Auteur Sujet: SFR/Red THD connexion bloquée pour certains ports source utilisés ! (Lu 29808 fois)

vivien · « **le:** 07 avril 2021 à 13:52:21 »

Je vais vous parler d'un incident réseau assez étrange qui affectent certains clients RED et SFR sur le câble. Si vous avez une idée, je suis preneur, car vu la complexité du bug, la hotline ne semble pas la bonne solution.

Cela fait plusieurs jours que ma connexion SFR câble est bien dégradée, sous tous mes systèmes d’exploitation que j'utilise (Windows 10, Android, Ubuntu 18.04 ou Ubuntu 20.10) aussi bien en Ethernet que en Wi-Fi.

J'ai alors fait quelques tests de débit qui montrent que le débit est bon (j'ai tout le temps les 100 Mb/s descendant et 5 Mb/s montant promis).

Suspectant des pertes de paquets, j'ai réalisés des tests, mais non, je ne perd pas de paquets.

J'ai réinitialisé ma box (Sagem F@st 3284 DC) à sa configuration usine, au cas où, sans effet.
J'ai testé avec la box de mon voisin (un modèle bien : Sagem LABOXV3B (Box 4k pour réseau câble) : même problématique.

J'ai alors sorti Wireshark pour analyser ma connexion et c'est assez incroyable : Environ une connexion TCP sur dix est bloquée (probablement par le réseau). Le client envoi un paquet [SYN] qui est bien transmis au serveur. Le serveur répond un [SYN-ACK] qui n'arrivera jamais sur le client. Le client va faire un deuxième [SYN] en utilisant le même port source et il sera de nouveau perdu, un troisième, un quatrième, un cinquième, perdu eux aussi. Par contre si il tente une autre connexion, donc sur un autre port source, cela fonctionne bien. Tout est lié au port source utilisé !

Je précise que je ne fais pas de peer-to-peer et que ce problème se produit même avec seulement un PC de connecté en Ethernet à la box, qui surf sur un seul site web. La box n'est donc pas chargée par de nombreuses connexion TCP ouvertes simultanément.

Les symptômes :

- Dans un navigateur web : On va avoir un message comme quoi le sites est inaccessible :

Certains sites vont être chargés partiellement, voir avec une page vide comme NextINpact ci-dessous :

Twitter :

Application Molotov.TV :

- Android : Des applications se lancent et plantent ou ne trouvent pas certains contenus. Certaines applications indiquent qu'il y a un problème réseau, d'autres ont des contenus manquant.

Exemple avec l'application Android pour le lavage de dent de mon fils (Brush Up) qui bloque sur cette image :

Impact sur mon thermostat connecté Netatmo et à droite pour monter mon VPN pro :

Je précise qu'une fois que le VPN est monté, je n'ai plus aucun problème.

- iPhone : j'ai confirmation par ma femme qui est sur iPhone, qu'elle est aussi impactée. Elle accusait l'iPhone et regrettait son Samsung (elle vient de migrer d'Android à iPhone à la demande de son employeur). Elle me dit que de nombreux sites n'arrivent pas à se charger.

- Windows 10 : Quand on clique sur un exécutable téléchargé, on a va avoir le message de Windows SmartScreen expliquant qu'il ne peut vérifier le fichier faute de connexion Internet.

- Ubuntu : La mise à jour va télécharger des fichiers sur plusieurs déports et un seul inaccessible fait apparaître ce message, qui sera donc quasiment systématique :

Voici un exemple de test de débit réalisé avec nPerf, le débit est bon, mais nPerf ne peut pas terminer car il n'arrive pas à établir une connexion TCP malgré de nombreuses tentatives :

vivien · « **Réponse #1 le:** 07 avril 2021 à 13:53:45 »

Exemple de captures Wireshark coté client :

Voici ce que donne une capture Wireshark sur ma box RED (Sagem F@st 3284 DC).

C'est un serveur OCSP qui est interrogé par Firefox en http (port destination 80) pour vérifier la validité du certificat TLS d'un site qui utilise un certificat Trustwave. On interroge toujours la même IPv4 :
- t= 0,00 s : Première connexion TCP en utilisant le port source 50756. Pas de réponse reçue.
- t= 0,25 s : Seconde connexion TCP en utilisant le port source 50762. Pas de réponse reçue.
- t= 1,00 s : Retransmission du [SYN] de la première connexion (port source 50756). Pas de réponse reçue.
- t= 1,25 s : Retransmission du [SYN] de la seconde connexion (port source 50762). Pas de réponse reçue.
- t= 1,70 s : Troisième connexion TCP en utilisant le port source 50796. Là c'est bon en moins de 0,1 sec il obtient la réponse. Le chargement de la page est retardé inutilement par ce bug d'au moins 1,7sec.
- t= 3,00 s : Retransmission du [SYN] de la première connexion (port source 50756). Pas de réponse reçue.
- t= 3,25 s : Retransmission du [SYN] de la seconde connexion (port source 50762). Pas de réponse reçue.
Les autres retransmission du port 50756 et 50762 seront en échec.

Les paquets sur les ports 50756 et 50762 sont supprimés probablement par le réseau (vu que mon voisin a le même problème avec une box bien différente)

La capture Wireshark si vous souhaitez regarder : (cliquer sur la miniature ci-dessous, Wireshark est nécessaire pour lire le fichier)
202104_sfr_pb_connexion_windows_capture_ocsp.trustwave.com.pcapng.gz

Voici ce que donne une capture Wireshark sur la box de mon voisin, la Box 4K de SFR (Sagem LABOXV3B), un autre PC et Windows 10:

Ici c'est une connexion https (port destination 443) sur un serveur Microsoft (disc601.prod.do.dsp.mp.microsoft.com). Ici contrairement à la précédente capture où les connexions TCP sont ouvertes sucessivement faute de rpéonse, là le client ouvre directement deux connexions. Celle sur le port 51900 n'arrivera jamais à s'ouverir malgré une relance à T+1sec, T+3 sec, T+7sec et T+15sec.

Celle sur le port 51901 de la même IP fonctionne parfaitement :

La capture Wireshark si vous souhaitez regarder : (cliquer sur la miniature ci-dessous, Wireshark est nécessaire pour lire le fichier)
202104_sfr_pb_connexion_windows_capture_microsoft.pcapng.gz

vivien · « **Réponse #2 le:** 07 avril 2021 à 14:07:51 »

Capture coté client + coté serveur

Dans mes captures précédentes, rien ne prouve que le problème est chez SFR : En effet, même si c'est toujours la même IPv4 qui est interrogée, il est possible d'imaginer que les différentes connexions sont envoyées vers un répartiteur de charge et arrivent vers des serveurs physiques différents et que certains sont en panne.

J'ai donc effectué une capture coté client et coté serveur simultanément.
- Coté serveur : Ubuntu Server 20.04 https://ubuntu.lafibre.info/ interrogé en https (port destination : 443)
- Coté client : Ubuntu 20.10 avec une requête réalisée par le client wget
- Box : RED box THD (Sagem F@st 3284 DC).

Le message d'erreur coté client :

La capture coté client : On voit des paquets [SYN] qui sont tous avec le port destination 443 et le port source 37204 :

La capturé coté serveur : Surprise, le serveur reçois bien les paquets et y répond. C'est donc cette réponse qui est perdue.
La réponse inverse les ports, le port source est donc le port 443 et le port destination le port 37204 pour tous les paquets [SYN, ACK]

A noter que pendant ma capture, j'ai réussi à maintenir une autre connexion TCP sur le serveur : Les paquets émis par ce serveur à destination de l'IPv4 de la box arrivent donc bien a destination, si le port destination est ok.

La capture Wireshark coté client : (cliquer sur la miniature ci-dessous, Wireshark est nécessaire pour lire le fichier)
202104_sfr_pb_connexion_linux_capture_client_vivien.pcapng.gz

La capture Wireshark coté serveur : (cliquer sur la miniature ci-dessous, Wireshark est nécessaire pour lire le fichier)
202104_sfr_pb_connexion_linux_capture_serveur_vivien.pcapng.gz

vivien · « **Réponse #3 le:** 07 avril 2021 à 14:14:37 »

Même test, depuis la box SFR (box 4k) de mon voisin :

- Coté serveur : Ubuntu Server 20.04 https://ubuntu.lafibre.info/ interrogé en http (port destination : 80)
- Coté client : Ubuntu 20.10 avec une requête réalisée par le client wget
- Box : Box SFR 4k Sagem LABOXV3B

La capture coté client : On voit des paquets [SYN] qui sont tous avec le port destination 80 et le port source 52396 :

La capturé coté serveur : Comme sur ma box, le serveur reçois bien les paquets et y répond. C'est donc cette réponse qui est perdue.
La réponse inverse les ports, le port source est donc le port 80 et le port destination le port 52396 pour tous les paquets [SYN, ACK]

La capture Wireshark coté client : (cliquer sur la miniature ci-dessous, Wireshark est nécessaire pour lire le fichier)
202104_sfr_pb_connexion_linux_capture_client_jacques.pcapng.gz

La capture Wireshark coté serveur : (cliquer sur la miniature ci-dessous, Wireshark est nécessaire pour lire le fichier)
202104_sfr_pb_connexion_linux_capture_serveur_jacques.pcapng.gz

vivien · « **Réponse #4 le:** 07 avril 2021 à 14:27:33 »

Autres exemple de captures Wireshark coté client :

Voici ce que donne une capture Wireshark sur ma box RED (Sagem F@st 3284 DC).

La connexion se fait en https (port destination 443) sur les serveurs de Mozilla : incoming.telemetry.mozilla.org

3 connexions TCP sont établies sur le serveur mozilla :
- t= 0,00 sec : connexion N°0, qui utilise le port source 50565 : Les réponses au paquet SYN ne reviennent pas
- t= 0,25 sec : connexion N°1, qui utilise le port source 50570 : Tout est ok
- t= 2,28 sec : connexion N°2, qui utilise le port source 50581 : Les réponses au paquet SYN ne reviennent pas

Voici ce que donne la capture Wireshark en ne filtrant que sur l'IPv4 du serveur de Mozilla :

En filtrant sur la connexion N°0, qui utilise le port source 50565 : Les réponses au paquet SYN ne reviennent pas

En filtrant sur la connexion N°1, qui utilise le port source 50570 : Tout est ok

En filtrant sur la connexion N°2, qui utilise le port source 50581 : Les réponses au paquet SYN ne reviennent pas

La capture Wireshark si vous souhaitez regarder : (cliquer sur la miniature ci-dessous, Wireshark est nécessaire pour lire le fichier)
202104_sfr_pb_connexion_windows_telemetry.mozilla.org.pcapng.gz

vivien · « **Réponse #5 le:** 07 avril 2021 à 14:40:52 »

Un autre exemple la connexion en https (port destination 443) sur le serveur prg.smartadserver.com (pour de la publicité il me semble)

8 connexions TCP sont établies sur le serveur :
- t= 0,00 sec : connexion N°0, qui utilise le port source 50781 : Les réponses au paquet SYN ne reviennent pas
- t= 0,00 sec : connexion N°1, qui utilise le port source 50782 : Tout est ok
- t= 0,00 sec : connexion N°2, qui utilise le port source 50783 : Les réponses au paquet SYN ne reviennent pas
- t= 0,00 sec : connexion N°3, qui utilise le port source 50784 : Tout est ok
- t= 0,00 sec : connexion N°4, qui utilise le port source 50785 : Tout est ok
- t= 0,00 sec : connexion N°5, qui utilise le port source 50786 : Tout est ok
- t= 0,26 sec : connexion N°6, qui utilise le port source 50798 : Tout est ok
- t= 0,26 sec : connexion N°7, qui utilise le port source 50799 : Tout est ok

Voici ce que donne la capture Wireshark en ne filtrant que sur l'IPv4 du serveur en question :

En filtrant sur la connexion N°0, qui utilise le port source 50781 : Les réponses au paquet SYN ne reviennent pas

En filtrant sur la connexion N°1, qui utilise le port source 50782 : Tout est ok

En filtrant sur la connexion N°2, qui utilise le port source 50783 : Les réponses au paquet SYN ne reviennent pas

En filtrant sur la connexion N°3, qui utilise le port source 50784 : Tout est ok

En filtrant sur la connexion N°4, qui utilise le port source 50785 : Tout est ok

En filtrant sur la connexion N°5, qui utilise le port source 50786 : Tout est ok

En filtrant sur la connexion N°6, qui utilise le port source 50798 : Tout est ok

La capture Wireshark si vous souhaitez regarder :[/size] (cliquer sur la miniature ci-dessous, Wireshark est nécessaire pour lire le fichier)
202104_sfr_pb_connexion_windows_capture_smartadserver.com.pcapng.gz

vivien · « **Réponse #6 le:** 07 avril 2021 à 14:46:49 »

En conclusion :

Je ne pense pas que cela vienne des box, car ma box et celle de mon voisin (une box tout en un) sont de génération bien différentes, bien que fabriquées par Sagem toutes les deux. La mienne, la Sagem F@st 3284 DC est assez ancienne et je ne pense pas qu'il y a des mises à jour qui soient déployée dessus (en https, elle écoute en SSLv2, SSLv3 et TLS 1.0 uniquement, pas de TLS 1.1 ou plus récent).

J'ai testé un reset usine sans sucés sur max box, cela a permis de changer d'IPv4 publique (javais le même problème avec ma précédente IP publique d'une range bien différent). J'ai ensuite juste modifié le SSID et le mot de passe.

J'ai testé avec de nombreux PC client, système exploitation et serveurs donc je pense que le plus probable est que cela vienne du réseau.

Ma box, Sagem F@st 3284 DC :

Celle de mon voisin, Sagem LABOXV3B, une box tout en un 4k de SFR :

vivien · « **Réponse #7 le:** 07 avril 2021 à 14:47:23 »

Les canaux de ma box :

Celle de mon voisin Sagem LABOXV3B :

Sylvere · « **Réponse #8 le:** 08 avril 2021 à 12:31:54 »

En plus des problèmes SYN, il y a quelque chose qui m'interpelle sur les FIN de connexion TCP. Par ex sur le stream 8 (image écran jointe; on a le même comportement sur le stream 3): à la trame 188, le client émet 24 octets de n° de séquence 4196 à 4220, puis ferme la connexion (trame 189). Le serveur ferme à son tour (trame 190 "FIN"), mais sans acquittter ces 24 octets (il fait ACK 4196, c'est-à-dire des octets de la trame d'avant).

Cette séquence de 24 octets est répétée avec les Delta T croissants caractéristiques de TCP, à partir de la trame 193. Ce qui m'interpelle, c'est que ces retransmissions n'obtiennent AUCUNE réponse (du serveur ou d'un équipements intermédiaire portant la connexion TCP: Load balancer, firewall,....), même pas un RST.

[Note: Cela semble d'ailleurs perturber aussi le client, puisqu'après avoir constaté l'échec de la retransmission de cette séquence de 24 octets (octets 4196 et suivants), il remonte de 1 et retransmet le seul octet 4195 (trame 199 à 208), déjà acquitté par le serveur! (à la trame 185). Cela fait penser à un comportement de "probe" qu'on retrouve dans certains cas TCP, mais ici je ne sais pas l'expliquer. C'est toutefois a priori hors sujet par rapport au problème que l'on traite.]

En résumé: je ne suis pas sûr que le problème TCP soit limité aux seuls SYN ! Peut-être y a-t-il un équipement intermédiaire au comportement "limite". Je ferais bien des analyses un peu plus poussée des connexions TCP, en recherchant dans wireshark d'éventuelles séquences de retransmission non expliquées, sur une période de temps un peu plus longue.

vivien · « **Réponse #9 le:** 08 avril 2021 à 14:08:49 »

Oui, il y a des anomalies dans les échanges TCP/IP au-delà des paquets [SYN-ACK] et bien avant cette dégradation. Je n'avait pas conscience que le réseau (ou la box ?) pouvait supprimer comme ça des paquets en fonction du contenu des flag dans les paquets de niveau 4.

Maintenant, la dégradation qui date de la fin de la semaine dernière (ou lundi ?) à un impact fort. Par exemple là j'ai eu twitter où aucune image ne se chargeait.
Le comportement est complètement inattendu, que des applications plantent.

J’aimerais bien savoir si d'autres clients sont impactées, je me demande si cela ne concernerait pas ma TDR, celle de Vitry-sur-Seine, dont voici la couverture extraite du SDTAN du Val-de-Marne :

guiz67 · « **Réponse #10 le:** 08 avril 2021 à 14:11:23 »

Hello,

Le comportement que tu indiques Vivien m'impacte aussi parfois.
Dans l'utilisation courante et depuis quelques jours je dois parfois rafraichir une page ou relancer un recherche sur google pour que les résultats ce charge.

vivien · « **Réponse #11 le:** 08 avril 2021 à 14:27:53 »

guiz67, cela serait possible de réaliser une capture Wireshark pour vérifier qu'on est bien dans le même cas ?

=> Réaliser une capture Wireshark pas à pas

Je conseille de faire une capture et de surfer sur internet. Chaque blocage de connexion TCP n'est pas visible, certains services vont finir par faire une demande sur un autre port et d'autres connexions perdues n'int pas d'impact visible (tracker publicitaire, télémétrie,...)

Dans Wireshark, il faut utiliser le filtre tcp.flags.syn==1 pour se concentrer sur les paquets [SYN] et [SYN-ACK].

Wireshark met en rouge sur fond noir les retransmissions.

Ci-dessous une capture en live, on voit que la connexion avec le port source 44520 a été bloquée :

Avec une seconde connexion réussie sur la même IP, j'ai pu voir par le SNI que c'est "fpc.msedge.net" sur l'IP 13.107.6.163, je trouve ça étonnant que Microsoft Edge génère du trafic sur mon PC alors qu'il est fermé (je suis sous Ubuntu, Microsoft Edge n'est pas un élément du système mais juste un navigateur que j'utilise très peu)

A noter que ton IPv4 publique n’apparaît pas dans les captures réalisées coté client, tu peut donc partager directement ou passer par moi, pour que je vérifie et filtre sur la connexion intéressante à observer.

Autre information importante: pourrais-tu nous indiquer quelle est ton modèle de box ?