Pages: 1 ... 3 4 5 6 7 [8]   En bas

Auteur Sujet: Firefox (sous Ubuntu) ouvre des connexion TCP puis fait un reset  (Lu 20451 fois)

0 Membres et 1 Invité sur ce sujet

vivien

  • Administrateur
  • *
  • Messages: 47 187
    • Twitter LaFibre.info
Firerox (sous Ubuntu) ouvre des connexion TCP puis fait un reset
« Réponse #84 le: 22 mai 2019 à 21:32:04 »
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

Capture coté serveur :
201905_lafibre_acceuil_firefox67_ubuntu1904_serveur.pcapng.gz
IP archivée

vivien

  • Administrateur
  • *
  • Messages: 47 187
    • Twitter LaFibre.info
Firerox (sous Ubuntu) ouvre des connexion TCP puis fait un reset
« Réponse #85 le: 22 mai 2019 à 21:38:44 »
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 :


Connexion TCP N°0 coté serveur :
IP archivée

vivien

  • Administrateur
  • *
  • Messages: 47 187
    • Twitter LaFibre.info
Firerox (sous Ubuntu) ouvre des connexion TCP puis fait un reset
« Réponse #86 le: 22 mai 2019 à 21:47:13 »
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 :


Connexion TCP N°2 coté serveur :
IP archivée

vivien

  • Administrateur
  • *
  • Messages: 47 187
    • Twitter LaFibre.info
Firerox (sous Ubuntu) ouvre des connexion TCP puis fait un reset
« Réponse #87 le: 22 mai 2019 à 21:56:30 »
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 :


Connexion TCP N°3 coté serveur :
IP archivée

renaud07

  • Abonné Orange adsl
  • *
  • Messages: 3 371
Firerox (sous Ubuntu) ouvre des connexion TCP puis fait un reset
« Réponse #88 le: 22 mai 2019 à 22:52:54 »
Perso, n'étant pas assez calé sur TCP je ne sais pas ce qu'il faut en conclure... je laisse la parole aux autres...
IP archivée

butler_fr

  • Client Bbox adsl
  • Modérateur
  • *
  • Messages: 3 607
  • FTTH orange
Firerox (sous Ubuntu) ouvre des connexion TCP puis fait un reset
« Réponse #89 le: 22 mai 2019 à 23:10:41 »
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?
IP archivée

hwti

  • Abonné Orange Fibre
  • *
  • Messages: 2 237
  • Chambly (60)
Firerox (sous Ubuntu) ouvre des connexion TCP puis fait un reset
« Réponse #90 le: 23 mai 2019 à 01:58:08 »
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.
IP archivée

vivien

  • Administrateur
  • *
  • Messages: 47 187
    • Twitter LaFibre.info
Firerox (sous Ubuntu) ouvre des connexion TCP puis fait un reset
« Réponse #91 le: 23 mai 2019 à 06:48:53 »
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
Code: [Sélectionner]
# 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 :
Code: [Sélectionner]
# 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
IP archivée
Pages: 1 ... 3 4 5 6 7 [8]   En haut