Auteur Sujet: Connexions TCP aléatoirement gelées en upload (Lu 8031 fois)

hwti · « **Réponse #36 le:** 02 juillet 2022 à 02:29:56 »

Donc quand la Livebox émet un TTL Exceeded, ça passe (ou alors il faudrait un pattern ou une taille différente pour provoquer le problème).
Mais quand il s'agit d'un Echo Reply, il est perdu s'il a une taille de 29 avec le pattern 0F.
Donc c'est exactement comme les pings sortants (Echo Request), avec la différence qu'il n'y a plus de routage par la Livebox, puisque c'est elle-même qui répond sur son interface WAN.

Au passage, là tu caches ton IP, mais elle est visible dans les différentes traces iperf.

Du coup je me me suis permis quelques pings vers ton IP.
J'ai bien le même comportement que ce que tu observes depuis l'airbox, mais avec un traceroute beaucoup plus petit :
80.10.237.77
193.253.80.134
193.253.80.249
90.127.xx.yy

Je n'ai trouvé qu'une seule autre IP qui répond au ping sur le /24 (et qui a une latence énorme c'est bizarre).
Elle n'a pas le même problème que toi, ce qui implique que soit la route retour est différente, soit le problème est avant le premier routeur (donc soit la Livebox, soit des équipements L2 derrière : ONT, OLT, switchs, ...).

Sinon, j'ai l'impression que le problème ne dépend que d'un seul octet :

Code: [Sélectionner]

for i in $(seq 0 255); do HEX=$(printf %02x $i); nping --data 00000000000000000000000000000000000000000000000000${HEX}000000 -c1 90.127.xx.yy | grep -q RCVD; echo "$HEX : $?"; done

KO pour 08-0f, 18-1f, 28-2f, 38-3f, 88-8f, 98-9f, a8-af, b8-bf => x0xx1xxx
Ce sont uniquement deux bits semblent générer la perte de l'ICMP, quelque soit le reste du contenu.
Ca semble être pareil avec 29/45/61/... octets de données (soit une taille IP de 57/73/89/...) : on peut rajouter autant de fois qu'on veut 16 octets au début des données, c'est toujours le même octet qui compte.

Ça demande à être vérifié, mais il est possible que les pertes en TCP soient exactement pour les mêmes conditions :
- taille IP de la forme 57 + 16*N
- octet YY à l'offset 53 + 16*N (cad qu'il reste 3 octets derrière), tel que YY & 0x48 == 0x8

caeies · « **Réponse #37 le:** 02 juillet 2022 à 12:03:52 »

Va falloir que je fasse une passe sur mes premiers posts, j'étais moins vigilant

.

Sinon pour le reste on est en phase. Merci pour le rappel sur nping, je l'avais zappé, c'est plus pratique pour tester. et Oui c'est des demi octets qui posent problèmes, ce qui me fait penser à une ligne HW «coupée» pour une raison ou une autre.

J'ai tenté aussi de faire des tests autour de mon IP, mais je pense que ce n'est pas très représentatif étant donné que ce sont des ips dynamiques dans un pool et que celui-ci peut être «vaste».

Et pour le TCP, oui je suis a peu près certain que c'est pareil. mais plus «relou» à tester. Je vais voir si je peux faire une boucle de routage sur mon PC entre l'airbox et ma fibre, je vais voir. Un truc qui me fait tiquer tout de même, c'est le pourquoi il faut que le paquet soit sous la forme 13+N*16 ... cette partie là me fait tout de même penser à un bug «logiciel» plus que hard.

(rappel: Il faut: -s 13+$(($N*16)) avec N > 0, et -p $k$j avec k ∈ [0,3]∪[8,b] et j ∈ [8,f].)

Caeies,

caeies · « **Réponse #38 le:** 03 juillet 2022 à 01:22:49 »

Bonsoir à tous,

Bon ça va être un peu frustrant parce que pour l'instant je n'ai pas trouvé comment faire une anonymisation correct des flux, et il va donc falloir me croire :/.

Installation:
* Livebox <= SWITCH => ONT
\- port mirroring vers PC sous wireshark + lien interne sur le VLAN 1 (non taggé).
\- airbox, avec routage de l'ip externe de la livebox par cette interface spécifique.

Sur le PC sous wireshark:
* Wireshark capture sur l'interface eth0 et airbox.
* nping --data 000000000000000000000000000000000000000000000000000F000000 -c1 my.external.ip (routage via l'airbox):
=>

Code: [Sélectionner]

00:03:59.067391 IP 192.168.1.100 > 90.127.xx.yy: ICMP echo request, id 32208, seq 1, length 37 # => paquet vers l'airbox
00:03:59.161749 IP 92.184.107.239 > 90.127.xx.yy: ICMP echo request, id 32208, seq 1, length 37 # => arrivé du même paquet sur le vlan 832 vers la livebox (CHKSUM OK)
00:03:59.162508 IP 90.127.xx.yy > 92.184.107.239: ICMP echo reply, id 32208, seq 1, length 37 # => départ de la réponse depuis la livebox sur le vlan 832 vers l'ip de l'airbox (CHKSUM OK)
# => absence de retour de la réponse sur l'interface de l'airbox (normal, vu le problème).

* La même chose pour le tcp:
* DNAT TCP my.external.ip / 61234 => PC / 9999
* shell 1: echo -ne "\x00\x0f\x00\x00\x00" | nc -N -l 9999
* shell 2: nc -N my.external.ip 61234 | od (Taper Ctrl-D pour terminer proprement la connection, ou utiliser -d)
=> Jamais de fin et multiple re-transmission TCP du paquet contenant la charge utile

Code: [Sélectionner]

00:31:52.859289 IP 92.184.107.239.43856 > 90.127.xx.yy.61234: Flags [S], seq 360100060, win 64240, options [mss 1400,sackOK,TS val 485948444 ecr 0,nop,wscale 10], length 0
00:31:52.859491 IP 92.184.107.239.43856 > 192.168.1.16.9999: Flags [S], seq 360100060, win 64240, options [mss 1400,sackOK,TS val 485948444 ecr 0,nop,wscale 10], length 0
00:31:52.859558 IP 192.168.1.16.9999 > 92.184.107.239.43856: Flags [S.], seq 275788681, ack 360100061, win 65160, options [mss 1460,sackOK,TS val 4255433512 ecr 485948444,nop,wscale 10], length 0
00:31:52.859765 IP 90.127.xx.yy.61234 > 92.184.107.239.43856: Flags [S.], seq 275788681, ack 360100061, win 65160, options [mss 1460,sackOK,TS val 4255433512 ecr 485948444,nop,wscale 10], length 0
00:31:52.825180 IP 192.168.1.100.43856 > 90.127.xx.yy.61234: Flags [S], seq 360100060, win 64240, options [mss 1460,sackOK,TS val 485948444 ecr 0,nop,wscale 10], length 0
00:31:52.873415 IP 90.127.xx.yy.61234 > 192.168.1.100.43856: Flags [S.], seq 275788681, ack 360100061, win 65160, options [mss 1400,sackOK,TS val 4255433512 ecr 485948444,nop,wscale 10], length 0
00:31:52.873469 IP 192.168.1.100.43856 > 90.127.xx.yy.61234: Flags [.], ack 1, win 63, options [nop,nop,TS val 485948493 ecr 4255433512], length 0
00:31:52.917035 IP 90.127.xx.yy.61234 > 192.168.1.100.43856: Flags [F.], seq 6, ack 1, win 64, options [nop,nop,TS val 4255433561 ecr 485948493], length 0
00:31:52.917065 IP 192.168.1.100.43856 > 90.127.xx.yy.61234: Flags [.], ack 1, win 63, options [nop,nop,TS val 485948536 ecr 4255433512,nop,nop,sack 1 {6:7}], length 0
00:31:52.909027 IP 92.184.107.239.43856 > 90.127.xx.yy.61234: Flags [.], ack 1, win 63, options [nop,nop,TS val 485948493 ecr 4255433512], length 0
00:31:52.909200 IP 92.184.107.239.43856 > 192.168.1.16.9999: Flags [.], ack 1, win 63, options [nop,nop,TS val 485948493 ecr 4255433512], length 0
00:31:52.909373 IP 192.168.1.16.9999 > 92.184.107.239.43856: Flags [P.], seq 1:6, ack 1, win 64, options [nop,nop,TS val 4255433561 ecr 485948493], length 5
00:31:52.909398 IP 192.168.1.16.9999 > 92.184.107.239.43856: Flags [F.], seq 6, ack 1, win 64, options [nop,nop,TS val 4255433561 ecr 485948493], length 0
00:31:52.909606 IP 90.127.xx.yy.61234 > 92.184.107.239.43856: Flags [P.], seq 1:6, ack 1, win 64, options [nop,nop,TS val 4255433561 ecr 485948493], length 5
00:31:52.909757 IP 90.127.xx.yy.61234 > 92.184.107.239.43856: Flags [F.], seq 6, ack 1, win 64, options [nop,nop,TS val 4255433561 ecr 485948493], length 0
00:31:52.938866 IP 92.184.107.239.43856 > 90.127.xx.yy.61234: Flags [.], ack 1, win 63, options [nop,nop,TS val 485948536 ecr 4255433512,nop,nop,sack 1 {6:7}], length 0
00:31:52.938978 IP 92.184.107.239.43856 > 192.168.1.16.9999: Flags [.], ack 1, win 63, options [nop,nop,TS val 485948536 ecr 4255433512,nop,nop,sack 1 {6:7}], length 0
00:31:52.957857 IP 192.168.1.16.9999 > 92.184.107.239.43856: Flags [P.], seq 1:6, ack 1, win 64, options [nop,nop,TS val 4255433610 ecr 485948536], length 5
00:31:52.958099 IP 90.127.xx.yy.61234 > 92.184.107.239.43856: Flags [P.], seq 1:6, ack 1, win 64, options [nop,nop,TS val 4255433610 ecr 485948536], length 5
00:31:53.209856 IP 192.168.1.16.9999 > 92.184.107.239.43856: Flags [P.], seq 1:6, ack 1, win 64, options [nop,nop,TS val 4255433862 ecr 485948536], length 5
00:31:53.210115 IP 90.127.xx.yy.61234 > 92.184.107.239.43856: Flags [P.], seq 1:6, ack 1, win 64, options [nop,nop,TS val 4255433862 ecr 485948536], length 5
00:31:53.733860 IP 192.168.1.16.9999 > 92.184.107.239.43856: Flags [P.], seq 1:6, ack 1, win 64, options [nop,nop,TS val 4255434386 ecr 485948536], length 5
00:31:53.734125 IP 90.127.xx.yy.61234 > 92.184.107.239.43856: Flags [P.], seq 1:6, ack 1, win 64, options [nop,nop,TS val 4255434386 ecr 485948536], length 5
00:31:54.429202 IP 92.184.107.239.43856 > 90.127.xx.yy.61234: Flags [F.], seq 1, ack 1, win 63, options [nop,nop,TS val 485950031 ecr 4255433512,nop,nop,sack 1 {6:7}], length 0
00:31:54.429414 IP 92.184.107.239.43856 > 192.168.1.16.9999: Flags [F.], seq 1, ack 1, win 63, options [nop,nop,TS val 485950031 ecr 4255433512,nop,nop,sack 1 {6:7}], length 0
00:31:54.429432 IP 192.168.1.16.9999 > 92.184.107.239.43856: Flags [.], ack 2, win 64, options [nop,nop,TS val 4255435081 ecr 485950031], length 0
00:31:54.429653 IP 90.127.xx.yy.61234 > 92.184.107.239.43856: Flags [.], ack 2, win 64, options [nop,nop,TS val 4255435081 ecr 485950031], length 0
00:31:54.411918 IP 192.168.1.100.43856 > 90.127.xx.yy.61234: Flags [F.], seq 1, ack 1, win 63, options [nop,nop,TS val 485950031 ecr 4255433512,nop,nop,sack 1 {6:7}], length 0
00:31:54.437008 IP 90.127.xx.yy.61234 > 192.168.1.100.43856: Flags [.], ack 2, win 64, options [nop,nop,TS val 4255435081 ecr 485950031], length 0
00:31:54.757851 IP 192.168.1.16.9999 > 92.184.107.239.43856: Flags [P.], seq 1:6, ack 2, win 64, options [nop,nop,TS val 4255435410 ecr 485950031], length 5
00:31:54.758142 IP 90.127.xx.yy.61234 > 92.184.107.239.43856: Flags [P.], seq 1:6, ack 2, win 64, options [nop,nop,TS val 4255435410 ecr 485950031], length 5
00:31:56.773858 IP 192.168.1.16.9999 > 92.184.107.239.43856: Flags [P.], seq 1:6, ack 2, win 64, options [nop,nop,TS val 4255437426 ecr 485950031], length 5
00:31:56.774176 IP 90.127.xx.yy.61234 > 92.184.107.239.43856: Flags [P.], seq 1:6, ack 2, win 64, options [nop,nop,TS val 4255437426 ecr 485950031], length 5
00:32:00.901863 IP 192.168.1.16.9999 > 92.184.107.239.43856: Flags [P.], seq 1:6, ack 2, win 64, options [nop,nop,TS val 4255441554 ecr 485950031], length 5
00:32:00.902166 IP 90.127.xx.yy.61234 > 92.184.107.239.43856: Flags [P.], seq 1:6, ack 2, win 64, options [nop,nop,TS val 4255441554 ecr 485950031], length 5
00:32:09.093869 IP 192.168.1.16.9999 > 92.184.107.239.43856: Flags [P.], seq 1:6, ack 2, win 64, options [nop,nop,TS val 4255449746 ecr 485950031], length 5
00:32:09.094252 IP 90.127.xx.yy.61234 > 92.184.107.239.43856: Flags [P.], seq 1:6, ack 2, win 64, options [nop,nop,TS val 4255449746 ecr 485950031], length 5
00:32:25.221876 IP 192.168.1.16.9999 > 92.184.107.239.43856: Flags [P.], seq 1:6, ack 2, win 64, options [nop,nop,TS val 4255465874 ecr 485950031], length 5
00:32:25.222155 IP 90.127.xx.yy.61234 > 92.184.107.239.43856: Flags [P.], seq 1:6, ack 2, win 64, options [nop,nop,TS val 4255465874 ecr 485950031], length 5
00:32:59.013858 IP 192.168.1.16.9999 > 92.184.107.239.43856: Flags [P.], seq 1:6, ack 2, win 64, options [nop,nop,TS val 4255499666 ecr 485950031], length 5

Conclusions:
* La livebox est pour moi totalement hors de cause (je m'en doutais, mais au moins, comme ça plus de doute).
* Cela impact bien TOUS les protocoles, pour peu que l'on respecte le «pattern» (taille de paquet (ethernet) de 71 octets +N*16, et octet 67 qui match le pattern donné par hwit: x0xx1xxx).

Y a plus qu'à attendre que les gars d'Orange fassent leur taff :/, je vois pas trop comment on pourrait identifier l'interface réseau de la machine qui pose problème: 80.10.236.81

Caeies, finalement pas fou, mais dégouté.

hwti · « **Réponse #39 le:** 03 juillet 2022 à 03:36:14 »

Si les checksums de ce qui sort de la Livebox sont corrects, et qu'en plus l'ONT a déjà été changé, il n'y a effectivement plus qu'à espérer que le problème remontera aux équipes réseau d'Orange.

Est-ce qu'il y a des ICMP en entrée dans la capture ? On ne sait jamais, peut-être que l'équipement qui perd le paquet le signale.

caeies · « **Réponse #40 le:** 03 juillet 2022 à 23:58:14 »

Non, Je vois rien autour.

J'en ai profité pour regarder l'IPV6 et ça tombe en plein dans les «flags» du TCP, lorsqu'il est activé à PUSH ... autrement dit c'est aussi fréquent :/ (il faut cependant que la taille de la trame soit à 13+N*16). Et il faut lire 68e octet, d'adresse 0x43 dans le paquet (hors vlan).

Bref l'intégrale. Mais le fait que ça tombe dans les flags du TCPv6 me fait me demander si c'est pas l'origine du problème. Car l'autre flag impacté c'est ... l'ECN-echo. Bref c'est une coincidence pour le moins étrange.

Caeies,

hwti · « **Réponse #41 le:** 04 juillet 2022 à 00:20:38 »

Avec l'ICMP, l'octet en question était toujours proche de la fin (on pouvait rajouter 16 octets de données, mais au début).

En TCPv6, ce ne serait plus le cas ?
Pour que ça tombe dans les flags, il faut que ce soit différent.

caeies · « **Réponse #42 le:** 04 juillet 2022 à 09:02:10 »

Ah, tu as raison. J'avais pas fait gaffe qu'il fallait que ce soit le dernier mot du paquet qui corresponde au motif.

Du même coup ce serait l'optimiseur qui calcul le checksum qui serait déficient? (on peut supposer qu'il y a une accélération HW par paquets de 16 octets, et que la dernière partie passe par un autre bout de code ?).

Caeies.

hwti · « **Réponse #43 le:** 04 juillet 2022 à 11:22:49 »

Pour un calcul de checksum, ce serait bizarre : c'est correct pour 3 des 4 possibilités sur les deux bits qui posent problème.
Peut-être qu'il s'agit d'une logique de filtrage de trames/paquets qui se trouve appliquée au mauvais endroit, suivant la manière donc le dernier bloc incomplet (< 16 octets) est traité.

caeies · « **Réponse #44 le:** 04 juillet 2022 à 11:55:29 »

Mais si c'est un filtrage, pourquoi ne serait-il présent que sur la machine incriminée et pas les autres ? ça me parait être un sérieux ratage si c'est le cas (bon ok, c'est orange

).

caeies · « **Réponse #45 le:** 06 juillet 2022 à 13:08:34 »

Bon,

Je viens de rappeler le 3900 faute de retour de leurs part. Je découvre que le ticket Oceane a été traité en disant qu'il y a un problème entre la livebox et l'ONT ... Dommage, ils auraient pu prendre contact avec moi pour que je leur explique tous les tests que j'ai fais pour écarter cette hypothèse...

Du même coup, le technicien du support, qui est un ancien de FT, va relancer le ticket autrement. Donc ça va remonter les étages, niveau 2 puis niveau 3 et j'espère que ce coup-ci les gars du niveau 3 ne diront pas que le niveau 1 n'a pas vérifié le BA-BA.

Je vais voir s'il me reste le convertisseur optique de mon ancienne livebox ça permettrait de faire le test «en direct» pour qu'ils arrêtent de faire une fixette là-dessus.

J'espère avoir du nouveau Vendredi matin

, mais je me fais pas beaucoup d'illusions.

cetipabo · « **Réponse #46 le:** 06 juillet 2022 à 13:13:20 »

Citation de: caeies le 03 juillet 2022 à 01:22:49

Y a plus qu'à attendre que les gars d'Orange fassent leur taff :/

sur une offre grand publique...as-tu préparé ton testament ? ca risque de prendre du temps...

Sur une offre PRO ils n'ont pas voulu admettre qu'une mise a jour du firmware de la LB a causé un dysfonctionnement total dans ma boite. et j'ai su par la suite que je n'étais pas le seul.

caeies · « **Réponse #47 le:** 06 juillet 2022 à 14:52:48 »

Citer

sur une offre grand publique...as-tu préparé ton testament ? ca risque de prendre du temps...

Je suis du genre obstiné

.

J'ai lu ton fil, ça fait vraiment penser à une «nouvelle feature» mal testée ton histoire ... C'est soft@Home qui produit le FW des livebox ou c'est vraiment interne à Orange ?

Caeies,

Auteur Sujet: Connexions TCP aléatoirement gelées en upload (Lu 8031 fois)

cetipabo