La Fibre
Télécom => Logiciels et systèmes d'exploitation => 
Navigateurs web => Discussion démarrée par: renaud07 le 10 mai 2019 à 00:24:18
-
Dans mes souvenirs de premières captures, il m'avait semblé que lorsque j'avais droit à connexion échouée, aucun paquet n'était envoyé, j'ai enfin pu le prendre sur le fait : c'est exactement ce qu'il se passe.
voici un petit screenshot : Dans les deux cas l'échange s'arrête au dernier Reset : je modifie mon message, clique pour poster : paf connexion échouée. Puis Réessayer, renvoyer > ça repart.
-
J'ai l'impression que j'ai beaucoup plus de Reset sur le forum que sur d'autres sites, est-ce normal d'en avoir autant ? Par exemple :
Vu que c'est toujours après un reset que j'ai une connexion échouée (ça ne le fait pas à chaque fois heureusement, vu tout ce que je vois passer)...
-
Là dans ces échanges le serveur répond bien et c'est toi le cient qui refuse de se connecter : le Reset est envoyé par le client, pas par le serveur !
Un peu comme si le chiffrement proposé ne lui convenait pas.
Tu as quoi comme anti-virus ?
-
Anti-virus ? Aucun, j'étais sur ubuntu tout ce temps là.
A noter que sous windows il ne me semble pas que ça le fasse. A vérifier sur une longue période.
Je vais essayer avec chromium aujourd'hui, des fois que ça vienne de firefox ou d'un mauvais paramétrage.
-
Je crois que le résultat est sans appel : Avec firefox j'ai des dizaines de RST, alors qu'avec chromium, j'en vois passer de temps en temps mais sans plus.
Quel genre de paramétrage pourrait provoquer ça ?
-
Une extension mal développée ?
Ce qui est sur et sans appel avec ta capture, c'est que c'est le client qui arrête la connexion TCP.
Le serveur répond bien (tu le sollicite beaucoup, il est probable que tu aurait été jeté avec des règles anti DOS, car là tu es très agressif, regarde le nombre de connexion TCP crées !)
-
En extension je n'ai que ublock et downloadhelper.
Pour le nombre important de connexions TCP je ne saurais te dire pourquoi.
Après c'est vrai j'ai peut-être tendance à naviguer rapidement (mais ce n'est pas que sur le forum), là c'était un test je cliquais sur plusieurs sections à quelques secondes d'intervalle, pour voir si ça générait des RST.
-
La première seconde de ta capture tu as généré 19 connexion TCP (une seule connexion TCP permet de naviguer dans de nombreuses pages sur le forum, d’ailleurs seule la première a été utilisé et pas jusqu'à la fin : le serveur t'envoyait des données et toit tu répondait Reset systématiquement)
Tu as trouvé l'extension problématique ?
Test en premier en désactivant downloadhelper.
-
Download helper désactivé ainsi que ublock : toujours autant de RST...
Pour cette capture tout j'ai désactivé et simplement cliqué pour afficher la page d’accueil sans aller ailleurs, y'a vraiment un truc qui cloche.
-
La commande si tu souhaites voir les connexion TCP que tu ouvre est la suivante : tcp.flags.syn == 1 && ip.src==192.168.1.11
31 connexions TCP ouvertes en 560ms !
Je n'ai pas d'idée sur la source de ce pb.
-
Ah oui... la commande permet de se rendre bien compte du problème.
Firefox : un clic, des dizaines de connexions ouvertes.
Chromium : une connexion par clic.
-
Quel genre de paramétrage pourrait provoquer ça ?
c'est quelle version de FF et OS ?
Dans "about:config", recherche "network.http" . Regarde s'il y a des lignes en gras.
-
c'est quelle version de FF et OS ?
Firefox 66 et ubuntu 18.04. mais ça le faisait déjà plusieurs versions avant ça, cela doit faire au moins 2 ans que j'ai ce problème si c'est pas plus...
Dans "about:config", recherche "network.http" . Regarde s'il y a des lignes en gras.
Ah ! Je crois avoir trouvé un truc :
network.http.speculative-parallel-limit 0
On tient le bon bout j'ai l'impression ?
Sur un FF fraîchement installé c'est paramétré à 6.
-
Raté... je pensais que ça venait là de mais non, j'ai toujours autant de connexions ouvertes en même temps.
EDIT : En fait c'est un peu normal ça n'a rien à voir... :
Préconnexions prédictives
Pour améliorer la vitesse de chargement, Firefox ouvrira des connexions prédictives aux sites lorsque l’utilisateur ou l’utilisatrice survole avec son curseur les miniatures de la page de nouvel onglet, démarre une recherche dans la barre de recherche, ou encore dans le champ de recherche de la page d’accueil ou de la page de nouvel onglet.
-
oui c'est mieux de lire la doc avant de tester ;D
-> t'as aucune lignes en gras dans "about:config", recherche "network.http"
sinon tu passe peut-être par un proxy ou cache sans le savoir ?
-
L'IP qui se présente sur le forum est bien une IP d'une box ADSL dans le sud-est de la France donc pas de proxy.
-
L'IP qui se présente sur le forum est bien une IP d'une box ADSL dans le sud-est de la France donc pas de proxy.
il peut avoir un proxy avant la box, voir meme dans la meme machine.
-
Voir https://bugzilla.mozilla.org/show_bug.cgi?id=1533273 qui, même s'il est un peu différent, donne quelques pistes.
network.http.speculative-parallel-limit a probablement été mis 0 par ublock ("Désactiver la prédiction des actions sur le réseau" est coché par défaut)
Est-ce que l'IPv6 est activé ? Et est-il fonctionnel ?
Firefox implèmente à priori le Happy Eyeballs : connexion quasi simultanée en IPv4 et IPv6, au cas où l'IPv6 serait non fonctionnelle.
Il est possible que la connexion IPv6 réussisse, et qu'il annule donc l'IPv4.
Je ne connais pas les détails du comportement de Firefox, normalement :
- la connexion IPv4 est démarrée avec un délai (peut-être que le délai est trop court et qu'il n'a pas encore la réponse IPv6 à ce moment là)
- on peut s'attendre à ce que l'état "IPv6 fonctionnel pour lafibre.info" soit enregistré, donc c'est étrange d'avoir ce comportement régulièrement
Peut-être qu'il y a un paramètre incorrect, un bug dans Firefox, ou que l'IPv6 fonctionne mal, ce qui engendre des tentatives régulières en IPv4.
-
Pas d'IPv6 sur mon LAN. Il est activé sur le système mais j'ai seulement la link-local donc ça n'a aucune incidence à mon avis.
Pour l'option speculative-parallel-limit, ça explique pourquoi lorsque j'essayais de la remettre par défaut elle revenait à 0 à chaque redémarrage.
Sinon, une chose m'intrigue : systématiquement lors du premier démarrage, il ouvre un très grand nombre de connexions TCP (au moins 40), puis ça se calme 3-4 connexions à chaque fois que je vais dans une section... alors que chromium lui, n'en ouvre que 2... et une par lien/section visité. C'est incompréhensible.
Je suis aussi certain de ne pas passer par un proxy, à moins d'avoir choppé un virus bien dissimulé, sous linux qui plus est, ça me parait quasi impossible.
-
Testé sous windows au démarrage (toujours sur la v66) : 27 connexions TCP ouvertes, y'a du mieux. Et c'est a peu près à même chose lorsque j'ouvre différents topic 4 à 6 connexions...
Et bonne surprise : les RST sont quasi absents contrairement à Ubuntu où j'en ai à la pelle.
-
t'as quand meme pas mal de RST.
peut-être un souci sur ton NAT qui drop des translations ? c'est une livebox ou un routeur perso ?
-
Routeur perso. BT home hub 5 sous OWRT sur lequel j'avais tenté de monter mes VPN.
Pour être complet, j'ai aussi 2 nanostations qui assurent la connexion, mais je pense pas que ça vienne de là.
-
t'as combien sur http://ipdurouteur/cgi-bin/luci/admin/status/realtime/connections ?
-
Une 30aine de connexions en moyenne.
Le problème c'est que je ne suis pas seul à me servir du net donc le résultat est faussé... Sinon lorsque j'actualise les pages je vois bien mes 5 ou 6 connexions et elles disparaissent quelques secondes plus tard.
Par exemple (bon là d'accord y'en a un peu plus...) :
-
Je viens d'essayer sur un PC portable avec un hardware totalement différent et debian buster : résultat identique... De même en partage de connexion sur la 4G SFR (histoire d'éliminer un pb de routeur).
C'est désespérant.
As-tu checké voir si ça faisait pareil chez toi ? Je ne peux pas croire que je sois le seul concerné...
-
Windows 10 pro 1809, firefox 66.0.5 (64 bits), chargement de https://lafibre.info (avec F12/réseau/désactiver le cache coché) : 6 connections exactement. pas de RST, rien de superflu.
(https://i.imgur.com/F5a2vTh.png)
la page lafibre.info (sans authentification sur le site), nécessite 118 requêtes https qui sont donc réparties sur les 6 connections TCP constatées:
(https://i.imgur.com/qljXEgf.png)
-
De mon côté j'ai 120 requêtes sans login. Ça à l'air ok.
Par contre niveau TCP ça part vraiment en c**** 61 connexions au premier lancement de FF ! Je crois que j'ai explosé le record d'hier :o
Comme on peut le voir, seul les 6-7 premières connexions contient vraiment des données (comme chez toi du coup), les autres sont créées inutilement... Et niveau RST c'est la fête quasi toute la capture est teintée de rouge.
-
Je pense que la cause du nombre de connexion élevé, c'est les Reset : si la connexion ferme, il la ré-ouvre.
Il faut donc trouver l'origine de ces reset envoyé par ton PC.
-
t'es sur que c'est firefox qui ouvre ces connexions ?
vu que t'es sur Linux:
sudo strace -e trace=network firefox https://lafibre.info/
(faut apt install strace avant)
-
c'est le résultat attendu ? :
recvmsg(4, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\16\0\350 \33\0@\3\0\0>\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., iov_len=4096}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 64
recvmsg(4, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(4, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(4, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(4, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(4, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(4, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(4, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\16\0\353 \33\0@\3\0\0>\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., iov_len=4096}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 64
recvmsg(4, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(4, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(4, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(4, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(4, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(4, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(4, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(4, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(4, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(4, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(4, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(4, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(4, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(4, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\16\0\356 \33\0@\3\0\0>\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., iov_len=4096}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 64
Et si je lance avec sudo il me dit que ce n'est pas supporté.
Running Firefox as root in a regular user's session is not supported.
Faut obligatoirement lancer une session root en graphique ?
EDIT : c'est bizarre... si FF est déjà ouvert la commande se termine avec exited 0 et si je lance alors qu'il n'est pas ouvert elle continue indéfiniment même après avoir chargé le forum, normal ?
-
ah oui c'est chiant sudo avec firefox. il faut donc lancer firefox normalement (1 seul onglet) ,repérér le n° de process de l'onglet puis faire un sudo strace avec le n° de process et ouvrir lafibre.info dans l'onglet.
pgrep -a firefox
noter le PID de firefox.
puis
sudo strace -e trace=network -p PID(ctrl-c pour arreter la trace)
-
J'ai les même lignes que précédemment... à la différence que ça fonctionne bien avec sudo cette fois.
On dirait qu'il affiche tous les appels système et pas que le réseau malgré l'argument. Car si je déplace ma souris sur la page les lignes changent.
-
Je viens de trouver un truc avec grep pour filtrer :
ici j'ai actualisé une fois le topic et cliqué pour aller sur l'accueil. (En fait je ne sais même pas si j'ai utilisé le bon truc ?)
renaud@renaud-pc:~$ sudo strace -f -e trace=network -p 8747 2>&1 | grep sin_addr
[sudo] Mot de passe de renaud :
[pid 9781] connect(58, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("127.0.0.53")}, 16) = 0
[pid 9781] recvfrom(58, "\227\341\201\200\0\1\0\1\0\0\0\0\7lafibre\4info\0\0\1\0\1\300\f"..., 1024, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("127.0.0.53")}, [28->16]) = 46
[pid 8784] connect(58, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("46.227.16.8")}, 16) = -1 EINPROGRESS (Operation now in progress)
[pid 8784] getsockname(58, {sa_family=AF_INET, sin_port=htons(59204), sin_addr=inet_addr("192.168.1.11")}, [112->16]) = 0
[pid 8784] getpeername(58, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("46.227.16.8")}, [112->16]) = 0
[pid 8784] getpeername(58, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("46.227.16.8")}, [112->16]) = 0
[pid 9780] connect(55, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("127.0.0.53")}, 16) = 0
[pid 9780] recvfrom(55, "\274\354\201\200\0\1\0\1\0\0\0\0\7lafibre\4info\0\0\1\0\1\300\f"..., 1024, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("127.0.0.53")}, [28->16]) = 46
[pid 8784] connect(55, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("46.227.16.8")}, 16) = -1 EINPROGRESS (Operation now in progress)
[pid 9777] connect(47, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("127.0.0.53")}, 16) = 0
[pid 9777] recvfrom(47, "\377\274\201\200\0\1\0\1\0\0\0\0\7lafibre\4info\0\0\1\0\1\300\f"..., 1024, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("127.0.0.53")}, [28->16]) = 46
[pid 8784] connect(47, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("46.227.16.8")}, 16) = -1 EINPROGRESS (Operation now in progress)
[pid 9781] connect(57, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("127.0.0.53")}, 16) = 0
[pid 9781] recvfrom(57, "\257&\201\200\0\1\0\1\0\0\0\0\7lafibre\4info\0\0\1\0\1\300\f"..., 1024, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("127.0.0.53")}, [28->16]) = 46
[pid 8784] connect(57, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("46.227.16.8")}, 16 <unfinished ...>
[pid 8784] getsockname(47, {sa_family=AF_INET, sin_port=htons(59208), sin_addr=inet_addr("192.168.1.11")}, [112->16]) = 0
[pid 8784] getsockname(55, {sa_family=AF_INET, sin_port=htons(59206), sin_addr=inet_addr("192.168.1.11")}, [112->16]) = 0
[pid 8784] getpeername(47, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("46.227.16.8")}, [112->16]) = 0
[pid 8784] getpeername(55, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("46.227.16.8")}, [112->16]) = 0
[pid 8784] getpeername(47, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("46.227.16.8")}, [112->16]) = 0
[pid 8784] getpeername(55, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("46.227.16.8")}, [112->16]) = 0
[pid 8784] getpeername(57, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("46.227.16.8")}, [112->16]) = 0
[pid 8784] getsockname(57, {sa_family=AF_INET, sin_port=htons(59210), sin_addr=inet_addr("192.168.1.11")}, [112->16]) = 0
[pid 8784] getpeername(57, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("46.227.16.8")}, [112->16]) = 0
[pid 9780] connect(41, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("127.0.0.53")}, 16) = 0
[pid 9780] <... recvfrom resumed> "\237\363\201\200\0\1\0\1\0\0\0\0\7lafibre\4info\0\0\1\0\1\300\f"..., 1024, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("127.0.0.53")}, [28->16]) = 46
[pid 8784] connect(41, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("46.227.16.8")}, 16) = -1 EINPROGRESS (Operation now in progress)
[pid 8784] connect(119, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("46.227.16.8")}, 16) = -1 EINPROGRESS (Operation now in progress)
[pid 8784] getsockname(41, {sa_family=AF_INET, sin_port=htons(59212), sin_addr=inet_addr("192.168.1.11")}, [112->16]) = 0
[pid 8784] getpeername(41, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("46.227.16.8")}, [112->16]) = 0
[pid 8784] <... getpeername resumed> {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("46.227.16.8")}, [112->16]) = 0
[pid 8784] <... getpeername resumed> {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("46.227.16.8")}, [112->16]) = 0
[pid 8784] getsockname(119, {sa_family=AF_INET, sin_port=htons(59214), sin_addr=inet_addr("192.168.1.11")}, [112->16]) = 0
[pid 8784] getpeername(119, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("46.227.16.8")}, [112->16]) = 0
[pid 9777] connect(48, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("127.0.0.53")}, 16 <unfinished ...>
[pid 9777] <... recvfrom resumed> "8p\201\200\0\1\0\2\0\0\0\0\1i\5imgur\3com\0\0\1\0\1\300\f\0"..., 1024, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("127.0.0.53")}, [28->16]) = 86
[pid 8784] connect(48, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("151.101.120.193")}, 16) = -1 EINPROGRESS (Operation now in progress)
[pid 8784] getsockname(48, {sa_family=AF_INET, sin_port=htons(58266), sin_addr=inet_addr("192.168.1.11")}, [112->16]) = 0
[pid 8784] getpeername(48, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("151.101.120.193")}, [112->16]) = 0
[pid 8784] <... getpeername resumed> {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("151.101.120.193")}, [112->16]) = 0
[pid 9781] connect(47, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("127.0.0.53")}, 16) = 0
[pid 9781] <... recvfrom resumed> "f\344\201\200\0\1\0\1\0\0\0\0\7lafibre\4info\0\0\1\0\1\300\f"..., 1024, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("127.0.0.53")}, [28->16]) = 46
[pid 8784] connect(47, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("46.227.16.8")}, 16 <unfinished ...>
[pid 8784] getsockname(47, {sa_family=AF_INET, sin_port=htons(59218), sin_addr=inet_addr("192.168.1.11")}, [112->16]) = 0
[pid 8784] getpeername(47, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("46.227.16.8")}, [112->16]) = 0
[pid 8784] getpeername(47, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("46.227.16.8")}, [112->16]) = 0
[pid 8784] connect(55, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("46.227.16.8")}, 16) = -1 EINPROGRESS (Operation now in progress)
[pid 8784] connect(247, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("46.227.16.8")}, 16) = -1 EINPROGRESS (Operation now in progress)
[pid 8784] connect(248, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("46.227.16.8")}, 16) = -1 EINPROGRESS (Operation now in progress)
[pid 8784] connect(48, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("46.227.16.8")}, 16) = -1 EINPROGRESS (Operation now in progress)
[pid 8784] connect(249, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("46.227.16.8")}, 16 <unfinished ...>
[pid 8784] connect(47, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("46.227.16.8")}, 16) = -1 EINPROGRESS (Operation now in progress)
[pid 8784] connect(55, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("46.227.16.8")}, 16) = -1 EINPROGRESS (Operation now in progress)
[pid 8784] connect(247, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("46.227.16.8")}, 16) = -1 EINPROGRESS (Operation now in progress)
[pid 8784] connect(248, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("46.227.16.8")}, 16 <unfinished ...>
[pid 8784] connect(48, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("46.227.16.8")}, 16 <unfinished ...>
[pid 8784] connect(249, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("46.227.16.8")}, 16) = -1 EINPROGRESS (Operation now in progress)
[pid 8784] connect(47, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("46.227.16.8")}, 16 <unfinished ...>
[pid 8784] connect(55, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("46.227.16.8")}, 16 <unfinished ...>
[pid 8784] connect(247, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("46.227.16.8")}, 16) = -1 EINPROGRESS (Operation now in progress)
[pid 8784] connect(248, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("46.227.16.8")}, 16) = -1 EINPROGRESS (Operation now in progress)
[pid 8784] connect(48, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("46.227.16.8")}, 16 <unfinished ...>
[pid 8784] connect(249, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("46.227.16.8")}, 16) = -1 EINPROGRESS (Operation now in progress)
[pid 8784] connect(47, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("46.227.16.8")}, 16) = -1 EINPROGRESS (Operation now in progress)
[pid 8784] connect(55, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("46.227.16.8")}, 16 <unfinished ...>
[pid 8784] connect(247, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("46.227.16.8")}, 16) = -1 EINPROGRESS (Operation now in progress)
[pid 8784] connect(248, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("46.227.16.8")}, 16) = -1 EINPROGRESS (Operation now in progress)
[pid 8784] connect(248, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("46.227.16.8")}, 16) = -1 EINPROGRESS (Operation now in progress)
[pid 8784] getpeername(48, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("46.227.16.8")}, [112->16]) = 0
[pid 8784] <... getsockname resumed> {sa_family=AF_INET, sin_port=htons(59250), sin_addr=inet_addr("192.168.1.11")}, [112->16]) = 0
[pid 8784] getpeername(48, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("46.227.16.8")}, [112->16]) = 0
[pid 8784] getpeername(249, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("46.227.16.8")}, [112->16]) = 0
[pid 8784] getsockname(249, {sa_family=AF_INET, sin_port=htons(59252), sin_addr=inet_addr("192.168.1.11")}, [112->16]) = 0
[pid 8784] getpeername(249, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("46.227.16.8")}, [112->16]) = 0
[pid 8784] connect(48, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("46.227.16.8")}, 16) = -1 EINPROGRESS (Operation now in progress)
[pid 8784] connect(249, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("46.227.16.8")}, 16) = -1 EINPROGRESS (Operation now in progress)
[pid 8784] getsockname(47, {sa_family=AF_INET, sin_port=htons(59254), sin_addr=inet_addr("192.168.1.11")}, [112->16]) = 0
[pid 8784] getpeername(47, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("46.227.16.8")}, [112->16]) = 0
[pid 8784] getpeername(47, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("46.227.16.8")}, [112->16]) = 0
[pid 8784] connect(249, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("46.227.16.8")}, 16) = -1 EINPROGRESS (Operation now in progress)
[pid 8784] getsockname(55, {sa_family=AF_INET, sin_port=htons(59256), sin_addr=inet_addr("192.168.1.11")}, [112->16]) = 0
[pid 8784] getpeername(55, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("46.227.16.8")}, [112->16]) = 0
[pid 8784] getpeername(55, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("46.227.16.8")}, [112->16]) = 0
[pid 8784] getsockname(247, {sa_family=AF_INET, sin_port=htons(59258), sin_addr=inet_addr("192.168.1.11")}, [112->16]) = 0
[pid 8784] <... getpeername resumed> {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("46.227.16.8")}, [112->16]) = 0
[pid 8784] getpeername(247, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("46.227.16.8")}, [112->16]) = 0
[pid 8784] connect(41, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("46.227.16.8")}, 16) = -1 EINPROGRESS (Operation now in progress)
[pid 8784] getsockname(248, {sa_family=AF_INET, sin_port=htons(59262), sin_addr=inet_addr("192.168.1.11")}, [112->16]) = 0
[pid 8784] getpeername(248, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("46.227.16.8")}, [112->16]) = 0
[pid 8784] getpeername(248, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("46.227.16.8")}, [112->16]) = 0
[pid 8784] connect(41, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("46.227.16.8")}, 16) = -1 EINPROGRESS (Operation now in progress)
[pid 8784] connect(41, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("46.227.16.8")}, 16) = -1 EINPROGRESS (Operation now in progress)
[pid 8784] connect(41, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("46.227.16.8")}, 16) = -1 EINPROGRESS (Operation now in progress)
[pid 8784] connect(41, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("46.227.16.8")}, 16 <unfinished ...>
[pid 8784] connect(47, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("46.227.16.8")}, 16) = -1 EINPROGRESS (Operation now in progress)
[pid 8784] getpeername(48, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("46.227.16.8")}, [112->16]) = 0
[pid 8784] getsockname(48, {sa_family=AF_INET, sin_port=htons(59264), sin_addr=inet_addr("192.168.1.11")}, [112->16]) = 0
[pid 8784] getpeername(48, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("46.227.16.8")}, [112->16]) = 0
[pid 8784] connect(41, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("46.227.16.8")}, 16) = -1 EINPROGRESS (Operation now in progress)
[pid 8784] connect(47, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("46.227.16.8")}, 16) = -1 EINPROGRESS (Operation now in progress)
[pid 8784] connect(55, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("46.227.16.8")}, 16) = -1 EINPROGRESS (Operation now in progress)
[pid 8784] getsockname(249, {sa_family=AF_INET, sin_port=htons(59268), sin_addr=inet_addr("192.168.1.11")}, [112->16]) = 0
[pid 8784] <... getpeername resumed> {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("46.227.16.8")}, [112->16]) = 0
[pid 8784] getpeername(249, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("46.227.16.8")}, [112->16]) = 0
[pid 8784] connect(41, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("46.227.16.8")}, 16) = -1 EINPROGRESS (Operation now in progress)
[pid 8784] connect(47, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("46.227.16.8")}, 16) = -1 EINPROGRESS (Operation now in progress)
[pid 8784] connect(55, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("46.227.16.8")}, 16) = -1 EINPROGRESS (Operation now in progress)
[pid 8784] connect(41, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("46.227.16.8")}, 16) = -1 EINPROGRESS (Operation now in progress)
[pid 8784] connect(47, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("46.227.16.8")}, 16) = -1 EINPROGRESS (Operation now in progress)
[pid 8784] connect(48, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("46.227.16.8")}, 16) = -1 EINPROGRESS (Operation now in progress)
[pid 8784] connect(55, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("46.227.16.8")}, 16 <unfinished ...>
[pid 8784] connect(41, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("46.227.16.8")}, 16) = -1 EINPROGRESS (Operation now in progress)
[pid 8784] connect(47, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("46.227.16.8")}, 16) = -1 EINPROGRESS (Operation now in progress)
[pid 8784] connect(55, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("46.227.16.8")}, 16) = -1 EINPROGRESS (Operation now in progress)
-
Avec TCP dans le filtre ça serait peut-être mieux en fait...
renaud@renaud-pc:~$ sudo strace -f -e trace=network -p 10868 2>&1 | grep TCP
[pid 10905] setsockopt(108, SOL_TCP, TCP_NODELAY, [1], 4 <unfinished ...>
[pid 10905] setsockopt(108, SOL_TCP, TCP_KEEPIDLE, [10], 4) = 0
[pid 10905] setsockopt(108, SOL_TCP, TCP_KEEPINTVL, [1], 4) = 0
[pid 10905] setsockopt(108, SOL_TCP, TCP_KEEPCNT, [4], 4) = 0
[pid 10905] setsockopt(108, SOL_TCP, TCP_KEEPIDLE, [10], 4) = 0
[pid 10905] setsockopt(108, SOL_TCP, TCP_KEEPINTVL, [1], 4) = 0
[pid 10905] setsockopt(108, SOL_TCP, TCP_KEEPCNT, [4], 4) = 0
[pid 10905] setsockopt(108, SOL_TCP, TCP_NODELAY, [1], 4) = 0
[pid 10905] setsockopt(104, SOL_TCP, TCP_NODELAY, [1], 4) = 0
[pid 10905] setsockopt(104, SOL_TCP, TCP_KEEPIDLE, [10], 4) = 0
[pid 10905] setsockopt(104, SOL_TCP, TCP_KEEPINTVL, [1], 4) = 0
[pid 10905] setsockopt(104, SOL_TCP, TCP_KEEPCNT, [4], 4) = 0
[pid 10905] setsockopt(104, SOL_TCP, TCP_KEEPIDLE, [10], 4) = 0
[pid 10905] setsockopt(104, SOL_TCP, TCP_KEEPINTVL, [1], 4 <unfinished ...>
[pid 10905] setsockopt(104, SOL_TCP, TCP_KEEPCNT, [4], 4) = 0
[pid 10905] setsockopt(104, SOL_TCP, TCP_NODELAY, [1], 4) = 0
[pid 10905] setsockopt(106, SOL_TCP, TCP_NODELAY, [1], 4 <unfinished ...>
[pid 10905] setsockopt(106, SOL_TCP, TCP_KEEPIDLE, [10], 4) = 0
[pid 10905] setsockopt(106, SOL_TCP, TCP_KEEPINTVL, [1], 4) = 0
[pid 10905] setsockopt(106, SOL_TCP, TCP_KEEPCNT, [4], 4) = 0
[pid 10905] setsockopt(106, SOL_TCP, TCP_KEEPIDLE, [10], 4) = 0
[pid 10905] setsockopt(106, SOL_TCP, TCP_KEEPINTVL, [1], 4) = 0
[pid 10905] setsockopt(106, SOL_TCP, TCP_KEEPCNT, [4], 4) = 0
[pid 10905] setsockopt(106, SOL_TCP, TCP_NODELAY, [1], 4) = 0
[pid 10905] setsockopt(101, SOL_TCP, TCP_NODELAY, [1], 4) = 0
[pid 10905] setsockopt(101, SOL_TCP, TCP_KEEPIDLE, [10], 4 <unfinished ...>
[pid 10905] setsockopt(101, SOL_TCP, TCP_KEEPINTVL, [1], 4) = 0
[pid 10905] setsockopt(101, SOL_TCP, TCP_KEEPCNT, [4], 4) = 0
[pid 10905] setsockopt(101, SOL_TCP, TCP_KEEPIDLE, [10], 4 <unfinished ...>
[pid 10905] setsockopt(101, SOL_TCP, TCP_KEEPINTVL, [1], 4) = 0
[pid 10905] setsockopt(101, SOL_TCP, TCP_KEEPCNT, [4], 4) = 0
[pid 10905] setsockopt(101, SOL_TCP, TCP_NODELAY, [1], 4 <unfinished ...>
[pid 10905] setsockopt(108, SOL_TCP, TCP_NODELAY, [1], 4 <unfinished ...>
[pid 10905] setsockopt(108, SOL_TCP, TCP_KEEPIDLE, [10], 4) = 0
[pid 10905] setsockopt(108, SOL_TCP, TCP_KEEPINTVL, [1], 4) = 0
[pid 10905] setsockopt(108, SOL_TCP, TCP_KEEPCNT, [4], 4 <unfinished ...>
[pid 10905] setsockopt(108, SOL_TCP, TCP_KEEPIDLE, [10], 4 <unfinished ...>
[pid 10905] setsockopt(108, SOL_TCP, TCP_KEEPINTVL, [1], 4) = 0
[pid 10905] setsockopt(108, SOL_TCP, TCP_KEEPCNT, [4], 4) = 0
[pid 10905] setsockopt(108, SOL_TCP, TCP_NODELAY, [1], 4) = 0
[pid 10905] setsockopt(104, SOL_TCP, TCP_NODELAY, [1], 4 <unfinished ...>
[pid 10905] setsockopt(104, SOL_TCP, TCP_KEEPIDLE, [10], 4) = 0
[pid 10905] setsockopt(104, SOL_TCP, TCP_KEEPINTVL, [1], 4) = 0
[pid 10905] setsockopt(104, SOL_TCP, TCP_KEEPCNT, [4], 4) = 0
[pid 10905] setsockopt(104, SOL_TCP, TCP_KEEPIDLE, [10], 4) = 0
[pid 10905] setsockopt(104, SOL_TCP, TCP_KEEPINTVL, [1], 4) = 0
[pid 10905] setsockopt(104, SOL_TCP, TCP_KEEPCNT, [4], 4) = 0
[pid 10905] setsockopt(104, SOL_TCP, TCP_NODELAY, [1], 4) = 0
[pid 10905] setsockopt(106, SOL_TCP, TCP_NODELAY, [1], 4) = 0
[pid 10905] setsockopt(106, SOL_TCP, TCP_KEEPIDLE, [10], 4) = 0
[pid 10905] setsockopt(106, SOL_TCP, TCP_KEEPINTVL, [1], 4) = 0
[pid 10905] setsockopt(106, SOL_TCP, TCP_KEEPCNT, [4], 4) = 0
[pid 10905] setsockopt(106, SOL_TCP, TCP_KEEPIDLE, [10], 4 <unfinished ...>
[pid 10905] setsockopt(106, SOL_TCP, TCP_KEEPINTVL, [1], 4) = 0
[pid 10905] setsockopt(106, SOL_TCP, TCP_KEEPCNT, [4], 4) = 0
[pid 10905] setsockopt(143, SOL_TCP, TCP_NODELAY, [1], 4) = 0
[pid 10905] setsockopt(148, SOL_TCP, TCP_NODELAY, [1], 4) = 0
[pid 10905] setsockopt(151, SOL_TCP, TCP_NODELAY, [1], 4) = 0
[pid 10905] setsockopt(91, SOL_TCP, TCP_NODELAY, [1], 4 <unfinished ...>
[pid 10905] setsockopt(143, SOL_TCP, TCP_KEEPIDLE, [10], 4) = 0
[pid 10905] setsockopt(143, SOL_TCP, TCP_KEEPINTVL, [1], 4 <unfinished ...>
[pid 10905] setsockopt(143, SOL_TCP, TCP_KEEPCNT, [4], 4 <unfinished ...>
[pid 10905] setsockopt(143, SOL_TCP, TCP_KEEPIDLE, [10], 4) = 0
[pid 10905] setsockopt(143, SOL_TCP, TCP_KEEPINTVL, [1], 4) = 0
[pid 10905] setsockopt(143, SOL_TCP, TCP_KEEPCNT, [4], 4) = 0
[pid 10905] setsockopt(148, SOL_TCP, TCP_KEEPIDLE, [10], 4) = 0
[pid 10905] setsockopt(148, SOL_TCP, TCP_KEEPINTVL, [1], 4) = 0
[pid 10905] setsockopt(148, SOL_TCP, TCP_KEEPCNT, [4], 4) = 0
[pid 10905] setsockopt(148, SOL_TCP, TCP_KEEPIDLE, [10], 4) = 0
[pid 10905] setsockopt(148, SOL_TCP, TCP_KEEPINTVL, [1], 4) = 0
[pid 10905] setsockopt(148, SOL_TCP, TCP_KEEPCNT, [4], 4) = 0
[pid 10905] setsockopt(151, SOL_TCP, TCP_KEEPIDLE, [10], 4) = 0
[pid 10905] setsockopt(151, SOL_TCP, TCP_KEEPINTVL, [1], 4) = 0
[pid 10905] setsockopt(151, SOL_TCP, TCP_KEEPCNT, [4], 4) = 0
[pid 10905] setsockopt(151, SOL_TCP, TCP_KEEPIDLE, [10], 4) = 0
[pid 10905] setsockopt(151, SOL_TCP, TCP_KEEPINTVL, [1], 4) = 0
[pid 10905] setsockopt(151, SOL_TCP, TCP_KEEPCNT, [4], 4) = 0
[pid 10905] setsockopt(91, SOL_TCP, TCP_KEEPIDLE, [10], 4) = 0
[pid 10905] setsockopt(91, SOL_TCP, TCP_KEEPINTVL, [1], 4) = 0
[pid 10905] setsockopt(91, SOL_TCP, TCP_KEEPCNT, [4], 4) = 0
[pid 10905] setsockopt(91, SOL_TCP, TCP_KEEPIDLE, [10], 4) = 0
[pid 10905] setsockopt(91, SOL_TCP, TCP_KEEPINTVL, [1], 4) = 0
[pid 10905] setsockopt(91, SOL_TCP, TCP_KEEPCNT, [4], 4) = 0
[pid 10905] setsockopt(106, SOL_TCP, TCP_NODELAY, [1], 4) = 0
[pid 10905] setsockopt(143, SOL_TCP, TCP_NODELAY, [1], 4 <unfinished ...>
[pid 10905] setsockopt(148, SOL_TCP, TCP_NODELAY, [1], 4) = 0
[pid 10905] setsockopt(151, SOL_TCP, TCP_NODELAY, [1], 4) = 0
[pid 10905] setsockopt(91, SOL_TCP, TCP_NODELAY, [1], 4) = 0
[pid 10905] setsockopt(104, SOL_TCP, TCP_NODELAY, [1], 4 <unfinished ...>
[pid 10905] setsockopt(104, SOL_TCP, TCP_KEEPIDLE, [10], 4) = 0
[pid 10905] setsockopt(104, SOL_TCP, TCP_KEEPINTVL, [1], 4) = 0
[pid 10905] setsockopt(104, SOL_TCP, TCP_KEEPCNT, [4], 4) = 0
[pid 10905] setsockopt(104, SOL_TCP, TCP_KEEPIDLE, [10], 4 <unfinished ...>
[pid 10905] setsockopt(104, SOL_TCP, TCP_KEEPINTVL, [1], 4) = 0
[pid 10905] setsockopt(104, SOL_TCP, TCP_KEEPCNT, [4], 4) = 0
[pid 10905] setsockopt(104, SOL_TCP, TCP_NODELAY, [1], 4) = 0
[pid 10905] setsockopt(101, SOL_TCP, TCP_NODELAY, [1], 4) = 0
[pid 10905] setsockopt(101, SOL_TCP, TCP_KEEPIDLE, [10], 4 <unfinished ...>
[pid 10905] setsockopt(101, SOL_TCP, TCP_KEEPINTVL, [1], 4) = 0
[pid 10905] setsockopt(101, SOL_TCP, TCP_KEEPCNT, [4], 4) = 0
[pid 10905] setsockopt(101, SOL_TCP, TCP_KEEPIDLE, [10], 4 <unfinished ...>
[pid 10905] setsockopt(101, SOL_TCP, TCP_KEEPINTVL, [1], 4) = 0
[pid 10905] setsockopt(101, SOL_TCP, TCP_KEEPCNT, [4], 4 <unfinished ...>
[pid 10905] setsockopt(108, SOL_TCP, TCP_NODELAY, [1], 4) = 0
[pid 10905] setsockopt(111, SOL_TCP, TCP_NODELAY, [1], 4) = 0
[pid 10905] setsockopt(119, SOL_TCP, TCP_NODELAY, [1], 4 <unfinished ...>
[pid 10905] setsockopt(127, SOL_TCP, TCP_NODELAY, [1], 4) = 0
[pid 10905] setsockopt(108, SOL_TCP, TCP_KEEPIDLE, [10], 4) = 0
[pid 10905] setsockopt(108, SOL_TCP, TCP_KEEPINTVL, [1], 4) = 0
[pid 10905] setsockopt(108, SOL_TCP, TCP_KEEPCNT, [4], 4) = 0
[pid 10905] setsockopt(108, SOL_TCP, TCP_KEEPIDLE, [10], 4) = 0
[pid 10905] setsockopt(108, SOL_TCP, TCP_KEEPINTVL, [1], 4 <unfinished ...>
[pid 10905] setsockopt(108, SOL_TCP, TCP_KEEPCNT, [4], 4) = 0
[pid 10905] setsockopt(111, SOL_TCP, TCP_KEEPIDLE, [10], 4 <unfinished ...>
[pid 10905] setsockopt(111, SOL_TCP, TCP_KEEPINTVL, [1], 4) = 0
[pid 10905] setsockopt(111, SOL_TCP, TCP_KEEPCNT, [4], 4) = 0
[pid 10905] setsockopt(111, SOL_TCP, TCP_KEEPIDLE, [10], 4) = 0
[pid 10905] setsockopt(111, SOL_TCP, TCP_KEEPINTVL, [1], 4) = 0
[pid 10905] setsockopt(111, SOL_TCP, TCP_KEEPCNT, [4], 4) = 0
[pid 10905] setsockopt(119, SOL_TCP, TCP_KEEPIDLE, [10], 4) = 0
[pid 10905] setsockopt(119, SOL_TCP, TCP_KEEPINTVL, [1], 4) = 0
[pid 10905] setsockopt(119, SOL_TCP, TCP_KEEPCNT, [4], 4 <unfinished ...>
[pid 10905] setsockopt(119, SOL_TCP, TCP_KEEPIDLE, [10], 4) = 0
[pid 10905] setsockopt(119, SOL_TCP, TCP_KEEPINTVL, [1], 4 <unfinished ...>
[pid 10905] setsockopt(119, SOL_TCP, TCP_KEEPCNT, [4], 4) = 0
[pid 10905] setsockopt(127, SOL_TCP, TCP_KEEPIDLE, [10], 4) = 0
[pid 10905] setsockopt(127, SOL_TCP, TCP_KEEPINTVL, [1], 4) = 0
[pid 10905] setsockopt(127, SOL_TCP, TCP_KEEPCNT, [4], 4 <unfinished ...>
[pid 10905] setsockopt(127, SOL_TCP, TCP_KEEPIDLE, [10], 4) = 0
[pid 10905] setsockopt(127, SOL_TCP, TCP_KEEPINTVL, [1], 4) = 0
[pid 10905] setsockopt(127, SOL_TCP, TCP_KEEPCNT, [4], 4 <unfinished ...>
[pid 10905] setsockopt(104, SOL_TCP, TCP_NODELAY, [1], 4 <unfinished ...>
[pid 10905] setsockopt(101, SOL_TCP, TCP_NODELAY, [1], 4) = 0
[pid 10905] setsockopt(104, SOL_TCP, TCP_KEEPIDLE, [10], 4) = 0
[pid 10905] setsockopt(104, SOL_TCP, TCP_KEEPINTVL, [1], 4) = 0
[pid 10905] setsockopt(104, SOL_TCP, TCP_KEEPCNT, [4], 4) = 0
[pid 10905] setsockopt(104, SOL_TCP, TCP_KEEPIDLE, [10], 4) = 0
[pid 10905] setsockopt(104, SOL_TCP, TCP_KEEPINTVL, [1], 4) = 0
[pid 10905] setsockopt(104, SOL_TCP, TCP_KEEPCNT, [4], 4) = 0
[pid 10905] setsockopt(127, SOL_TCP, TCP_NODELAY, [1], 4 <unfinished ...>
[pid 10905] setsockopt(108, SOL_TCP, TCP_NODELAY, [1], 4) = 0
[pid 10905] setsockopt(111, SOL_TCP, TCP_NODELAY, [1], 4) = 0
[pid 10905] setsockopt(119, SOL_TCP, TCP_NODELAY, [1], 4) = 0
[pid 10905] setsockopt(104, SOL_TCP, TCP_NODELAY, [1], 4) = 0
C'est ça qu'on cherche ? Les "unfinished" correspondent aux RST ?
Faites pas attention si je dis que des énormités, la programmation et moi ça fait 2. Comme dirait un certain youtuber (enfin, il est passé sur peertube maintenant) : "Je sais même pas faire un hello world en python" ;D
-
non, il faut plutôt que tu recherches les appels systèmes "connect"
-
Voici ce que ça donne en actualisant la page d'accueil :
renaud@renaud-pc:~$ sudo strace -f -e trace=network -p 10868 2>&1 | grep connect
[pid 10996] connect(106, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("127.0.0.53")}, 16 <unfinished ...>
[pid 10996] <... connect resumed> ) = 0
[pid 10905] getpeername(106, 0x7f44eec633d0, [112]) = -1 ENOTCONN (Transport endpoint is not connected)
[pid 10905] connect(106, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("46.227.16.8")}, 16) = -1 EINPROGRESS (Operation now in progress)
[pid 10905] getpeername(106, 0x7f44eec637f0, [112]) = -1 ENOTCONN (Transport endpoint is not connected)
[pid 11450] connect(116, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("127.0.0.53")}, 16) = 0
[pid 10905] <... getpeername resumed> 0x7f44eec633d0, [112]) = -1 ENOTCONN (Transport endpoint is not connected)
[pid 10905] connect(116, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("46.227.16.8")}, 16) = -1 EINPROGRESS (Operation now in progress)
[pid 10905] <... getpeername resumed> 0x7f44eec633d0, [112]) = -1 ENOTCONN (Transport endpoint is not connected)
[pid 10905] connect(127, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("46.227.16.8")}, 16) = -1 EINPROGRESS (Operation now in progress)
[pid 10905] getpeername(127, 0x7f44eec637f0, [112]) = -1 ENOTCONN (Transport endpoint is not connected)
[pid 10905] <... getpeername resumed> 0x7f44eec637f0, [112]) = -1 ENOTCONN (Transport endpoint is not connected)
[pid 10905] <... getpeername resumed> 0x7f44eec637f0, [112]) = -1 ENOTCONN (Transport endpoint is not connected)
[pid 10905] getpeername(116, 0x7f44eec637f0, [112]) = -1 ENOTCONN (Transport endpoint is not connected)
[pid 10905] <... getpeername resumed> 0x7f44eec637f0, [112]) = -1 ENOTCONN (Transport endpoint is not connected)
[pid 10905] <... getpeername resumed> 0x7f44eec637f0, [112]) = -1 ENOTCONN (Transport endpoint is not connected)
[pid 11054] connect(128, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("127.0.0.53")}, 16) = 0
[pid 10905] getpeername(127, 0x7f44eec637f0, [112]) = -1 ENOTCONN (Transport endpoint is not connected)
[pid 10905] getpeername(116, 0x7f44eec637f0, [112]) = -1 ENOTCONN (Transport endpoint is not connected)
[pid 10905] getpeername(128, 0x7f44eec633d0, [112]) = -1 ENOTCONN (Transport endpoint is not connected)
[pid 10905] connect(128, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("46.227.16.8")}, 16) = -1 EINPROGRESS (Operation now in progress)
[pid 10905] getpeername(127, 0x7f44eec637f0, [112]) = -1 ENOTCONN (Transport endpoint is not connected)
[pid 10905] getpeername(116, 0x7f44eec637f0, [112]) = -1 ENOTCONN (Transport endpoint is not connected)
[pid 10905] getpeername(128, 0x7f44eec637f0, [112]) = -1 ENOTCONN (Transport endpoint is not connected)
[pid 10905] getpeername(127, 0x7f44eec637f0, [112]) = -1 ENOTCONN (Transport endpoint is not connected)
[pid 10905] <... getpeername resumed> 0x7f44eec637f0, [112]) = -1 ENOTCONN (Transport endpoint is not connected)
[pid 10905] getpeername(127, 0x7f44eec637f0, [112]) = -1 ENOTCONN (Transport endpoint is not connected)
[pid 10905] getpeername(128, 0x7f44eec637f0, [112]) = -1 ENOTCONN (Transport endpoint is not connected)
[pid 10905] <... getpeername resumed> 0x7f44eec637f0, [112]) = -1 ENOTCONN (Transport endpoint is not connected)
[pid 10905] getpeername(128, 0x7f44eec637f0, [112]) = -1 ENOTCONN (Transport endpoint is not connected)
[pid 10905] getpeername(127, 0x7f44eec637f0, [112]) = -1 ENOTCONN (Transport endpoint is not connected)
[pid 10905] getpeername(128, 0x7f44eec637f0, [112]) = -1 ENOTCONN (Transport endpoint is not connected)
[pid 10996] connect(279, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("127.0.0.53")}, 16) = 0
[pid 10905] <... getpeername resumed> 0x7f44eec633d0, [112]) = -1 ENOTCONN (Transport endpoint is not connected)
[pid 10905] connect(279, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("46.227.16.8")}, 16) = -1 EINPROGRESS (Operation now in progress)
[pid 10905] getpeername(279, 0x7f44eec637f0, [112]) = -1 ENOTCONN (Transport endpoint is not connected)
[pid 10905] getpeername(279, 0x7f44eec637f0, [112]) = -1 ENOTCONN (Transport endpoint is not connected)
[pid 10905] getpeername(279, 0x7f44eec637f0, [112]) = -1 ENOTCONN (Transport endpoint is not connected)
[pid 10905] getpeername(279, 0x7f44eec637f0, [112]) = -1 ENOTCONN (Transport endpoint is not connected)
[pid 10905] getpeername(279, 0x7f44eec637f0, [112]) = -1 ENOTCONN (Transport endpoint is not connected)
[pid 11450] connect(285, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("127.0.0.53")}, 16) = 0
[pid 10905] getpeername(279, 0x7f44eec637f0, [112]) = -1 ENOTCONN (Transport endpoint is not connected)
[pid 10905] getpeername(285, 0x7f44eec633d0, [112]) = -1 ENOTCONN (Transport endpoint is not connected)
[pid 10905] connect(285, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("46.227.16.8")}, 16 <unfinished ...>
[pid 10905] <... connect resumed> ) = -1 EINPROGRESS (Operation now in progress)
[pid 10905] getpeername(279, 0x7f44eec637f0, [112]) = -1 ENOTCONN (Transport endpoint is not connected)
[pid 10905] getpeername(285, 0x7f44eec637f0, [112]) = -1 ENOTCONN (Transport endpoint is not connected)
[pid 10905] <... getpeername resumed> 0x7f44eec637f0, [112]) = -1 ENOTCONN (Transport endpoint is not connected)
[pid 10905] getpeername(285, 0x7f44eec637f0, [112]) = -1 ENOTCONN (Transport endpoint is not connected)
[pid 10905] getpeername(279, 0x7f44eec637f0, [112]) = -1 ENOTCONN (Transport endpoint is not connected)
[pid 10905] getpeername(285, 0x7f44eec637f0, [112]) = -1 ENOTCONN (Transport endpoint is not connected)
[pid 10905] getpeername(279, 0x7f44eec637f0, [112]) = -1 ENOTCONN (Transport endpoint is not connected)
[pid 10905] <... getpeername resumed> 0x7f44eec637f0, [112]) = -1 ENOTCONN (Transport endpoint is not connected)
[pid 10905] getpeername(279, 0x7f44eec637f0, [112]) = -1 ENOTCONN (Transport endpoint is not connected)
[pid 10905] getpeername(285, 0x7f44eec637f0, [112]) = -1 ENOTCONN (Transport endpoint is not connected)
[pid 10905] <... getpeername resumed> 0x7f44eec637f0, [112]) = -1 ENOTCONN (Transport endpoint is not connected)
[pid 10905] getpeername(285, 0x7f44eec637f0, [112]) = -1 ENOTCONN (Transport endpoint is not connected)
[pid 10905] getpeername(279, 0x7f44eec637f0, [112]) = -1 ENOTCONN (Transport endpoint is not connected)
[pid 10905] <... getpeername resumed> 0x7f44eec637f0, [112]) = -1 ENOTCONN (Transport endpoint is not connected)
[pid 10905] getpeername(279, 0x7f44eec637f0, [112]) = -1 ENOTCONN (Transport endpoint is not connected)
[pid 10905] <... getpeername resumed> 0x7f44eec637f0, [112]) = -1 ENOTCONN (Transport endpoint is not connected)
[pid 10905] getpeername(279, 0x7f44eec637f0, [112]) = -1 ENOTCONN (Transport endpoint is not connected)
[pid 10905] <... getpeername resumed> 0x7f44eec637f0, [112]) = -1 ENOTCONN (Transport endpoint is not connected)
[pid 10905] getpeername(279, 0x7f44eec637f0, [112]) = -1 ENOTCONN (Transport endpoint is not connected)
[pid 10905] getpeername(285, 0x7f44eec637f0, [112]) = -1 ENOTCONN (Transport endpoint is not connected)
[pid 10905] <... getpeername resumed> 0x7f44eec637f0, [112]) = -1 ENOTCONN (Transport endpoint is not connected)
[pid 10905] getpeername(285, 0x7f44eec637f0, [112]) = -1 ENOTCONN (Transport endpoint is not connected)
[pid 10905] getpeername(279, 0x7f44eec637f0, [112]) = -1 ENOTCONN (Transport endpoint is not connected)
[pid 10905] getpeername(285, 0x7f44eec637f0, [112]) = -1 ENOTCONN (Transport endpoint is not connected)
[pid 10905] getpeername(279, 0x7f44eec637f0, [112]) = -1 ENOTCONN (Transport endpoint is not connected)
[pid 10905] getpeername(285, 0x7f44eec637f0, [112]) = -1 ENOTCONN (Transport endpoint is not connected)
[pid 10905] getpeername(279, 0x7f44eec637f0, [112]) = -1 ENOTCONN (Transport endpoint is not connected)
[pid 10905] <... getpeername resumed> 0x7f44eec637f0, [112]) = -1 ENOTCONN (Transport endpoint is not connected)
[pid 10905] getpeername(279, 0x7f44eec637f0, [112]) = -1 ENOTCONN (Transport endpoint is not connected)
[pid 10905] <... getpeername resumed> 0x7f44eec637f0, [112]) = -1 ENOTCONN (Transport endpoint is not connected)
[pid 10905] <... getpeername resumed> 0x7f44eec637f0, [112]) = -1 ENOTCONN (Transport endpoint is not connected)
[pid 10905] getpeername(285, 0x7f44eec637f0, [112]) = -1 ENOTCONN (Transport endpoint is not connected)
[pid 10905] getpeername(279, 0x7f44eec637f0, [112]) = -1 ENOTCONN (Transport endpoint is not connected)
[pid 10905] <... getpeername resumed> 0x7f44eec637f0, [112]) = -1 ENOTCONN (Transport endpoint is not connected)
[pid 10905] getpeername(279, 0x7f44eec637f0, [112]) = -1 ENOTCONN (Transport endpoint is not connected)
[pid 10905] getpeername(285, 0x7f44eec637f0, [112]) = -1 ENOTCONN (Transport endpoint is not connected)
[pid 10905] getpeername(279, 0x7f44eec637f0, [112]) = -1 ENOTCONN (Transport endpoint is not connected)
[pid 10905] <... getpeername resumed> 0x7f44eec637f0, [112]) = -1 ENOTCONN (Transport endpoint is not connected)
[pid 10905] getpeername(279, 0x7f44eec637f0, [112]) = -1 ENOTCONN (Transport endpoint is not connected)
[pid 10905] <... getpeername resumed> 0x7f44eec637f0, [112]) = -1 ENOTCONN (Transport endpoint is not connected)
[pid 10905] getpeername(279, 0x7f44eec637f0, [112]) = -1 ENOTCONN (Transport endpoint is not connected)
[pid 10905] <... getpeername resumed> 0x7f44eec637f0, [112]) = -1 ENOTCONN (Transport endpoint is not connected)
[pid 10905] getpeername(279, 0x7f44eec637f0, [112]) = -1 ENOTCONN (Transport endpoint is not connected)
[pid 10905] <... getpeername resumed> 0x7f44eec637f0, [112]) = -1 ENOTCONN (Transport endpoint is not connected)
[pid 10905] getpeername(279, 0x7f44eec637f0, [112]) = -1 ENOTCONN (Transport endpoint is not connected)
[pid 10905] getpeername(285, 0x7f44eec637f0, [112]) = -1 ENOTCONN (Transport endpoint is not connected)
[pid 10905] getpeername(279, 0x7f44eec637f0, [112]) = -1 ENOTCONN (Transport endpoint is not connected)
[pid 10905] <... getpeername resumed> 0x7f44eec637f0, [112]) = -1 ENOTCONN (Transport endpoint is not connected)
[pid 10905] getpeername(279, 0x7f44eec637f0, [112]) = -1 ENOTCONN (Transport endpoint is not connected)
[pid 10905] <... getpeername resumed> 0x7f44eec637f0, [112]) = -1 ENOTCONN (Transport endpoint is not connected)
[pid 10905] getpeername(279, 0x7f44eec637f0, [112]) = -1 ENOTCONN (Transport endpoint is not connected)
[pid 10905] getpeername(285, 0x7f44eec637f0, [112]) = -1 ENOTCONN (Transport endpoint is not connected)
[pid 10905] getpeername(279, 0x7f44eec637f0, [112]) = -1 ENOTCONN (Transport endpoint is not connected)
[pid 10905] getpeername(285, 0x7f44eec637f0, [112]) = -1 ENOTCONN (Transport endpoint is not connected)
[pid 10905] getpeername(279, 0x7f44eec637f0, [112]) = -1 ENOTCONN (Transport endpoint is not connected)
[pid 10905] <... getpeername resumed> 0x7f44eec637f0, [112]) = -1 ENOTCONN (Transport endpoint is not connected)
[pid 10905] getpeername(279, 0x7f44eec637f0, [112]) = -1 ENOTCONN (Transport endpoint is not connected)
[pid 10905] <... getpeername resumed> 0x7f44eec637f0, [112]) = -1 ENOTCONN (Transport endpoint is not connected)
[pid 10905] getpeername(279, 0x7f44eec637f0, [112]) = -1 ENOTCONN (Transport endpoint is not connected)
[pid 10905] getpeername(285, 0x7f44eec637f0, [112]) = -1 ENOTCONN (Transport endpoint is not connected)
[pid 10905] getpeername(279, 0x7f44eec637f0, [112]) = -1 ENOTCONN (Transport endpoint is not connected)
[pid 10905] <... getpeername resumed> 0x7f44eec637f0, [112]) = -1 ENOTCONN (Transport endpoint is not connected)
[pid 10905] getpeername(279, 0x7f44eec637f0, [112]) = -1 ENOTCONN (Transport endpoint is not connected)
[pid 10905] getpeername(285, 0x7f44eec637f0, [112]) = -1 ENOTCONN (Transport endpoint is not connected)
[pid 10905] getpeername(279, 0x7f44eec637f0, [112]) = -1 ENOTCONN (Transport endpoint is not connected)
[pid 10905] getpeername(285, 0x7f44eec637f0, [112]) = -1 ENOTCONN (Transport endpoint is not connected)
[pid 10905] getpeername(279, 0x7f44eec637f0, [112]) = -1 ENOTCONN (Transport endpoint is not connected)
[pid 10905] <... getpeername resumed> 0x7f44eec637f0, [112]) = -1 ENOTCONN (Transport endpoint is not connected)
[pid 10905] getpeername(279, 0x7f44eec637f0, [112]) = -1 ENOTCONN (Transport endpoint is not connected)
[pid 10905] <... getpeername resumed> 0x7f44eec637f0, [112]) = -1 ENOTCONN (Transport endpoint is not connected)
[pid 10905] getpeername(279, 0x7f44eec637f0, [112]) = -1 ENOTCONN (Transport endpoint is not connected)
[pid 10905] <... getpeername resumed> 0x7f44eec637f0, [112]) = -1 ENOTCONN (Transport endpoint is not connected)
[pid 10905] getpeername(279, 0x7f44eec637f0, [112]) = -1 ENOTCONN (Transport endpoint is not connected)
[pid 10905] getpeername(285, 0x7f44eec637f0, [112]) = -1 ENOTCONN (Transport endpoint is not connected)
[pid 10905] getpeername(279, 0x7f44eec637f0, [112]) = -1 ENOTCONN (Transport endpoint is not connected)
[pid 10905] getpeername(285, 0x7f44eec637f0, [112]) = -1 ENOTCONN (Transport endpoint is not connected)
[pid 10905] getpeername(279, 0x7f44eec637f0, [112]) = -1 ENOTCONN (Transport endpoint is not connected)
[pid 10905] getpeername(285, 0x7f44eec637f0, [112]) = -1 ENOTCONN (Transport endpoint is not connected)
[pid 10905] getpeername(279, 0x7f44eec637f0, [112]) = -1 ENOTCONN (Transport endpoint is not connected)
[pid 10905] getpeername(285, 0x7f44eec637f0, [112]) = -1 ENOTCONN (Transport endpoint is not connected)
[pid 10905] getpeername(279, 0x7f44eec637f0, [112]) = -1 ENOTCONN (Transport endpoint is not connected)
[pid 10905] getpeername(285, 0x7f44eec637f0, [112]) = -1 ENOTCONN (Transport endpoint is not connected)
[pid 10905] getpeername(279, 0x7f44eec637f0, [112]) = -1 ENOTCONN (Transport endpoint is not connected)
[pid 10905] getpeername(285, 0x7f44eec637f0, [112]) = -1 ENOTCONN (Transport endpoint is not connected)
[pid 10905] getpeername(279, 0x7f44eec637f0, [112]) = -1 ENOTCONN (Transport endpoint is not connected)
[pid 10905] getpeername(285, 0x7f44eec637f0, [112]) = -1 ENOTCONN (Transport endpoint is not connected)
[pid 10905] getpeername(285, 0x7f44eec637f0, [112]) = -1 ENOTCONN (Transport endpoint is not connected)
[pid 10905] getpeername(285, 0x7f44eec637f0, [112]) = -1 ENOTCONN (Transport endpoint is not connected)
[pid 10905] getpeername(285, 0x7f44eec637f0, [112]) = -1 ENOTCONN (Transport endpoint is not connected)
[pid 10905] getpeername(285, 0x7f44eec637f0, [112]) = -1 ENOTCONN (Transport endpoint is not connected)
[pid 10905] getpeername(285, 0x7f44eec637f0, [112]) = -1 ENOTCONN (Transport endpoint is not connected)
[pid 10905] getpeername(285, 0x7f44eec637f0, [112]) = -1 ENOTCONN (Transport endpoint is not connected)
[pid 10905] <... getpeername resumed> 0x7f44eec637f0, [112]) = -1 ENOTCONN (Transport endpoint is not connected)
[pid 10905] <... getpeername resumed> 0x7f44eec637f0, [112]) = -1 ENOTCONN (Transport endpoint is not connected)
-
Petite question qui n'a peut-être pas de rapport : Je test différentes versions de FF en VM, et lorsque je capture le trafic un paquet sur 2 est un TCP out of order ou un DUP Ack voir des fois des retransmissions.
Est-ce l'accès par pont qui provoque ces erreurs ? Ou elles ne devraient pas se produire ? Je capture à partir de l’hôte et non de la VM.
En tout cas le peu que j'ai testé, toujours pleins de RST, par exemple avec le live d'ubuntu 18.04 (firefox 61)
-
Là ce sont tous les paquets qui semblent être capturés en double.
Est-ce que la capture est bien limitée à l'interface LAN ?
-
Oui, je sélectionne une seule interface à la fois. Dans mon cas enp2s0.
-
d'apres ta trace ce n'est pas firefox qui fait les connections en plus...
-
C'est donc le système qui ouvre ces connexions ?
Vu que ça se produit avec un livecd aussi, pour moi la modification d'un paramètre quelque part me paraît peu probable...
-
Je tiens enfin (peut-être) une piste : J'ai DL une iso d'ubuntu 16.04 avec le noyau 4.4 et FF 47.
Cette fois, j'ai beau redémarrer FF, ouvrir plusieurs onglets, je ne dépasse pas les 6 connexions TCP ouvertes simultanèment. Et à chaque fois que je change de section une seule connexion s'ouvre. On est proche du comportement de chromium.
Alors certes, j'ai toujours des RST, mais ça n'a rien à voir avec la déferlante sur les dernières versions.
-
Ou sinon...
Tu t’installes windows 10, et bienvenue dans le monde des truc qui marchent sans peter les couilles ?
;)
-
Je pense avoir trouvé le coupable : le noyau. Bien vu kgersen ;)
J'ai retesté avec une ubuntu 16.04 mise à jour, conservant le 4.4 mais avec FF 66 et malgré une très longue capture j'ai eu très peu de RST. Alors qu'avec le 4.18, un échange de 30 sec en est rempli.
Je comprends maintenant pourquoi y'a des périodes où tout fonctionnait normalement...
-
Je pense avoir trouvé le problème : le noyau serait en cause.
J'ai retesté avec une ubuntu 16.04 mise à jour, conservant le 4.4 avec FF 66 et malgré une très longue capture j'ai eu très peu de RST. Alors qu'avec le 4.18, un échange de 30 sec, ça en est rempli...
peut-être un souci avec le driver donc. C'est quoi comme carte réseau et la version du driver ?
Pour determiner cela, faire "lspci", chercher la ligne de la carte réseau (en general il y a Ethernet dans la ligne). Noter les chiffres au début de la ligne , par exemple "01:00.0" puis:
lspci -vv -s 01:00.0 | grep "Kernel driver"
cela indique le nom du driver, par exemple "igb" pour certaines cartes Intel.
pour avoir la version du driver:
sudo modinfo igb | grep "^version"
Une méthode plus directe: sudo lshw -C network mais il faut en général installer lshw.
-
J'en profite pour rappeler qu'il y a deux noyaux proposés avec Ubuntu 18.04 / Ubuntu 16.04 / Ubuntu 14.04.
=> Linux 4.18 : gain de performance sur certains serveurs (https://lafibre.info/serveur-linux/linux-4-18/)
Ubuntu 18.04 => Si tu es sur le noyau 4.15 pour passer en 4.18 :
L'installation se fait simplement :
- Ubuntu 18.04 server : sudo apt install --install-recommends linux-generic-hwe-18.04
- Ubuntu 18.04 avec interface graphique : sudo apt install --install-recommends linux-generic-hwe-18.04 xserver-xorg-hwe-18.04
Ubuntu 18.04 => Si tu es sur le noyau 4.18 pour passer en 4.15 :
L'installation se fait simplement :
- Ubuntu 18.04 server : sudo apt install --install-recommends linux-generic
- Ubuntu 18.04 avec interface graphique : sudo apt install --install-recommends linux-generic xserver-xorg
Ubuntu 16.04 => Si tu es sur le noyau 4.4 pour passer en 4.15 :
L'installation se fait simplement :
- Ubuntu 18.04 server : sudo apt install --install-recommends linux-generic-hwe-16.04
- Ubuntu 18.04 avec interface graphique : sudo apt install --install-recommends linux-generic-hwe-16.04 xserver-xorg-hwe-16.04
Ubuntu 16.04 => Si tu es sur le noyau 4.15 pour passer en 4.4 :
L'installation se fait simplement :
- Ubuntu 18.04 server : sudo apt install --install-recommends linux-generic
- Ubuntu 18.04 avec interface graphique : sudo apt install --install-recommends linux-generic xserver-xorg
-
Là j'ai testé avec un autre PC. Je ne suis pas chez moi. Sachant que j'avais déjà essayé sur un portable avec le même résultat et c'était le 4.19 sur debian buster.
D’ailleurs je me suis gouré, la capture c'est le 4.15, pas le 4.18.
Mon PC est équipée d'une realtek driver r8169. Pour la version je te dirais ça en rentrant.
Le PC de test a une intel :
Ethernet controller: Intel Corporation 82579LM Gigabit Network Connection
lspci -vv -s 00:19.0 | grep "Kernel driver"
Kernel driver in use: e1000e
sudo modinfo igb | grep "^version"
version: 5.4.0-k
J'en profite pour rappeler qu'il y a deux noyaux proposés avec Ubuntu 18.04 / Ubuntu 16.04 / Ubuntu 14.04.
Au vu du résultat, je vais charger toutes les versions d'ubuntu intermédiaires, voir à partir de laquelle ça par en cacahuète.
-
Visiblement, ce n'est pas encore ça... Je viens de réessayer la 16.04 après avoir testé la 16.10/4.8, et j'ai de nouveau un déluge de connexions...
Ce n'était donc qu'une coïncidence que me précédente capture soit enfin "normale" :'( D'autres étaient sans doute déjà ouvertes et je n'ai pas assez attendu. Car une fois cette première salve passée, ça en ouvre beaucoup moins.
Ou alors y'a bien un problème de pilote/noyau et c'est du à la VM, puisque c'est l’hôte qui prend tout en charge à l’arrivée... Faut que j'essaie en dur. Mais pas de clé USB sous la main pour le moment.
-
Si tu as 8 Go de ram ou plus, je te conseille de faire un test via des Live-USB : il est possible faire ton surf et prendre la capture avec TCP dump.
Tu la poste sur le forum avant de rebooter, ce qui permet de la sauvegarder (si tu à 16 Go de RAM , il est même possible d'installer Wireshark en ram)
C'est bien d'avoir un environnement neuf qui parle en direct au hardware et pas de la virtualisation.
-
Oui, c'est bien ce que je compte faire ;)
-
On commence avec la 17.10 (4.13) : je dirais ça passe, mais pas sûr à 100%. Quelques RST, mais pas de folie sur le nombre de connexions.
-
J'ai fait une capture avec Ubuntu 19.04 + Firefox 66, elle est en pièce jointe, SFR câble 100 Mb/S en FAI (box F@st 3284 DC, connecté au PC en Ethernet)
J'ai chargé la page d’accueil de lafibre.info sans connexion et avec le cache vidé.
6 connexions sont ouvertes pour le chargement de la page puis refermées sans reset.
Ce qui est étonnant, c'est que le serveur m'a m'a envoyé en fin de connexion des [SYN, ACK] en masse, 46 pour 46 connexion TCP qui j'aurais initiées ([SYN, ACK] est une réponse à un paquet [STN] qui n’apparaît pas dans la capture). Bien sur mon navigateur répond par RESET vu qu'il n'est pas à l'origine de ces connexions.
Une hypothèse, vu les N° de port plus faible, ce seraient des SYN envoyés avant de charger la page et le serveur ferait une nouvelle tentative, mais j'ai un peu de mal à comprendre pourquoi.
Dans tous les cas le pb est bien différent. Là mon navigateur envoi des RESET car il n'est pas à l'origine de la connexion.
-
Bien sur mon navigateur répond par RESET vu qu'il n'est pas à l'origine de ces connexions.
Dans tous les cas le pb est bien différent. Là mon navigateur envoi des RESET car il n'est pas à l'origine de la connexion.
En l’occurrence, c'est plutôt la pile TCP du kernel qui renvoie de RSET (et non le navigateur).
-
Est-ce que tu as démarré la capture assez tôt ?
Je ne sais pas quelles sont les conditions pour que Firefox ouvre des connexions, peut-être que taper l'adresse sans la valider est suffisant.
Ce qui est bizarre, c'est que le PC semble avoir fermé les connexions sans que le serveur soit au courant (ou alors il ne les a jamais ouvertes, et le serveur a un gros bug).
-
J'utilisait activement mon navigateur avant. J'ai vidé le cache je l'ai fermé.
J'ai alors démarrer le navigateur, puis la capture puis mis l'adresse du site.
Mon hypothèses c'est que ce sont de vieux SYN où faute de réponse le serveur renvoi son paquet plusieurs secondes aprés, mais cela fait beaucoup...
-
Tu as essayé de désactiver temporairement le TCP timestamp côté PC navigateur pour voir si ça élimine ces TCP SYN ACK à retard du serveur (sysctl -w net.ipv4.tcp_timestamps=0) ?
Apparemment il peut y avoir confusion dans les connexions si du NAT est présent avec TCP timestamp.
https://serverfault.com/questions/235965/why-would-a-server-not-send-a-syn-ack-packet-in-response-to-a-syn-packet (https://serverfault.com/questions/235965/why-would-a-server-not-send-a-syn-ack-packet-in-response-to-a-syn-packet)
-
J'en ai aussi de mon côté ( des SYN ACK) .
Sinon, j'ai continué avec la 17.04 et je note un truc bizarre : malgré un nombre de connexions correct (pas plus de de 6-7 à la fois) j'ai vers le milieu de la capture une longue liste de RST... est-ce parce que les connexions qui étaient déjà ouvertes sont trop nombreuses ? Comme quand ça en ouvre à la chaîne en somme. Donc pour le coup ce comportement est normal ?
Aurai-je enfin trouvé une version du kernel qui ne bug pas ?
EDIT : 23 Mo de capture... j'ai un peu abusé ce coup si ;D
-
pour être certain que c'est firefox (ou savoir quelle partie de firefox), un audit serait le bienvenue:
#install
sudo apt install auditd
#démarrage capture
sudo auditctl -D
sudo auditctl -a exit,always -F arch=b64 -S connect -k HMOK
*** faire le chargement de https://lafibre.info depuis firefox
#arret capture
sudo auditctl -D
#affichage
sudo ausearch -k HMOK
une fois terminé, il est recommandé d’arrêter et désactiver le service d'audit:
sudo systemctl stop auditd.service
sudo systemctl disable auditd.service
-
Voici le résultat :
renaud@renaud-pc:~$ sudo ausearch -k HMOK
----
time->Mon May 13 20:38:12 2019
type=CONFIG_CHANGE msg=audit(1557772692.819:42): auid=4294967295 ses=4294967295 op=add_rule key="HMOK" list=4 res=1
----
time->Mon May 13 20:38:19 2019
type=PROCTITLE msg=audit(1557772699.831:46): proctitle=2F7573722F6C69622F66697265666F782F66697265666F78002D636F6E74656E7470726F63002D6368696C644944003138002D6973466F7242726F77736572002D70726566734C656E0038303338002D707265664D617053697A6500313831343734002D706172656E744275696C644944003230313930353036313030383334
type=SOCKADDR msg=audit(1557772699.831:46): saddr=0100002F746D702F2E5831312D756E69782F5830
type=SYSCALL msg=audit(1557772699.831:46): arch=c000003e syscall=42 success=no exit=-111 a0=9 a1=7fff25fed1d0 a2=14 a3=58 items=0 ppid=2227 pid=19555 auid=4294967295 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=(none) ses=4294967295 comm="firefox" exe="/usr/lib/firefox/firefox" key="HMOK"
----
time->Mon May 13 20:38:19 2019
type=PROCTITLE msg=audit(1557772699.831:45): proctitle=2F7573722F6C69622F66697265666F782F66697265666F78002D636F6E74656E7470726F63002D6368696C644944003138002D6973466F7242726F77736572002D70726566734C656E0038303338002D707265664D617053697A6500313831343734002D706172656E744275696C644944003230313930353036313030383334
type=PATH msg=audit(1557772699.831:45): item=0 name="/run/user/1000/wayland-0" nametype=UNKNOWN cap_fp=0000000000000000 cap_fi=0000000000000000 cap_fe=0 cap_fver=0
type=CWD msg=audit(1557772699.831:45): cwd="/home/renaud"
type=SOCKADDR msg=audit(1557772699.831:45): saddr=01002F72756E2F757365722F313030302F7761796C616E642D3000
type=SYSCALL msg=audit(1557772699.831:45): arch=c000003e syscall=42 success=no exit=-2 a0=9 a1=7fff25fed3e0 a2=1b a3=58 items=1 ppid=2227 pid=19555 auid=4294967295 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=(none) ses=4294967295 comm="firefox" exe="/usr/lib/firefox/firefox" key="HMOK"
----
time->Mon May 13 20:38:19 2019
type=PROCTITLE msg=audit(1557772699.831:47): proctitle=2F7573722F6C69622F66697265666F782F66697265666F78002D636F6E74656E7470726F63002D6368696C644944003138002D6973466F7242726F77736572002D70726566734C656E0038303338002D707265664D617053697A6500313831343734002D706172656E744275696C644944003230313930353036313030383334
type=PATH msg=audit(1557772699.831:47): item=0 name="/tmp/.X11-unix/X0" inode=262778 dev=08:05 mode=0140777 ouid=0 ogid=0 rdev=00:00 nametype=NORMAL cap_fp=0000000000000000 cap_fi=0000000000000000 cap_fe=0 cap_fver=0
type=CWD msg=audit(1557772699.831:47): cwd="/home/renaud"
type=SOCKADDR msg=audit(1557772699.831:47): saddr=01002F746D702F2E5831312D756E69782F583000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
type=SYSCALL msg=audit(1557772699.831:47): arch=c000003e syscall=42 success=yes exit=0 a0=9 a1=7fff25fed1d0 a2=6e a3=7fff25fed1b0 items=1 ppid=2227 pid=19555 auid=4294967295 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=(none) ses=4294967295 comm="firefox" exe="/usr/lib/firefox/firefox" key="HMOK"
----
time->Mon May 13 20:38:19 2019
type=PROCTITLE msg=audit(1557772699.839:48): proctitle=2F7573722F6C69622F66697265666F782F66697265666F78002D636F6E74656E7470726F63002D6368696C644944003138002D6973466F7242726F77736572002D70726566734C656E0038303338002D707265664D617053697A6500313831343734002D706172656E744275696C644944003230313930353036313030383334
type=PATH msg=audit(1557772699.839:48): item=0 name="/run/user/1000/bus" inode=12 dev=00:35 mode=0140666 ouid=1000 ogid=1000 rdev=00:00 nametype=NORMAL cap_fp=0000000000000000 cap_fi=0000000000000000 cap_fe=0 cap_fver=0
type=CWD msg=audit(1557772699.839:48): cwd="/home/renaud"
type=SOCKADDR msg=audit(1557772699.839:48): saddr=01002F72756E2F757365722F313030302F627573000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
type=SYSCALL msg=audit(1557772699.839:48): arch=c000003e syscall=42 success=yes exit=0 a0=16 a1=7fff25fec690 a2=6e a3=0 items=1 ppid=2227 pid=19555 auid=4294967295 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=(none) ses=4294967295 comm="firefox" exe="/usr/lib/firefox/firefox" key="HMOK"
----
time->Mon May 13 20:38:21 2019
type=PROCTITLE msg=audit(1557772701.971:119): proctitle=2F7573722F6C69622F66697265666F782F66697265666F78002D636F6E74656E7470726F63002D6368696C644944003139002D6973466F7242726F77736572002D70726566734C656E0038303338002D707265664D617053697A6500313831343734002D706172656E744275696C644944003230313930353036313030383334
type=PATH msg=audit(1557772701.971:119): item=0 name="/run/user/1000/wayland-0" nametype=UNKNOWN cap_fp=0000000000000000 cap_fi=0000000000000000 cap_fe=0 cap_fver=0
type=CWD msg=audit(1557772701.971:119): cwd="/home/renaud"
type=SOCKADDR msg=audit(1557772701.971:119): saddr=01002F72756E2F757365722F313030302F7761796C616E642D3000
type=SYSCALL msg=audit(1557772701.971:119): arch=c000003e syscall=42 success=no exit=-2 a0=9 a1=7ffce6c57d10 a2=1b a3=58 items=1 ppid=2227 pid=19603 auid=4294967295 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=(none) ses=4294967295 comm="firefox" exe="/usr/lib/firefox/firefox" key="HMOK"
----
time->Mon May 13 20:38:21 2019
type=PROCTITLE msg=audit(1557772701.971:120): proctitle=2F7573722F6C69622F66697265666F782F66697265666F78002D636F6E74656E7470726F63002D6368696C644944003139002D6973466F7242726F77736572002D70726566734C656E0038303338002D707265664D617053697A6500313831343734002D706172656E744275696C644944003230313930353036313030383334
type=SOCKADDR msg=audit(1557772701.971:120): saddr=0100002F746D702F2E5831312D756E69782F5830
type=SYSCALL msg=audit(1557772701.971:120): arch=c000003e syscall=42 success=no exit=-111 a0=9 a1=7ffce6c57b00 a2=14 a3=58 items=0 ppid=2227 pid=19603 auid=4294967295 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=(none) ses=4294967295 comm="firefox" exe="/usr/lib/firefox/firefox" key="HMOK"
----
time->Mon May 13 20:38:21 2019
type=PROCTITLE msg=audit(1557772701.971:121): proctitle=2F7573722F6C69622F66697265666F782F66697265666F78002D636F6E74656E7470726F63002D6368696C644944003139002D6973466F7242726F77736572002D70726566734C656E0038303338002D707265664D617053697A6500313831343734002D706172656E744275696C644944003230313930353036313030383334
type=PATH msg=audit(1557772701.971:121): item=0 name="/tmp/.X11-unix/X0" inode=262778 dev=08:05 mode=0140777 ouid=0 ogid=0 rdev=00:00 nametype=NORMAL cap_fp=0000000000000000 cap_fi=0000000000000000 cap_fe=0 cap_fver=0
type=CWD msg=audit(1557772701.971:121): cwd="/home/renaud"
type=SOCKADDR msg=audit(1557772701.971:121): saddr=01002F746D702F2E5831312D756E69782F583000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
type=SYSCALL msg=audit(1557772701.971:121): arch=c000003e syscall=42 success=yes exit=0 a0=9 a1=7ffce6c57b00 a2=6e a3=7ffce6c57ae0 items=1 ppid=2227 pid=19603 auid=4294967295 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=(none) ses=4294967295 comm="firefox" exe="/usr/lib/firefox/firefox" key="HMOK"
----
time->Mon May 13 20:38:21 2019
type=PROCTITLE msg=audit(1557772701.979:122): proctitle=2F7573722F6C69622F66697265666F782F66697265666F78002D636F6E74656E7470726F63002D6368696C644944003139002D6973466F7242726F77736572002D70726566734C656E0038303338002D707265664D617053697A6500313831343734002D706172656E744275696C644944003230313930353036313030383334
type=PATH msg=audit(1557772701.979:122): item=0 name="/run/user/1000/bus" inode=12 dev=00:35 mode=0140666 ouid=1000 ogid=1000 rdev=00:00 nametype=NORMAL cap_fp=0000000000000000 cap_fi=0000000000000000 cap_fe=0 cap_fver=0
type=CWD msg=audit(1557772701.979:122): cwd="/home/renaud"
type=SOCKADDR msg=audit(1557772701.979:122): saddr=01002F72756E2F757365722F313030302F627573000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
type=SYSCALL msg=audit(1557772701.979:122): arch=c000003e syscall=42 success=yes exit=0 a0=16 a1=7ffce6c56fc0 a2=6e a3=0 items=1 ppid=2227 pid=19603 auid=4294967295 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=(none) ses=4294967295 comm="firefox" exe="/usr/lib/firefox/firefox" key="HMOK"
----
time->Mon May 13 20:38:28 2019
type=PROCTITLE msg=audit(1557772708.907:124): proctitle=7375646F00617564697463746C002D44
type=PATH msg=audit(1557772708.907:124): item=0 name="/var/run/nscd/socket" nametype=UNKNOWN cap_fp=0000000000000000 cap_fi=0000000000000000 cap_fe=0 cap_fver=0
type=CWD msg=audit(1557772708.907:124): cwd="/home/renaud"
type=SOCKADDR msg=audit(1557772708.907:124): saddr=01002F7661722F72756E2F6E7363642F736F636B657400000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000FFFFFF
type=SYSCALL msg=audit(1557772708.907:124): arch=c000003e syscall=42 success=no exit=-2 a0=3 a1=7ffd7d5b8ac0 a2=6e a3=6 items=1 ppid=18814 pid=19632 auid=4294967295 uid=1000 gid=1000 euid=0 suid=0 fsuid=0 egid=1000 sgid=1000 fsgid=1000 tty=pts5 ses=4294967295 comm="sudo" exe="/usr/bin/sudo" key="HMOK"
----
time->Mon May 13 20:38:28 2019
type=PROCTITLE msg=audit(1557772708.907:125): proctitle=7375646F00617564697463746C002D44
type=PATH msg=audit(1557772708.907:125): item=0 name="/var/run/nscd/socket" nametype=UNKNOWN cap_fp=0000000000000000 cap_fi=0000000000000000 cap_fe=0 cap_fver=0
type=CWD msg=audit(1557772708.907:125): cwd="/home/renaud"
type=SOCKADDR msg=audit(1557772708.907:125): saddr=01002F7661722F72756E2F6E7363642F736F636B657400000000000008001F0001000000080028002000000000000000C8FEFFFFFFFFFFFF090000000000000030915B7DFD7F000056915B7DFD7F000050915B7DFD7F0000FCF06D81557F00000000000008002F00000000000800
type=SYSCALL msg=audit(1557772708.907:125): arch=c000003e syscall=42 success=no exit=-2 a0=4 a1=7ffd7d5b9010 a2=6e a3=6 items=1 ppid=18814 pid=19632 auid=4294967295 uid=0 gid=1000 euid=0 suid=0 fsuid=0 egid=0 sgid=1000 fsgid=0 tty=pts5 ses=4294967295 comm="sudo" exe="/usr/bin/sudo" key="HMOK"
----
time->Mon May 13 20:38:28 2019
type=PROCTITLE msg=audit(1557772708.907:126): proctitle=7375646F00617564697463746C002D44
type=PATH msg=audit(1557772708.907:126): item=0 name="/var/run/nscd/socket" nametype=UNKNOWN cap_fp=0000000000000000 cap_fi=0000000000000000 cap_fe=0 cap_fver=0
type=CWD msg=audit(1557772708.907:126): cwd="/home/renaud"
type=SOCKADDR msg=audit(1557772708.907:126): saddr=01002F7661722F72756E2F6E7363642F736F636B657400000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000C002B000500020000000000EC021A0084000200800001000000000000000000000000000100
type=SYSCALL msg=audit(1557772708.907:126): arch=c000003e syscall=42 success=no exit=-2 a0=4 a1=7ffd7d5b91a0 a2=6e a3=6 items=1 ppid=18814 pid=19632 auid=4294967295 uid=0 gid=1000 euid=0 suid=0 fsuid=0 egid=0 sgid=1000 fsgid=0 tty=pts5 ses=4294967295 comm="sudo" exe="/usr/bin/sudo" key="HMOK"
----
time->Mon May 13 20:38:28 2019
type=PROCTITLE msg=audit(1557772708.907:127): proctitle=7375646F00617564697463746C002D44
type=PATH msg=audit(1557772708.907:127): item=0 name="/var/run/nscd/socket" nametype=UNKNOWN cap_fp=0000000000000000 cap_fi=0000000000000000 cap_fe=0 cap_fver=0
type=CWD msg=audit(1557772708.907:127): cwd="/home/renaud"
type=SOCKADDR msg=audit(1557772708.907:127): saddr=01002F7661722F72756E2F6E7363642F736F636B65740000020000001100000000000000FD7F000040945B7D07000000F707A581557F000050945B7DFD7F0000F0935B7DFD7F00000100000006000000000000000000000000EB71EDF3ED3C1BD8C2B31AAA550000030000000000
type=SYSCALL msg=audit(1557772708.907:127): arch=c000003e syscall=42 success=no exit=-2 a0=4 a1=7ffd7d5b93e0 a2=6e a3=6 items=1 ppid=18814 pid=19632 auid=4294967295 uid=1000 gid=1000 euid=0 suid=0 fsuid=0 egid=0 sgid=1000 fsgid=0 tty=pts5 ses=4294967295 comm="sudo" exe="/usr/bin/sudo" key="HMOK"
----
time->Mon May 13 20:38:28 2019
type=PROCTITLE msg=audit(1557772708.907:128): proctitle=7375646F00617564697463746C002D44
type=PATH msg=audit(1557772708.907:128): item=0 name="/var/run/nscd/socket" nametype=UNKNOWN cap_fp=0000000000000000 cap_fi=0000000000000000 cap_fe=0 cap_fver=0
type=CWD msg=audit(1557772708.907:128): cwd="/home/renaud"
type=SOCKADDR msg=audit(1557772708.907:128): saddr=01002F7661722F72756E2F6E7363642F736F636B65740000AFA7937F557F00000063B77F557F0000C859B31AAA550000010000000000000000000000000000000100000000000000D3A9A481557F00008E091C80557F0000D3A9A481557F0000C607A581557F0000D3A9A4810700
type=SYSCALL msg=audit(1557772708.907:128): arch=c000003e syscall=42 success=no exit=-2 a0=4 a1=7ffd7d5b9570 a2=6e a3=6 items=1 ppid=18814 pid=19632 auid=4294967295 uid=1000 gid=1000 euid=0 suid=0 fsuid=0 egid=0 sgid=1000 fsgid=0 tty=pts5 ses=4294967295 comm="sudo" exe="/usr/bin/sudo" key="HMOK"
----
time->Mon May 13 20:38:28 2019
type=PROCTITLE msg=audit(1557772708.911:129): proctitle=7375646F00617564697463746C002D44
type=PATH msg=audit(1557772708.911:129): item=0 name="/dev/log" inode=489 dev=00:17 mode=0140666 ouid=0 ogid=0 rdev=00:00 nametype=NORMAL cap_fp=0000000000000000 cap_fi=0000000000000000 cap_fe=0 cap_fver=0
type=CWD msg=audit(1557772708.911:129): cwd="/home/renaud"
type=SOCKADDR msg=audit(1557772708.911:129): saddr=01002F6465762F6C6F6700000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
type=SYSCALL msg=audit(1557772708.911:129): arch=c000003e syscall=42 success=yes exit=0 a0=4 a1=7f5581a362a0 a2=6e a3=414d4d4f43203b20 items=1 ppid=18814 pid=19632 auid=4294967295 uid=0 gid=1000 euid=0 suid=0 fsuid=0 egid=0 sgid=1000 fsgid=0 tty=pts5 ses=4294967295 comm="sudo" exe="/usr/bin/sudo" key="HMOK"
----
time->Mon May 13 20:38:28 2019
type=PROCTITLE msg=audit(1557772708.911:132): proctitle=7375646F00617564697463746C002D44
type=PATH msg=audit(1557772708.911:132): item=0 name="/dev/log" inode=489 dev=00:17 mode=0140666 ouid=0 ogid=0 rdev=00:00 nametype=NORMAL cap_fp=0000000000000000 cap_fi=0000000000000000 cap_fe=0 cap_fver=0
type=CWD msg=audit(1557772708.911:132): cwd="/home/renaud"
type=SOCKADDR msg=audit(1557772708.911:132): saddr=01002F6465762F6C6F6700000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
type=SYSCALL msg=audit(1557772708.911:132): arch=c000003e syscall=42 success=yes exit=0 a0=4 a1=7f5581a362a0 a2=6e a3=662064656e65706f items=1 ppid=18814 pid=19632 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts5 ses=4294967295 comm="sudo" exe="/usr/bin/sudo" key="HMOK"
----
time->Mon May 13 20:38:28 2019
type=CONFIG_CHANGE msg=audit(1557772708.915:134): auid=4294967295 ses=4294967295 op=remove_rule key="HMOK" list=4 res=1
----
time->Mon May 13 20:38:28 2019
type=PROCTITLE msg=audit(1557772708.907:123): proctitle=7375646F00617564697463746C002D44
type=PATH msg=audit(1557772708.907:123): item=0 name="/var/run/nscd/socket" nametype=UNKNOWN cap_fp=0000000000000000 cap_fi=0000000000000000 cap_fe=0 cap_fver=0
type=CWD msg=audit(1557772708.907:123): cwd="/home/renaud"
type=SOCKADDR msg=audit(1557772708.907:123): saddr=01002F7661722F72756E2F6E7363642F736F636B65740000000000000100000080895B7DFD7F000090895B7DFD7F000038774E82557F0000000000000000000000000000000000000000000000000000FFFFFFFF00000000000000000000000000EF6481557F0000E0734E82557F
type=SYSCALL msg=audit(1557772708.907:123): arch=c000003e syscall=42 success=no exit=-2 a0=3 a1=7ffd7d5b8930 a2=6e a3=6 items=1 ppid=18814 pid=19632 auid=4294967295 uid=1000 gid=1000 euid=0 suid=0 fsuid=0 egid=1000 sgid=1000 fsgid=1000 tty=pts5 ses=4294967295 comm="sudo" exe="/usr/bin/sudo" key="HMOK"
Par contre lorsque je tapais auditd -D j'avais comme retour "No rules" normal ?
-
https://serverfault.com/questions/235965/why-would-a-server-not-send-a-syn-ack-packet-in-response-to-a-syn-packet (https://serverfault.com/questions/235965/why-would-a-server-not-send-a-syn-ack-packet-in-response-to-a-syn-packet)
Il y a un lien intéressant : https://vincent.bernat.ch/en/blog/2014-tcp-time-wait-state-linux
Il faudrait vérifier si :
- le client n'a pas net.ipv4.tcp_tw_reuse ou net.ipv4.tcp_tw_recycle
- le serveur lafibre.info n'a pas net.ipv4.tcp_tw_recycle
-
Par contre lorsque je tapais auditd -D j'avais comme retour "No rules" normal ?
oui c'est normal, -D enleve toutes les regles d'audit.
cat ton-resultat | grep firefox | cut -f5,6,13 -d' ' donne:
success=no exit=-111 pid=19555
success=no exit=-2 pid=19555
success=yes exit=0 pid=19555
success=yes exit=0 pid=19555
success=no exit=-2 pid=19603
success=no exit=-111 pid=19603
success=yes exit=0 pid=19603
success=yes exit=0 pid=19603
t'as donc 2 process firefox différents. Regarde avec le task manager de ff ou "pgrep -a firefox" a quoi ils correspondent (un c'est l'onglet de la page mais l'autre peut-etre une extension ou autre).
Le mieux est dans doute un strace avec tout les pid de firefox:
sudo strace -e trace=network $(pidof firefox |sed 's/\([0-9]*\)/\-p \1/g')
-
Si je regarde la capture Firefox du post #4 (https://lafibre.info/navigateurs/firerox-reset/msg650511/#msg650511), je vois :
- SYN, SYN+ACK, RST : le client semble fermer la connexion immédiatement
- des connexions qui échangent des données, mais que le client ferme proprement avant la fin (Encrypted Altert + FIN,ACK), et sur lesquelles il continue de recevoir des données (donc il envoie des RST à chaque nouveau paquet reçu) : le serveur avait probablement tout envoyé avant que le client ferme la connexion (latence)
Le premier cas est le plus étrange, mais le second cas reste bizarre car je m'attendrais plus à un client qui garde la connexion ouverte pour faire plusieurs requêtes (comme c'est du TLS, je ne sais pas pourquoi il annule avant d'avoir reçu la totalité de la réponse du serveur).
-
Bon, j'ai bien avancé : le problème est facilement reproductible avec plusieurs PC différents équipés d'Ubuntu 19.04 (noyau Linux 5.0.0-13, Firefox 66.0.5).
Coté serveur, lafibre.info exploite un Ubuntu server 16.04 avec la configuration par défaut excepté ça :
# Reduce the swap
vm.swappiness = 5
# Reduce the threshold where a DDOS impacts the server
net.ipv4.tcp_max_syn_backlog = 2048
# TCP congestion control protocol for high-speed and long-distance networks
net.ipv4.tcp_congestion_control=illinois
# Increase TCP buffers
net.ipv4.tcp_rmem=4096 87380 16777216
net.ipv4.tcp_wmem=4096 65536 16777216
net.core.rmem_max=851968
net.core.wmem_max=851968
# default queuing discipline for 10GigE speeds
net.core.default_qdisc=fq
# Increase the queue within the Linux kernel where traffic is stored after reception from the NIC
net.core.netdev_max_backlog=4000
# Increase number of incoming connections
net.core.somaxconn = 512
# Ignorer les paquets Router Advertisement si IPv6 configuré manuellement
net.ipv6.conf.all.autoconf = 0
net.ipv6.conf.all.accept_ra = 0
net.ipv6.conf.all.accept_dad = 0
net.ipv6.conf.default.autoconf = 0
net.ipv6.conf.default.accept_ra = 0
net.ipv6.conf.default.accept_dad = 0
Pour le PC avec les captures ci-dessous, la carte réseau est une Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller.
La Box est une box SFR câble 100 Mb/s, modem Sagem F@st 3284 DC, version logiciel NCC-PC20_2.146.0
Capture coté client : 201905_lafibre_capture_client.pcapng.gz (https://lafibre.info/images/wireshark/201905_lafibre_capture_client.pcapng.gz)
Capture coté serveur : 201905_lafibre_capture_serveur.pcapng.gz (https://lafibre.info/images/wireshark/201905_lafibre_capture_serveur.pcapng.gz)
Les fichiers sont lisibles directement avec Wireshark.
-
Exemple de la connexion TCP sur le port 50484 :
Coté client :
(https://lafibre.info/images/wireshark/201905_lafibre_capture_client_50484.png)
Coté serveur :
(https://lafibre.info/images/wireshark/201905_lafibre_capture_serveur_50484.png)
On note que le serveur n'a pas reçu les reset d'où la retransmission de paquet qu'il considère perdu faite d’acquittement.
-
Exemple de la connexion TCP sur le port 50472 :
Coté client :
(https://lafibre.info/images/wireshark/201905_lafibre_capture_client_50472.png)
Coté serveur :
(https://lafibre.info/images/wireshark/201905_lafibre_capture_serveur_50472.png)
On note que le serveur n'a reçu que le premier reset.
-
On garde cette même connexion TCP sur le port 50472 en filtrant dans le sens download :
Coté client :
(https://lafibre.info/images/wireshark/201905_lafibre_capture_client_50472_down.png)
Coté serveur :
(https://lafibre.info/images/wireshark/201905_lafibre_capture_serveur_50472_down.png)
Tous les paquets sont bien là, sauf le deux dernier paquets retransmis (à T= 30 secondes et T= 60 secondes) ne sont pas reçus par le client, probablement que la box SFR a supprimé cette connexion de sa table qu'elle doit concerner comme terminée.
-
On garde cette même connexion TCP sur le port 50472 en filtrant dans le sens upload :
Coté client :
(https://lafibre.info/images/wireshark/201905_lafibre_capture_client_50472_up.png)
Coté serveur :
(https://lafibre.info/images/wireshark/201905_lafibre_capture_serveur_50472_up.png)
Tous les paquets sont bien là, mais il n'y a plus rien après le premier reset envoyé par le client.
A qui la faute de cette perte ?
-
Sur Fedora 29 (Firefox 66.0.5, Linux 5.0.8 ), j'ai bien 6 connexions, et juste des RST à la fin du chargement :
- une connexion où le client reçoit encore des données (TLS Application Data, 1378 octets) après avoir fermé proprement
- les 5 autres où il reçoit juste des Encrypted Alert / FIN,ACK / ACK / FIN+ACK (auquels il répond 4 RST) : le serveur semble vouloir fermer la connexion TCP de sa propre initiative, probablement à cause de l'Encrypted Altert qu'il a reçu (le client a terminé l'échange TLS), alors que le client l'a déjà terminée.
-
On note que le serveur n'a pas reçu les reset d'où la retransmission de paquet qu'il considère perdu faite d’acquittement.[/size]
En effet, bizarre.
Il y a peut-être quelque chose qui ne plait pas au client dans la réponse du serveur, mais ça n'explique pas que le RST n'arrive pas au serveur (la box ?).
On note que le serveur n'a reçu que le premier reset.[/size]
Dans mon cas je n'ai que la première retransmission du serveur (ce qui ne veut pas dire qu'il n'y en a pas d'autres, potentiellement éliminées par la box).
Le client et le serveur ont fermé la connexion TCP en même temps, chacun de son initiative.
Ca génère le premier RST côté client, mais autant dans mon cas avec la latence je ne suis pas 100% sûr, autant dans ton cas je ne comprends pas pourquoi le serveur persiste après l'avoir reçu.
Sur un test simple, openssl s_client server:433, Ctrl+C (le client termine la connexion TCP, sans même avoir envoyé d'Encrypted Alert SSL) :
- sur lafibre.info ou apache.org :
=> FIN,ACK
<= Encrypted Alert
=> RST
<= FIN, ACK
=> RST
- sur www.google.fr, mozilla.org, mon nginx en local :
=> FIN,ACK
<= FIN,ACK
=> ACK
La premier cas est un peu moins élégant, mais tant que ça s'arrête là (pas de retransmission à priori, à moins que ce soit filtré par ma NB6V) ce n'est pas grave car ça ne fait qu'un petit paquet en plus dans chaque sens.
-
t'as donc 2 process firefox différents. Regarde avec le task manager de ff ou "pgrep -a firefox" a quoi ils correspondent (un c'est l'onglet de la page mais l'autre peut-etre une extension ou autre).
Le mieux est dans doute un strace avec tout les pid de firefox:
sudo strace -e trace=network $(pidof firefox |sed 's/\([0-9]*\)/\-p \1/g')
Lors de la capture j'avais l'onglet du topic ouvert pour copier les commandes. Cela dit quand je fais un pgrep même avec plusieurs onglets j'ai un seul PID qui sort...
Et dans le task manager, je vois ublock ainsi que le correctif pour les extentions c'est peut-être ça ?
EDIT : j'ai refais un essai avec 2 onglets. L'un est le processus principal de FF l'autre est un des onglets mais il n’apparaît pas avec un pgrep, je ne le vois que dans le moniteur système.
Résultat :
success=yes exit=0 pid=2227
success=no exit=-2 pid=1225
success=no exit=-111 pid=1225
success=yes exit=0 pid=1225
success=yes exit=0 pid=1225
success=yes exit=0 pid=2227
success=yes exit=0 pid=2227
A noter que j'ai 3 "web content" alors que je n'ai que 2 onglets... peut-être qu'un est "confondu" avec le PID principal ?
-
J'ai viens de réessayer comme il faut avec un seul onglet : J'ai bien un seul PID. L'autre était donc bien le second onglet.
success=yes exit=0 pid=2921
success=yes exit=0 pid=2921
success=no exit=-101 pid=2921
success=no exit=-115 pid=2921
success=no exit=-115 pid=2921
success=no exit=-115 pid=2921
success=no exit=-115 pid=2921
success=no exit=-115 pid=2921
success=no exit=-115 pid=2921
success=no exit=-115 pid=2921
success=no exit=-115 pid=2921
success=no exit=-115 pid=2921
success=no exit=-115 pid=2921
success=no exit=-115 pid=2921
success=no exit=-115 pid=2921
success=no exit=-115 pid=2921
success=no exit=-115 pid=2921
success=no exit=-115 pid=2921
success=no exit=-115 pid=2921
success=no exit=-115 pid=2921
success=no exit=-115 pid=2921
success=no exit=-115 pid=2921
success=no exit=-115 pid=2921
success=no exit=-115 pid=2921
success=no exit=-115 pid=2921
success=no exit=-115 pid=2921
success=no exit=-115 pid=2921
success=no exit=-115 pid=2921
success=no exit=-115 pid=2921
success=no exit=-115 pid=2921
success=no exit=-115 pid=2921
success=no exit=-115 pid=2921
success=no exit=-115 pid=2921
success=no exit=-115 pid=2921
success=no exit=-115 pid=2921
success=no exit=-115 pid=2921
success=no exit=-115 pid=2921
success=no exit=-115 pid=2921
success=no exit=-115 pid=2921
success=no exit=-115 pid=2921
success=no exit=-115 pid=2921
success=no exit=-115 pid=2921
success=no exit=-115 pid=2921
success=no exit=-115 pid=2921
success=no exit=-115 pid=2921
success=no exit=-115 pid=2921
success=no exit=-115 pid=2921
success=no exit=-115 pid=2921
success=no exit=-115 pid=2921
success=no exit=-115 pid=2921
success=no exit=-115 pid=2921
success=no exit=-115 pid=2921
success=no exit=-115 pid=2921
success=no exit=-115 pid=2921
success=no exit=-115 pid=2921
success=no exit=-115 pid=2921
success=no exit=-115 pid=2921
success=no exit=-115 pid=2921
success=no exit=-115 pid=2921
success=no exit=-115 pid=2921
success=no exit=-115 pid=2921
success=no exit=-115 pid=2921
success=no exit=-115 pid=2921
success=no exit=-115 pid=2921
success=no exit=-115 pid=2921
success=no exit=-115 pid=2921
success=no exit=-115 pid=2921
success=no exit=-115 pid=2921
success=no exit=-115 pid=2921
success=no exit=-115 pid=2921
success=no exit=-115 pid=2921
success=no exit=-115 pid=2921
success=no exit=-115 pid=2921
success=no exit=-115 pid=2921
success=no exit=-115 pid=2921
success=no exit=-115 pid=2921
success=no exit=-115 pid=2921
success=no exit=-115 pid=2921
success=no exit=-115 pid=2921
success=no exit=-115 pid=2921
success=no exit=-115 pid=2921
success=no exit=-115 pid=2921
success=no exit=-115 pid=2921
success=no exit=-115 pid=2921
success=no exit=-115 pid=2921
success=no exit=-115 pid=2921
success=no exit=-115 pid=2921
success=no exit=-115 pid=2921
success=no exit=-115 pid=2921
success=no exit=-115 pid=2921
success=no exit=-115 pid=2921
success=no exit=-115 pid=2921
success=no exit=-115 pid=2921
success=no exit=-115 pid=2921
success=no exit=-115 pid=2921
success=no exit=-115 pid=2921
success=no exit=-115 pid=2921
success=no exit=-115 pid=2921
success=no exit=-115 pid=2921
success=no exit=-115 pid=2921
success=no exit=-115 pid=2921
success=no exit=-115 pid=2921
success=no exit=-115 pid=2921
success=no exit=-115 pid=2921
success=no exit=-115 pid=2921
success=no exit=-115 pid=2921
success=no exit=-115 pid=2921
success=no exit=-115 pid=2921
Le dernier se répète près d'un centaine de fois :o A noter que pour le précédent essai le success=yes exit=0 pid=2227 se répétait aussi une trentaine de fois.
-
Autre PC ou c'est reproductible:
- Ubuntu 19.04 (noyau Linux 5.0.0-13, Firefox 66.0.5).
- Intel Core i7-2600 @ 3.40GHz
- Connecté en Wi-Fi via Intel Corporation Wireless 7265
- Accès internet fibre avec du matériel pro
Capture coté client : 201905_lafibre_capture_client.pcapng.gz (https://lafibre.info/images/wireshark/201905_lafibre_capture2_client.pcapng.gz)
Le fichier est lisible directement avec Wireshark.
On voit que le nombre de connexions ouverte est vraiment important :
(https://lafibre.info/images/wireshark/201905_lafibre_capture2_client_1.png)
Avec plein de reset immédiatement :
(https://lafibre.info/images/wireshark/201905_lafibre_capture2_client_2.png)
A noter que sur mes deux PC, VirtualBox 6.0.6 est installé (mais non utilisé au moment où j'ai fait la capture)
Je me demande si le module kernel installé par VirtualBox pourrait avoir un impact.
-
On dirait plutôt que les RST correspondent aux SYN ACK, non ?
Je suis aussi en 66.0.5 depuis hier, mais chez moi pas de SYN ACK, juste un gros paquet de SYN (comme d'hab) puis les RST... Virtualbox est également installé et non utilisé.
Maintenant que j'y pense, c'est peut-être pour ça que j'ai de temps en temps des alertes google qui me bloquent en détectant un fort trafic, comme si j'étais catégorisé hébergeur. Que je me suis dit plusieurs fois : ça y est il a pété un câble... ::)
-
Si tu as immédiatement après un [SYN], le serveur répond [SYN-ACK] par contre dans ta capture, les reset ne sont pas envoyés au fur et à mesure que les [SYN-ACK] arrivent mais bien après.
Pour filtrer ta capture afin de voir uniquement les SYN, SYN-ACK et RST pour le serveur de lafibre.info, voici ce qu'il faut rentrer dans la base de Wireshark :
ip.addr == 46.227.16.8 && (tcp.flags.syn==1 || tcp.flags.reset==1)
-
Ah, avec cette syntaxe, on y voit plus clair, dans la capture que je viens de faire, y'a un mélange des deux : SYN puis RST et SYN-ACK/RST.
Je vais tester le 4.18 a tout hasard, bien que j'y crois pas trop...
-
Kernel 4.18 installé : toujours au même point...
EDIT : Oulala... j'ai plus de son ! Aussi je trouvais que ça sentait mauvais ces lignes failed au démarrage...
Allez hop, retour au 4.15.
-
A noter que sur mes deux PC, VirtualBox 6.0.6 est installé (mais non utilisé au moment où j'ai fait la capture)
Je me demande si le module kernel installé par VirtualBox pourrait avoir un impact.
Côté kernel il y a :
- vboxnetflt : bridge, à tester (sur un bridge les VM ont des IP différentes, mais on ne sait jamais)
- vboxnetadp : host-only, à priori ce n'est pas ça
- le processus VBoxNetNAT (comme il est en setuid, peut-être qu'il ouvre directement les interfaces, et répond à certains paquets directement)
-
Virtualbox n'a rien à voir dans l'histoire à priori.
Testé sur le portable HP sous debian qui m'a servi pour les tests 4G, sans VB installé et y'a toujours des RST/SYN-ACK en plus de l'habituel.
Faut donc sans doute bien modifier des paramètres de la pile réseau.
-
Virtualbox n'a rien à voir dans l'histoire à priori.
Testé sur le portable HP sous debian qui m'a servi pour les tests 4G, sans VB installé et y'a toujours des RST/SYN-ACK en plus de l'habituel.
Faut donc sans doute bien modifier des paramètres de la pile réseau.
Comme la capture est filtrée, je ne suis pas sûr, mais je vois deux cas :
- "tcp.stream eq 2", "tcp.stream eq 6", "tcp.stream eq 7", "tcp.stream eq 8" qui ont probablement des échanges filtrés => mutiples RST à cause de la fermeture simultanée par les deux parties (j'ai aussi la même chose avec Fedora pour lafibre.info ou apache.org par exemple), à priori pas très grave
- "tcp.stream eq 9" à tcp.stream eq 33" qui sont annulés tout de suite (et un seul RST) => je n'ai pas ça avec Fedora (donc à moins que ça vienne de ma configuration, il doit y avoir des différences côté Firefox/glibc/kernel, ou côté iptables)
-
En voilà une non filtrée :)
-
Pour mieux caractériser le phénomène, j'ai mis en place deux pages web de test.
102 requêtes et 349Ko téléchargés : https://lafibre.info/site/citefibre/offres_premium_tvnumerique.htm
287 requêtes et 1784Ko téléchargés : https://lafibre.info/site/declic-telecom/www.declic-telecom.com/television.html
Ce sont des pages statiques, sans connexion et qui ne changent jamais, ce qui facilite l’investigation en enlevant des hypothèses.
Il faut juste vider le cache avant de charger une des pages.
Voici une capture de la page citéFibre quand tout se passe bien : 6 connexions TCP ouvertes, toutes utilisées, aucun reset, aucun paquet retransmis : 201905_ref_citefibre_firefox67_ubuntu1904.pcapng.gz (https://lafibre.info/images/wireshark/201905_ref_citefibre_firefox67_ubuntu1904.pcapng.gz)
Le FAI utilisé est SFR câble 100 Mb/s.
Voici une capture de la page citéFibre un peu dégradé : il y a des paquetés envoyés en double et le serveur envoi deux reset à chaque fin de connexion, car il a reçu des paquets pour une connexion qu'il considère déjà fermée : 201905_ref_citefibre_firefox66_ubuntu1904.pcapng.gz (https://lafibre.info/images/wireshark/201905_ref_citefibre_firefox66_ubuntu1904.pcapng.gz)
Le FAI utilisé est un opérateur d’entreprise avec un plateforme de sécurité entre moi et Internet.
Dans les deux cas je suis connecté directement en Ethernet pour éviter les paquets perdu du WiFi.
Le système d’exploitation client est Ubuntu 19.04 dans les deux cas.
La version de Firefox n'est pas la même mais je ne pense pas que ce soit ça qui impacte le résultat.
Je n'arrive pas a reproduire les connexions TCP ouvertes par dizaines et les reset envoyé à tout va...
Tu arrives à reproduire la chose avec cette page statique après avoir vidé le cache ?
-
Tout va bien dans ce cas, et pas de RST non plus.
-
Il serait intéressant de savoir si le problème est résolut ou si tu n'a que des reset que sur SMF sur le forum (c'est le moteur du forum)
Les pages tests sont très proche : c'est le même serveur web qui répond, simplement le contenu est en statique ce qui permet de rendre la chose plus reproductible, vs contenu dynamique qui change a chaque appel.
-
Non, pas résolu, j'ai toujours autant de reset sur le forum. Il m'arrive d'avoir ce comportement sur d'autres sites mais c'est bien moins fréquent.
En fait, j'ai des reset un peu partout mais j'ai pas l'impression que ce soit lié à nombre trop important de connexions ouvert d'un coup, genre avec youtube ou spotify, je n'ai jamais vu 20 ou 30 connexions simultanées sur une même IP, même en mitraillant la touche F5.
Sur le forum au bout de quelques secondes de navigation (et souvent en revenant à l'accueil) c'est systématique.
Si c'est un bug de SMF, ça serait rassurant quelque part...
-
Hélas non, je ne pense pas que SMF soit le bug mais la façon dont il y a interaction.
J'arrive a le reproduire chez moi et j'ai fait l'indispensable capture coté serveur car c'est vraiment intéressant d'avoir les deux cotés.
Capture coté client :
201905_lafibre_acceuil_firefox67_ubuntu1904_client.pcapng.gz (https://lafibre.info/images/wireshark/201905_lafibre_acceuil_firefox67_ubuntu1904_client.pcapng.gz)
Capture coté serveur :
201905_lafibre_acceuil_firefox67_ubuntu1904_serveur.pcapng.gz (https://lafibre.info/images/wireshark/201905_lafibre_acceuil_firefox67_ubuntu1904_serveur.pcapng.gz)
-
Je vais filtrer connexion TCP par connexion TCP.
La première connexion TCP était déjà ouvert, je n'ai pas attendu suffisamment depuis la dernière page visitée pour aller sur le forum => Les numéro de séquences sont différent entre client et serveur.
On note que de nombreux paquets sont émis en double et reçus en double par le client.
Pourquoi ?
Coté serveur la ré-émission se fait car il n'a pas reçu d'acquittement après avoir envoyé le paquet. Il attend un peut de temps puis ré-èmet le paquet (le serveur connaît la distance ou RTT et donc la vitesse a laquelle il devrait recevoir les acquittement)
Coté client, il y a bien une absence d’acquittement pour une raison toute simple : le paquet initial et sa ré-émission arrivent en même temps ! Je me demande si cela ne serait pas lié à de l'offload sur la carte réseau du client. (j'ai une carte Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller sur mon PC client)
Connexion TCP N°0 coté client :
(https://lafibre.info/images/wireshark/201905_lafibre_acceuil_firefox67_ubuntu1904_client_0.png) (https://lafibre.info/images/wireshark/201905_lafibre_acceuil_firefox67_ubuntu1904_client_0.png)
Connexion TCP N°0 coté serveur :
(https://lafibre.info/images/wireshark/201905_lafibre_acceuil_firefox67_ubuntu1904_serveur_0.png) (https://lafibre.info/images/wireshark/201905_lafibre_acceuil_firefox67_ubuntu1904_serveur_0.png)
-
Je saute la connexion TCP N°1 qui est clean.
Pour la connexion TCP N°2, là je suis perplexe, le client fait une requête probablement un GET, c'est le paquet de 465 octets puis envoit immédiatement un [FIN, ACK] pour terminer la connexion TCP.
Le client va donc envoyer des reset à chaque paquet de données reçus, car le serveur exécute la requête jusqu'au bout avant de fermer la connexion.
Autre fait étrange : le serveur ne va recevoir qu'un seul Reset, alors que le client en envoi après chaque paquet. Ce paquet arrive au serveur une fois la totalité des paquets transférés.
Connexion TCP N°2 coté client :
(https://lafibre.info/images/wireshark/201905_lafibre_acceuil_firefox67_ubuntu1904_client_2.png) (https://lafibre.info/images/wireshark/201905_lafibre_acceuil_firefox67_ubuntu1904_client_2.png)
Connexion TCP N°2 coté serveur :
(https://lafibre.info/images/wireshark/201905_lafibre_acceuil_firefox67_ubuntu1904_serveur_2.png) (https://lafibre.info/images/wireshark/201905_lafibre_acceuil_firefox67_ubuntu1904_serveur_2.png)
-
Connexion TCP N°3 :
Le client et le serveur vont chacun s'envoyer en même temps un [FIN, ACK] (chacun envoi le sien avant de recevoir celui envoyé par l'autre)
A partir de ce [FIN, ACK] le client va envoyer des reset à tous les paquets reçus et il ne va plus envoyer d'acquitement. Comme la fois précédente, seul un seul reset parviendra au serveur.
Coté serveur, on souhaite recevoir l'acquittement du gros paquet de données, il sera donc ré-envoyé 9 fois au total ! (oui le même paquet est envoyé 9 fois)
A noter que dans la connexion N°2 il semble que ce soit un des denrier reset qui est passé, les premiers étant supprimés, ici, c'est l'inverse: le premier reset est envoyé et les autres sont supprimés.
Connexion TCP N°3 coté client :
(https://lafibre.info/images/wireshark/201905_lafibre_acceuil_firefox67_ubuntu1904_client_3.png) (https://lafibre.info/images/wireshark/201905_lafibre_acceuil_firefox67_ubuntu1904_client_3.png)
Connexion TCP N°3 coté serveur :
(https://lafibre.info/images/wireshark/201905_lafibre_acceuil_firefox67_ubuntu1904_serveur_3.png) (https://lafibre.info/images/wireshark/201905_lafibre_acceuil_firefox67_ubuntu1904_serveur_3.png)
-
Perso, n'étant pas assez calé sur TCP je ne sais pas ce qu'il faut en conclure... je laisse la parole aux autres...
-
Vous avez essayé de faire une capture entre les deux pour savoir ce qui sort exactement coté client?
genre un autre pc avec un bridge?
-
Connexion TCP N°0 :
Effectivement la réception des ACK + DUP ACK ensemble est très étrange.
Si on suppose que le problème est sur le PC, alors ça peut être :
- un bug dans l'offload (mais il n'y en a pas énormèment sur du Realtek)
- un bug autour des fonctionalités d'économie d'énergie (green ethernet, ASPM, ...)
Il y a eu pas mal de changements dans r8169 autour de l'ASPM, j'ai un patch local pour ne pas désactiver l'horloge du Realtek car l'ASPM est activé par mon BIOS (sans désactivation possible), et la sortie du mode L1.2 est trop lente ce qui engendre des pertes de trames Ethernet si le réseau ne supporte pas le controle de flux, avec comme résultat des performances catastrophiques).
Je suggère d'essayer des kernels différents, ou une autre carte réseau (par exemple en USB).
Connexion TCP N°2 :
Le serveur a reçu le FIN du client, mais envoit pourtant les données (peut-être des buffers quelque part, ou le comportement du programme), c'est autorisé par le TCP.
Connexion TCP N°3 :
La fermeture simultanée arrive à cause des Encrypted Alert (le serveur reçoit celui du client, et donc envoie le sien et le FIN, sauf que le client a envoyé son FIN immédiatement).
Jusque là, j'ai la même chose sur apache.org par exemple, mais je ne comprends pas pourquoi le serveur persiste après avoir reçu le RST.
Les connexions N°2 et N°3 semblent effectivement avoir été annulées par le client, mais le délai entre l'ACK et le paquet Application Data du client est étrange (respectivement 44ms et 100ms), surtout que l'Encrypted Alert suit (je ne voit aucun cas où le client voudrait faire un GET pour l'annuler immédiatement).
Peut-être que ce sont des connexions spéculatives (network.http.speculative-parallel-limit ?) qui sont finalement annulées car plus nécessaires, mais je ne sais pas quelles données pourraient être envoyées par le client.
Malheureusement Debian/Ubuntu n'activent pas le support de SSLKEYLOGFILE (https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/Key_Log_Format) donc impossible de déchiffrer les échanges dans Wireshark.
-
Je viens de redémarrer le serveur après avoir commenté toutes les options pour optimiser le débit (car c'est un serveur de test de débit pour 4G Mark et autres applications QoSi de test de débit)
nano /etc/sysctl.d/19-patch-swappiness.conf
# Reduce the swap
vm.swappiness = 5
# Reduce the threshold where a DDOS impacts the server
#net.ipv4.tcp_max_syn_backlog = 2048
# TCP congestion control protocol for high-speed and long-distance networks
#net.ipv4.tcp_congestion_control=illinois
# Increase TCP buffers
#net.ipv4.tcp_rmem=4096 87380 16777216
#net.ipv4.tcp_wmem=4096 65536 16777216
#net.core.rmem_max=851968
#net.core.wmem_max=851968
# default queuing discipline for 10GigE speeds
#net.core.default_qdisc=fq
# Increase the queue within the Linux kernel where traffic is stored after rece$
#net.core.netdev_max_backlog=4000
# Increase number of incoming connections
#net.core.somaxconn = 512
On est donc maintenant sur un Ubuntu server 16.04 avec kernel HWE (Linux 4.15.0-50-generic #54~16.04.1-Ubuntu) sans aucune optimisation / tunning à part la règles iptables suivante :
# Limiter le nombre de sessions tcp par client (un client = une IPv4 ou un /64 en IPv6)
/sbin/iptables -A INPUT -p tcp --syn -m connlimit --connlimit-above 100 -m limit --limit 30/hour --limit-burst 1 -j LOG --log-prefix="drop-c-"
/sbin/iptables -A INPUT -p tcp --syn -m connlimit --connlimit-above 100 -j REJECT
/sbin/ip6tables -A INPUT -p tcp --syn -m connlimit --connlimit-above 100 --connlimit-mask 64 -m limit --limit 30/hour --limit-burst 1 -j LOG --log-prefix="drop-c-"
/sbin/ip6tables -A INPUT -p tcp --syn -m connlimit --connlimit-above 100 --connlimit-mask 64 -j REJECT
Capture coté client en IPv6, aucun reset :
201905_lafibre_acceuil_firefox67_ubuntu1804_client_ipv6.pcapng.gz (https://lafibre.info/images/wireshark/201905_lafibre_acceuil_firefox67_ubuntu1804_client_ipv6.pcapng.gz)