Incidents câble => Discussion démarrée par: vivien le 07 avril 2021 à 13:52:21 Incidents câble => Discussion démarrée par: vivien le 07 avril 2021 à 13:52:21T'as vérifié si ça pouvait pas être un problème de MTU ?Je vois bien ces problématiques de MTU, j'ai d’ailleurs fait un sujet dessus : Négociation MTU MSS: comment ça fonctionne ? (https://lafibre.info/tcpip/negociation-mtu-comment-ca-fonctionne/)
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]
(https://lafibre.info/images/wireshark/202104_sfr_pb_connexion_linux_capture_serveur_vivien.png)
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.
Je suis par contre intéressé par le retour positif ou négatif d'autres utilisateurs câble que le problème soit présent ou pas pour mieux circoncire le problème.Exciser le prépuce d'un garçon? ;)
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 (https://lafibre.info/tcpip/realiser-une-capture-wireshark-pas-a-pas/)
--------
Autre information importante: pourrais-tu nous indiquer quelle est ton modèle de box ?
Je suis par contre intéressé par le retour positif ou négatif d'autres utilisateurs câble que le problème soit présent ou pas pour mieux circonscrire le problème.Il me semble avoir vu passer de (rares) symptômes proches des tiens récemment sur le forum SFR... Mais chez moi tout est OK.
Je ne connais plus le nom exact de cette box, c'est la petite box FTTLa de RED avec WiFi ac, ce n'est pas LaBox4K.Il y a forcément erreur de photo.
Je met une image en dessous (nb7 d'après le nom de l'image ?).
BonjourIl me semble avoir vu passer de (rares) symptômes proches des tiens récemment sur le forum SFR... Mais chez moi tout est OK.
A noter que chez REDbySFR en FTTH j'ai pas mal de retransmission TCP du serveur vers mon ordinateur, probablement lors de la fermeture de session également :
Du routage A+P pour faire du "CGNAT stateless" qui se met en place de manière foireuse, ce qui drop les paquets downlink (ou les envoie ailleurs) si le port de DST n'est pas dans le bon range ?Je vote pour un LAG entre deux routeurs dont un lien serait 💩 dans un sens (la distribution des paquets utilisant un hash sur au moins headers layers 3+4 ; quand le paquet tombe sur la mauvaise interface il part à la 🗑).
Je pense qu’elle devrait changer le port en effet. Il faudrait tenter le test avec absolument 0 device connecté à la box autre qu’un PC, et qu’absolument aucun programme si ce n’est curl sur le PC ne communique avec l’extérieur.Chez moi, 5 ou 6 devices connectés en permanence sur la box, en ethernet avec système de communifation alarme/domotique, boitier Dect/SIP, Sonde Ripe, quelques PC dont 2 actifs en permanence quand je n'ai pas une ou 2 bécanes en "convalescence"...
La plupart des NAT réutilisent le port source initial. Mais si celui-ci est déjà mappé, là ça peut devenir Random et c’est incontrôlable.
Il a des souci de reset, mais pas de blocage de connexion TCP, du moins en ce moment.
(https://lafibre.info/images/wireshark/202104_sfr_cable_capture_linux_nico_chevalier.jpg)
Après je pense que dans les faits n’avoir que 1/4 des ports te permet quand même plus de 16 000 connexions TCP simultanées (et autant d’UDP), ça doit pas être un facteur limitant chez un particulier.Ce n'était pas ce que disais, mais plus précisément que cela pouvait introduire une "interdiction" au NAT de reprendre le port origine interne pour le destinataire...
Après je pense que dans les faits n’avoir que 1/4 des ports te permet quand même plus de 16 000 connexions TCP simultanées (et autant d’UDP), ça doit pas être un facteur limitant chez un particulier.Ç'aurait été un problème dans le passé, à l'époque du Peer to Peer (et de certaines box dont le NAT moisi s'écroulait pour cause de trop de sessions simultanées à gérer).
Ç'aurait été un problème dans le passé, à l'époque du Peer to Peer (et de certaines box dont le NAT moisi s'écroulait pour cause de trop de sessions simultanées à gérer).Je pense avoir fait quelque peu dériver le sujet suite à ce qu'avait dit Eahlys
Mais avec sa quasi disparition, ça n'est plus vraiment un problème, le Peer to Peer qui reste étant surtout des saloperies type Streamroot (CDN qui vole la bande passante sortante des eyeballs pour faire rebondir le trafic).
Je pense qu’elle devrait changer le port en effet. Il faudrait tenter le test avec absolument 0 device connecté à la box autre qu’un PC, et qu’absolument aucun programme si ce n’est curl sur le PC ne communique avec l’extérieur.Pour moi, il est clair que ce type de mappage de port, faut pas trop compter dessus... Peut-être pour ce que j'appellerai "un test de labo", mais dans la réalité, pas glop... ;) ;) ;)
La plupart des NAT réutilisent le port source initial. Mais si celui-ci est déjà mappé, là ça peut devenir Random et c’est incontrôlable.
L'idée de scripter un moyen de tester tous les ports source possible pourrait permet de circonSCRire le problème, non ? (curl --local-port)
Je l'ai vraiment tout le temps.
Cela serait lié à la box ?
- Modem NB6VAC : 2 personnes non impactées
- Modem Sagem F@st 3284 DC : 1 personne impactée (moi)
- Box tout en un 4k Sagem LABOXV3B : 2 personnes impactées
Un lag n'est pas sensé être résilient ?En cas de coupure d'un lien.
Par contre, contrairement à toi, j'accède à tous les sites et ne ressens jamais ce que tu décris (nombreux sites qui n'arrivent pas à charger).
#!/bin/bash
i=32768
while [ $i -le 65536 ] ; do
echo Test du port source: $i
curl -4 -o /dev/null http://k-net.testdebit.info/0.iso --local-port $i
i=$(($i + 1))
doneJe vote pour un LAG entre deux routeurs dont un lien serait 💩 dans un sens (la distribution des paquets utilisant un hash sur au moins headers layers 3+4 ; quand le paquet tombe sur la mauvaise interface il part à la 🗑).
Le plus important c'est le SNR (ration du signal sur le bruit). 40dB, c'est très bon
Voici les valeurs de référence pour le SNR (rapport signal/bruit) :
Nominal Toléré Dégradé SNR canaux descendants modulation QAM256 >= 31dB entre 28 et 31 dB < 28 dB SNR canaux descendants modulation 64QAM >= 24 dB entre 23 et 24 dB < 23 dB SNR canaux montants modulation 16QAM >= 21 dB entre 19 et 21 dB < 19 dB SNR canaux montants modulation QPSK >= 15 dB entre 13 et 15 dB < 13 dB
Ouaip, mais je n'ai aucun souci, 24 canaux descendants, 2 remontants. Toujours au taquet et pas vraiment de soucis à remonter. Si j'appelle le SC alors que je ne constate aucun problème, ça va être bizarre.C'est quoi tes valeurs ?
Un lien serait dans un état où les paquets sont tous supprimés dans le sens internet => client, mais où le signal est suffisant pour ne pas le faire tomber ou électronique de contrôle est défectueuse.Les LAGs utilisent classiquement LACP pour vérifier la bidirectionnalité de chaque membre du LAG (et comme on n'a pas vu plusieurs IPs au même hop dans les traceroutes UDP, ce serait plutôt un LAG que plusieurs liens parallèles en ECMP). Donc:
C'est quoi tes valeurs ?
Optix, c'est mieux ? (J'ai viré des équipements inutiles).Ah oui, nettement mieux ;)