La Fibre
Fournisseurs d'accès à Internet fixe en France métropolitaine => Orange / Sosh => 
Débit fibre => Discussion démarrée par: caeies le 22 juin 2022 à 01:19:02
-
Bonsoir à tous,
Je ne sais pas si je suis dans le «bon» forum, étant donné la typologie du problème que je rencontre actuellement. Si ce n'est pas le cas, n'hésitez pas à déplacer le post au bon endroit :).
Pour faire court (et j'espère compréhensible):
J'ai la fibre orange depuis ~8 ans (contraint et forcé à l'époque, y avait que ça dans ma rue). J'ai jamais vraiment eu de problème notoire avec.
Depuis environ 3 semaines (presque 4 maintenant), certaines de mes connections TCP sont purement et simplement (mais aléatoirement !) «jetées» dans le sens «chez moi» => «serveur». J'ai vérifié via une capture wireshark entre l'ONT et la livebox 4 que les paquets TCP qui sont rejoués sont tous bien bloqués, et ce jusqu'au reset de la connection par la partie «Home». Les autres connexions restent fonctionnelles pour ce que j'en vois, et ça semble toucher plus l'IPv4 que l'IPv6.
Ces paquets TCP jetés sont petits (entre 145 et 518 octects pour le plus gros que j'ai vu).
Je vous passe les détails des 3 semaines d'investigation et de l'horreur que c'est lorsque l'on télétravaille.
Je suis en contact avec le support Orange (on m'a fait la totale, changer la livebox, l'ONT (ça je m'en souviendrais)) mais j'ai pas l'impression qu'ils y comprennent grand chose (tous les tests qu'ils font sont «ok»).
Bref je suis un peu à bout et je voudrais savoir comment investiguer «plus efficacement» pour résoudre ce problème au plus vite.
Suis-je le seul à constater ce genre de problème, j'ai pas vu de description sur le forum qui évoque ce type de soucis (à part les histoires de BBR vs CUBIC, mais j'y crois pas car tous les terminaux ici sont impactés).
Des idées ?
Merci d'avance,
Caeies.
Ps: plus de détails sur https://linuxfr.org/users/caeies/journaux/la-fibre-orange-hoquette-ou-comment-devenir-fou (https://linuxfr.org/users/caeies/journaux/la-fibre-orange-hoquette-ou-comment-devenir-fou)
-
C'est faisable un test avec un PC sous Linux en direct sur l'ONT?
VLAN 832
DHCP avec quelques options obligatoires (il y a une appli sur le forum qui permet de les récupérer).
Requête DHCP avec la COS à 6 (et seulement le DHCP).
Idem en DHCPv6.
Ce genre de galère avec TCP ça m'arrivait aussi en IPv6 chez Free. C'était à cause de la MTU (MTU IPv6 = 1480 et pas 1500).
Question annexe: t'as des switchs branchés entre l'ONT et la Livebox? Si c'est le cas, t'as pensé à augmenter la MTU (genre 1700) pour faire passer des paquets un peu plus gros que prévu? Je ne crois pas que Orange fasse des jumbo frames mais sait-on jamais... Le fait de voir un petit paquet partir de la box, mais pas la réponse du serveur en face peut faire dire que la switch a supprimé (en silence) un paquet dépassant sa MTU.
-
La perte de paquet, lors d'un transfert TCP n'est pas anormal, TCP ne connais pas le débit maximum de ta ligne, il va aller au-delà du débit max.
Il serait intéressant de tester la perte dans un sens et dans l'autre en UDP avec iperf3.
Un câble Ethernet défectueux pourrait être la cause comme une carte réseau défectueuse. Confirmer le test avec un second PC est intéressant, si possible avec une pile logicielle différente, par exemple en démarrant sur un live USB d'un autre linux.
-
Merci à tous les deux pour vos retours.
Oui la perte d'un paquet TCP n'est pas anormal (bien que très surprenant sur du «bas» débit, je déclenche le problème avec un simple message d'une taille que quelques octets sur mon lien vpn avec la boite) effectivement. Mais là ce qu'il se passe, c'est que le rejeu ne passe pas non plus, figeant la connection dans le sens Home -> Boite, alors que le sens Boite -> Home continu d'envoyer du traffic (car la fenêtre TCP est grande, vu la qualité de la ligne en temps normal).
Faire les tests iperf3 pourquoi pas, mais j'ai déjà des résultats avec nperf et c'est très très aléatoire. Parfois je suis full speed en download et upload, parfois l'upload est purement et simplement stoppé après la moitié du test, ou l'upload fait le yoyo ...
Ce qui me fait écarter le problème matériel pour l'instant, c'est qu'une fois le paquet TCP coincé, c'est fini la connexion est «morte». Si c'était matériel, les paquets seraient jetés aléatoirement et la connexion TCP ne serait que très légèrement impactée, pas gelée dans cet état. Mais peut être que je rate quelque chose.
Pour les tests, j'ai fait tous les OS, via wifi pour être en direct sur la livebox, ou via le filaire (ma maison est cablée en Gigabit).
Pour la capture entre la livebox et l'ONT, j'ai juste mis un switch avec une config pas trop pourrie et un port mirroring renvoyant le traffic sur un PC qui faisait tourner wireshark.
J'ai pas testé le direct derrière l'ONT, car ça implique de tout faire tomber et vu là ou est l'ONT (mon garage) il faut que je trouve un PC portable en Gb filaire, et c'est moins facile :).
Et c'est clairement pas un problème de MTU, ça se verrait effectivement sur les gros paquets (mais ce problème j'ai l'habitude de le diagnostiquer chez les opérateurs mobiles en roaming :). Bref pas les mêmes symptômes.
-
Bon,
voici un test en upload sur ping.online.net (udp) (abrégé):
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-30.00 sec 358 MBytes 100 Mbits/sec 0.000 ms 0/258977 (0%) sender
[ 5] 0.00-30.00 sec 358 MBytes 100 Mbits/sec 0.150 ms 126/258976 (0.049%) receiver
[ 7] 0.00-30.00 sec 358 MBytes 100 Mbits/sec 0.000 ms 0/258977 (0%) sender
[ 7] 0.00-30.00 sec 358 MBytes 100 Mbits/sec 0.156 ms 127/258977 (0.049%) receiver
[ 9] 0.00-30.00 sec 358 MBytes 100 Mbits/sec 0.000 ms 0/258977 (0%) sender
[ 9] 0.00-30.00 sec 358 MBytes 100 Mbits/sec 0.161 ms 130/258977 (0.05%) receiver
[ 11] 0.00-30.00 sec 358 MBytes 100 Mbits/sec 0.000 ms 0/258977 (0%) sender
[ 11] 0.00-30.00 sec 358 MBytes 100 Mbits/sec 0.174 ms 147/258976 (0.057%) receiver
[SUM] 0.00-30.00 sec 1.40 GBytes 400 Mbits/sec 0.000 ms 0/1035908 (0%) sender
[SUM] 0.00-30.00 sec 1.40 GBytes 400 Mbits/sec 0.160 ms 530/1035906 (0.051%) receiver
Server output:
iperf 3.1.3
Linux ping 4.15.0-47-generic #50-Ubuntu SMP Wed Mar 13 10:44:52 UTC 2019 x86_64
-----------------------------------------------------------
Server listening on 5208
-----------------------------------------------------------
Time: Wed, 22 Jun 2022 08:32:52 GMT
Accepted connection from 90.127.xx.yy, port 60908
Cookie: ray463bom62q6qs6xz4kt7npvhu4fqa72dbw
[ 5] local 62.210.18.40 port 5208 connected to 90.127.xx.yy port 39245
[ 6] local 62.210.18.40 port 5208 connected to 90.127.xx.yy port 38666
[ 8] local 62.210.18.40 port 5208 connected to 90.127.xx.yy port 42955
[ 10] local 62.210.18.40 port 5208 connected to 90.127.xx.yy port 55492
Starting Test: protocol: UDP, 4 streams, 1448 byte blocks, omitting 1 seconds, 30 second test
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 5] 0.00-2.00 sec 23.8 MBytes 100 Mbits/sec 0.165 ms 126/25874 (0.49%)
[ 6] 0.00-2.00 sec 23.8 MBytes 100 Mbits/sec 0.158 ms 127/25875 (0.49%)
[ 8] 0.00-2.00 sec 23.8 MBytes 100 Mbits/sec 0.172 ms 130/25874 (0.5%)
[ 10] 0.00-2.00 sec 23.8 MBytes 100 Mbits/sec 0.168 ms 147/25874 (0.57%)
[SUM] 0.00-2.00 sec 95.4 MBytes 400 Mbits/sec 0.166 ms 530/103497 (0.51%)
- - - - - - - - - - - - - - - - - - - - - - - - -
[ 5] 2.00-4.00 sec 23.8 MBytes 100 Mbits/sec 0.132 ms 0/17266 (0%)
[ 6] 2.00-4.00 sec 23.8 MBytes 100 Mbits/sec 0.134 ms 0/17265 (0%)
[ 8] 2.00-4.00 sec 23.8 MBytes 100 Mbits/sec 0.133 ms 0/17265 (0%)
[ 10] 2.00-4.00 sec 23.8 MBytes 100 Mbits/sec 0.132 ms 0/17265 (0%)
[SUM] 2.00-4.00 sec 95.4 MBytes 400 Mbits/sec 0.133 ms 0/69061 (0%)
- - - - - - - - - - - - - - - - - - - - - - - - -
Si je tente de saturer le lien, je vois que l'upload est au alentours de 410 Mbits/sec d'une manière très stable.
Il faudra que je refasse les tests l'après midi, c'est là que c'est le pire.
Les traces routes montrent une divergence à partir du 4e saut:
193.252.159.42 pour ping online vs 193.252.98.94 pour mon taff
Cordialement,
-
nPerf utilise de nombreuses connexions TCP, ce n'est pas une bonne solution pour faire des tests.
Pour un test TCP, privilégie SpeedTest.net en mode "mono-connexion".
À vérifier si cela impacte aussi bien IPv4 que IPv6 (certains serveurs font le test en IPv6 comme le serveur de Massy et d'autres en IPv4 comme le serveur de Palaiseau, les deux serveurs étant chez Bouygues Telecom en BBR, seul le protocole change et des choses à la marge, Massy vient d'être passé sur Ubuntu server 22.04 alors que Palaiseau est sur Ubuntu server 20.04)
iPerf3 permet de voir le pourcentage de perte de paquet en UDP, a un débit fixé et permet de voir qand quel sens (montant ou descendant) il y a les pertes.
Normalement la perte est nulle si le débit est pas trop élevé.
-
Un problème comme ça par exemple :
iperf3 -c ping.online.net -O1 -t 20 -i 1 -p 5208 -u -b 200M --get-server-output
Connecting to host ping.online.net, port 5208
[ 5] local 192.168.1.16 port 56038 connected to 62.210.18.40 port 5208
[ ID] Interval Transfer Bitrate Total Datagrams
[ 5] 0.00-1.00 sec 23.8 MBytes 200 Mbits/sec 17253 (omitted)
[ 5] 0.00-1.00 sec 23.8 MBytes 200 Mbits/sec 17265
[ 5] 1.00-2.00 sec 23.8 MBytes 200 Mbits/sec 17265
[ 5] 2.00-3.00 sec 23.8 MBytes 200 Mbits/sec 17265
[ 5] 3.00-4.00 sec 23.8 MBytes 200 Mbits/sec 17266
[ 5] 4.00-5.00 sec 23.8 MBytes 200 Mbits/sec 17265
[ 5] 5.00-6.00 sec 23.8 MBytes 200 Mbits/sec 17265
[ 5] 6.00-7.00 sec 23.8 MBytes 200 Mbits/sec 17265
[ 5] 7.00-8.00 sec 23.8 MBytes 200 Mbits/sec 17265
[ 5] 8.00-9.00 sec 23.8 MBytes 200 Mbits/sec 17265
[ 5] 9.00-10.00 sec 23.8 MBytes 200 Mbits/sec 17265
[ 5] 10.00-11.00 sec 23.8 MBytes 200 Mbits/sec 17266
[ 5] 11.00-12.00 sec 23.8 MBytes 200 Mbits/sec 17266
[ 5] 12.00-13.00 sec 23.8 MBytes 200 Mbits/sec 17264
[ 5] 13.00-14.00 sec 23.8 MBytes 200 Mbits/sec 17266
[ 5] 14.00-15.00 sec 23.8 MBytes 200 Mbits/sec 17264
[ 5] 15.00-16.00 sec 23.8 MBytes 200 Mbits/sec 17266
[ 5] 16.00-17.00 sec 23.8 MBytes 200 Mbits/sec 17265
[ 5] 17.00-18.00 sec 23.8 MBytes 200 Mbits/sec 17265
[ 5] 18.00-19.00 sec 23.8 MBytes 200 Mbits/sec 17265
[ 5] 19.00-20.00 sec 23.8 MBytes 200 Mbits/sec 17266
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-20.00 sec 477 MBytes 200 Mbits/sec 0.000 ms 0/345304 (0%) sender
[ 5] 0.00-20.00 sec 477 MBytes 200 Mbits/sec 0.064 ms 36/345304 (0.01%) receiver
Server output:
iperf 3.1.3
Linux ping 4.15.0-47-generic #50-Ubuntu SMP Wed Mar 13 10:44:52 UTC 2019 x86_64
-----------------------------------------------------------
Server listening on 5208
-----------------------------------------------------------
Time: Wed, 22 Jun 2022 15:47:43 GMT
Accepted connection from 90.127.xx.yy, port 48152
Cookie: or3jrmirjdptobzvw5ydo2cvv4xnfkt2elv5
[ 8] local 62.210.18.40 port 5208 connected to 90.127.xx.yy port 56038
Starting Test: protocol: UDP, 1 streams, 1448 byte blocks, omitting 1 seconds, 307200 bytes to send
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 8] 0.00-2.00 sec 47.7 MBytes 200 Mbits/sec 0.036 ms 10/51742 (0.019%)
[ 8] 2.00-4.00 sec 47.7 MBytes 200 Mbits/sec 0.054 ms 0/34537 (0%)
[ 8] 4.00-6.00 sec 47.7 MBytes 200 Mbits/sec 0.071 ms 0/34530 (0%)
[ 8] 6.00-8.00 sec 47.7 MBytes 200 Mbits/sec 0.063 ms 0/34529 (0%)
[ 8] 8.00-10.00 sec 47.7 MBytes 200 Mbits/sec 0.060 ms 0/34526 (0%)
[ 8] 10.00-12.00 sec 47.7 MBytes 200 Mbits/sec 0.047 ms 0/34537 (0%)
[ 8] 12.00-14.00 sec 47.7 MBytes 200 Mbits/sec 0.039 ms 0/34524 (0%)
[ 8] 14.00-16.00 sec 47.7 MBytes 200 Mbits/sec 0.096 ms 0/34531 (0%)
[ 8] 16.00-18.00 sec 47.7 MBytes 200 Mbits/sec 0.045 ms 0/34529 (0%)
[ 8] 18.00-20.00 sec 47.6 MBytes 200 Mbits/sec 0.034 ms 26/34530 (0.075%)
[ 8] 20.00-20.00 sec 59.4 KBytes 200 Mbits/sec 0.064 ms 0/42 (0%)
- - - - - - - - - - - - - - - - - - - - - - - - -
Test Complete. Summary Results:
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 8] 0.00-20.00 sec 0.00 Bytes 0.00 bits/sec 0.064 ms 26/345345 (0.0075%)
CPU Utilization: local/receiver 9.9% (1.4%u/8.5%s), remote/sender 6.6% (1.5%u/5.1%s)
iperf Done.
J'ai eu un nouveau technicien, l'ancien ne m'ayant pas rappelé, il envoie un tech car il considère que le signal optique est dégradé .... je vois pas trop le rapport, mais bon, je vais avoir de la visite :/
Merci pour votre aide.
-
Le pourcentage de perte de paquet est trop faible pour avoir un impact fort sur ta connexion.
C'est étrange.
-
Bon je viens de faire le test, mais dans l'autre sens:
iperf3 -c ping.online.net -O1 -t 20 -i 1 -p 5209 -R -u -b 200M --get-server-output
Connecting to host ping.online.net, port 5209
Reverse mode, remote host ping.online.net is sending
[ 5] local 192.168.1.16 port 34386 connected to 62.210.18.40 port 5209
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-1.00 sec 21.8 MBytes 183 Mbits/sec 0.017 ms 0/15800 (0%) (omitted)
[ 5] 0.00-1.00 sec 23.7 MBytes 198 Mbits/sec 0.263 ms 133/17266 (0.77%)
[ 5] 1.00-2.00 sec 23.9 MBytes 200 Mbits/sec 0.125 ms 0/17290 (0%)
[ 5] 2.00-3.00 sec 23.5 MBytes 197 Mbits/sec 0.363 ms 204/17244 (1.2%)
[ 5] 3.00-4.00 sec 23.7 MBytes 199 Mbits/sec 0.336 ms 116/17262 (0.67%)
[ 5] 4.00-5.00 sec 23.7 MBytes 199 Mbits/sec 0.200 ms 146/17288 (0.84%)
[ 5] 5.00-6.00 sec 23.8 MBytes 199 Mbits/sec 0.365 ms 40/17248 (0.23%)
[ 5] 6.00-7.00 sec 23.9 MBytes 200 Mbits/sec 0.181 ms 0/17300 (0%)
[ 5] 7.00-8.00 sec 23.8 MBytes 200 Mbits/sec 0.173 ms 0/17244 (0%)
[ 5] 8.00-9.00 sec 23.9 MBytes 201 Mbits/sec 0.072 ms 0/17312 (0%)
[ 5] 9.00-10.00 sec 23.9 MBytes 200 Mbits/sec 0.080 ms 0/17274 (0%)
[ 5] 10.00-11.00 sec 23.8 MBytes 200 Mbits/sec 0.129 ms 0/17238 (0%)
[ 5] 11.00-12.00 sec 23.8 MBytes 200 Mbits/sec 0.088 ms 0/17266 (0%)
[ 5] 12.00-13.00 sec 23.7 MBytes 199 Mbits/sec 0.196 ms 10/17208 (0.058%)
[ 5] 13.00-14.00 sec 23.8 MBytes 200 Mbits/sec 0.306 ms 1/17266 (0.0058%)
[ 5] 14.00-15.00 sec 23.7 MBytes 199 Mbits/sec 0.588 ms 58/17214 (0.34%)
[ 5] 15.00-16.00 sec 23.6 MBytes 198 Mbits/sec 0.544 ms 163/17276 (0.94%)
[ 5] 16.00-17.00 sec 23.6 MBytes 198 Mbits/sec 0.532 ms 142/17242 (0.82%)
[ 5] 17.00-18.00 sec 23.9 MBytes 200 Mbits/sec 0.156 ms 0/17287 (0%)
[ 5] 18.00-19.00 sec 23.7 MBytes 199 Mbits/sec 0.350 ms 126/17312 (0.73%)
[ 5] 19.00-20.00 sec 23.7 MBytes 199 Mbits/sec 0.162 ms 155/17309 (0.9%)
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-20.00 sec 477 MBytes 200 Mbits/sec 0.000 ms 0/345346 (0%) sender
[ 5] 0.00-20.00 sec 475 MBytes 199 Mbits/sec 0.162 ms 1294/345346 (0.37%) receiver
Server output:
iperf 3.1.3
Linux ping 4.15.0-47-generic #50-Ubuntu SMP Wed Mar 13 10:44:52 UTC 2019 x86_64
-----------------------------------------------------------
Server listening on 5209
-----------------------------------------------------------
Time: Wed, 22 Jun 2022 19:04:52 GMT
Accepted connection from 90.127.xx.yy, port 44474
Cookie: nivyvdlfamivof7p7l6sqxocsubfzxg4wtjq
[ 8] local 62.210.18.40 port 5209 connected to 90.127.xx.yy port 34386
Starting Test: protocol: UDP, 1 streams, 1448 byte blocks, omitting 1 seconds, 20 second test
[ ID] Interval Transfer Bandwidth Total Datagrams
[ 8] 0.00-2.00 sec 47.7 MBytes 200 Mbits/sec 50341
[ 8] 2.00-4.00 sec 47.7 MBytes 200 Mbits/sec 34527
[ 8] 4.00-6.00 sec 47.7 MBytes 200 Mbits/sec 34531
[ 8] 6.00-8.00 sec 47.7 MBytes 200 Mbits/sec 34534
[ 8] 8.00-10.00 sec 47.8 MBytes 200 Mbits/sec 34586
[ 8] 10.00-12.00 sec 47.6 MBytes 200 Mbits/sec 34499
[ 8] 12.00-14.00 sec 47.6 MBytes 200 Mbits/sec 34489
[ 8] 14.00-16.00 sec 47.6 MBytes 200 Mbits/sec 34490
[ 8] 16.00-18.00 sec 47.7 MBytes 200 Mbits/sec 34515
[ 8] 18.00-20.00 sec 47.8 MBytes 201 Mbits/sec 34628
[ 8] 20.00-20.00 sec 370 KBytes 1.19 Gbits/sec 262
- - - - - - - - - - - - - - - - - - - - - - - - -
Test Complete. Summary Results:
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 8] 0.00-20.00 sec 477 MBytes 200 Mbits/sec 0.000 ms 0/345602 (0%)
CPU Utilization: local/sender 5.2% (0.7%u/4.5%s), remote/receiver 1.7% (0.2%u/1.5%s)
iperf Done.
En sachant que c'est l'émission des paquets tcp qui pose problème, je suis en train de préparer une capture wireshark «anonyme» pour une expertise «externe».
Cordialement,
-
J'en ai fait un plus long, avec un débit plus faible:
iperf3 -c ping.online.net -O1 -i 5 -Z -t 180 -p 5209 -R -u -b 20M --get-server-output
Connecting to host ping.online.net, port 5209
Reverse mode, remote host ping.online.net is sending
[ 5] local 192.168.1.16 port 35056 connected to 62.210.18.40 port 5209
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-5.00 sec 11.9 MBytes 20.0 Mbits/sec 0.035 ms 0/10196 (0%)
[ 5] 5.00-10.00 sec 11.9 MBytes 20.0 Mbits/sec 0.020 ms 0/8649 (0%)
[ 5] 10.00-15.00 sec 11.9 MBytes 20.0 Mbits/sec 0.054 ms 0/8618 (0%)
[ 5] 15.00-20.00 sec 11.9 MBytes 20.0 Mbits/sec 0.060 ms 0/8625 (0%)
[ 5] 20.00-25.00 sec 11.9 MBytes 20.0 Mbits/sec 0.046 ms 0/8641 (0%)
[ 5] 25.00-30.00 sec 11.9 MBytes 20.0 Mbits/sec 0.030 ms 0/8641 (0%)
[ 5] 30.00-35.00 sec 11.9 MBytes 20.0 Mbits/sec 0.066 ms 0/8622 (0%)
[ 5] 35.00-40.00 sec 11.9 MBytes 20.0 Mbits/sec 0.052 ms 0/8630 (0%)
[ 5] 40.00-45.00 sec 11.9 MBytes 20.0 Mbits/sec 0.021 ms 0/8646 (0%)
[ 5] 45.00-50.00 sec 11.9 MBytes 20.0 Mbits/sec 0.048 ms 0/8616 (0%)
[ 5] 50.00-55.00 sec 11.9 MBytes 20.0 Mbits/sec 0.040 ms 8/8634 (0.093%)
[ 5] 55.00-60.00 sec 11.9 MBytes 20.0 Mbits/sec 0.040 ms 3/8642 (0.035%)
[ 5] 60.00-65.00 sec 11.8 MBytes 19.8 Mbits/sec 0.059 ms 63/8621 (0.73%)
[ 5] 65.00-70.00 sec 11.9 MBytes 20.0 Mbits/sec 0.061 ms 0/8633 (0%)
[ 5] 70.00-75.00 sec 11.9 MBytes 20.0 Mbits/sec 0.073 ms 6/8636 (0.069%)
[ 5] 75.00-80.00 sec 11.9 MBytes 19.9 Mbits/sec 0.040 ms 25/8629 (0.29%)
[ 5] 80.00-85.00 sec 11.9 MBytes 19.9 Mbits/sec 0.037 ms 37/8633 (0.43%)
[ 5] 85.00-90.00 sec 11.9 MBytes 20.0 Mbits/sec 0.058 ms 1/8632 (0.012%)
[ 5] 90.00-95.00 sec 11.9 MBytes 20.0 Mbits/sec 0.037 ms 0/8634 (0%)
[ 5] 95.00-100.00 sec 11.9 MBytes 20.0 Mbits/sec 0.039 ms 6/8647 (0.069%)
[ 5] 100.00-105.00 sec 11.9 MBytes 20.0 Mbits/sec 0.027 ms 3/8630 (0.035%)
[ 5] 105.00-110.00 sec 11.9 MBytes 20.0 Mbits/sec 0.016 ms 0/8622 (0%)
[ 5] 110.00-115.00 sec 11.9 MBytes 20.0 Mbits/sec 0.024 ms 0/8631 (0%)
[ 5] 115.00-120.00 sec 11.9 MBytes 20.0 Mbits/sec 0.049 ms 0/8632 (0%)
[ 5] 120.00-125.00 sec 11.9 MBytes 20.0 Mbits/sec 0.049 ms 0/8637 (0%)
[ 5] 125.00-130.00 sec 11.9 MBytes 19.9 Mbits/sec 0.067 ms 34/8633 (0.39%)
[ 5] 130.00-135.00 sec 11.9 MBytes 20.0 Mbits/sec 0.023 ms 17/8629 (0.2%)
[ 5] 135.00-140.00 sec 11.9 MBytes 20.0 Mbits/sec 0.013 ms 0/8633 (0%)
[ 5] 140.00-145.00 sec 11.9 MBytes 20.0 Mbits/sec 0.032 ms 0/8636 (0%)
[ 5] 145.00-150.00 sec 11.9 MBytes 20.0 Mbits/sec 0.031 ms 0/8632 (0%)
[ 5] 150.00-155.00 sec 11.9 MBytes 20.0 Mbits/sec 0.023 ms 0/8629 (0%)
[ 5] 155.00-160.00 sec 11.9 MBytes 20.0 Mbits/sec 0.022 ms 0/8633 (0%)
[ 5] 160.00-165.00 sec 11.9 MBytes 20.0 Mbits/sec 0.028 ms 15/8638 (0.17%)
[ 5] 165.00-170.00 sec 11.9 MBytes 19.9 Mbits/sec 0.020 ms 17/8627 (0.2%)
[ 5] 170.00-175.00 sec 11.9 MBytes 20.0 Mbits/sec 0.030 ms 2/8639 (0.023%)
[ 5] 175.00-180.00 sec 11.9 MBytes 20.0 Mbits/sec 0.043 ms 0/8626 (0%)
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-180.00 sec 429 MBytes 20.0 Mbits/sec 0.000 ms 0/310750 (0%) sender
[ 5] 0.00-180.00 sec 429 MBytes 20.0 Mbits/sec 0.043 ms 237/310750 (0.076%) receiver
si même à 20Mbits/sec on perd des paquets ...
Dans l'autre sens c'est plus propre mais ça va contre ce que je constate sur le problème tcp.
je sens que je vais sortir le service echo et un générateur incrémental de trames pour voir si c'est une taille précise qui pose problème .... (parce que le traffic de iperf est au maximum de la trame, alors que dans mon cas c'est plus petit).
-
Ok, en faisant un ping sweep sur ping.online.net:
PING ping.online.net (62.210.18.40) 170(198) bytes of data.
--- ping.online.net ping statistics ---
30 packets transmitted, 30 received, 0% packet loss, time 98ms
rtt min/avg/max/mdev = 2.118/2.702/12.060/1.782 ms, pipe 2, ipg/ewma 3.378/2.316 ms
PING ping.online.net (62.210.18.40) 173(201) bytes of data.
--- ping.online.net ping statistics ---
30 packets transmitted, 0 received, 100% packet loss, time 29031ms
PING ping.online.net (62.210.18.40) 176(204) bytes of data.
--- ping.online.net ping statistics ---
30 packets transmitted, 30 received, 0% packet loss, time 88ms
rtt min/avg/max/mdev = 2.190/2.444/3.185/0.190 ms, ipg/ewma 3.020/2.510 ms
PING ping.online.net (62.210.18.40) 179(207) bytes of data.
--- ping.online.net ping statistics ---
30 packets transmitted, 30 received, 0% packet loss, time 88ms
rtt min/avg/max/mdev = 2.154/2.315/3.020/0.162 ms, ipg/ewma 3.050/2.302 ms
PING ping.online.net (62.210.18.40) 182(210) bytes of data.
--- ping.online.net ping statistics ---
30 packets transmitted, 30 received, 0% packet loss, time 87ms
rtt min/avg/max/mdev = 2.119/2.277/2.649/0.095 ms, ipg/ewma 3.011/2.271 ms
Il semble que quelque chose n'aime pas les paquets de taille 201 octets ...
Je creuse autour de cette valeur:
Depuis chez moi X3:
for i in $(seq 170 300); do if ! sudo ping -q -c 1 -s $i -A ping.online.net > /dev/null; then echo "Killed for $i"; fi; sleep 0.1; done
Killed for 173
Killed for 189
Killed for 269
Killed for 285
Depuis ailleurs:
for i in $(seq 170 300); do if ! sudo ping -q -c 1 -s $i -A ping.online.net > /dev/null; then echo "Killed for $i"; fi; sleep 0.1; done
Je commence à avoir de très gros doutes ...
Cordialement,
-
Bon ben j'ai pas fini de me taper la tête sur les murs :
Si je change le pattern par défaut du ping ... plus de problèmes .... :o
for i in $(seq 170 300); do if ! ping -q -p 40414243444546478495051525354555657585960 -c 1 -s $i -A ping.online.net > /dev/null; then echo "Killed for $i"; fi; sleep 0.1; done
Y aurait-il des équipements «anti bidules» qui prendraient mes pauvres paquets tcp pour de dangereux délinquants ? (oui là c'est de l'ICMP, mais si y a du pattern matching sur l'ICMP ... pourquoi pas sur le tcp ?).
Une idée de comment remonter l'info à l'infra d'orange ?
Merci.
-
Le taux de perte était quand même faible. Je ne pense pas qu'on visualise un problème.
Tu n'a essayé qu'en IPv4, le problème apparait peut-être en IPv6 ?
-
Bonsoir Vivien,
J'ai pas trouvé de serveur iperf3 en ipv6, tu aurais ça en stock ?
Mais de toute manière, vu ce que j'ai découvert sur les pings ... j'ai plus beaucoup de doutes. (d'ailleurs si y a d'autres personnes qui peuvent tester, je suis preneur).
Merci
-
Bonsoir à tous,
Bon je commence à «mieux» cerner le problème. J'ai une airbox dans le cas de la résolution du problème ... J'ai connecté ma tablette wifi et j'ai fait le test sur ping.online.net ... tout va bien (damned). Puis je me suis dit ... si je faisais la même chose vers ma livebox. Hop ni une ni deux, parfeu en personnaliser, ping -s 174 qui passe et ping -s 173 qui ne passe pas ...
Donc le réseau de téléphonie d'orange (4G) n'a pas le problème, c'est bien le réseau fibre qui a un souci ... Me reste plus qu'à faire du sniffing pour voir si c'est le paquet entrant ou sortant qui a le problème ... (je vais tenter un traceroute avec la bonne taille et le bon pattern pour voir).
Cordialement,
-
Ok, traceroute du pauvre:
for i in $(seq 1 10); do ping -n -c 1 -t$i -s 170 ping.online.net; done | grep From
From 192.168.1.1 icmp_seq=1 Time to live exceeded
From 80.10.236.81 icmp_seq=1 Time to live exceeded
From 193.253.80.250 icmp_seq=1 Time to live exceeded
From 193.252.159.42 icmp_seq=1 Time to live exceeded
From 193.252.137.10 icmp_seq=1 Time to live exceeded
From 4.68.127.233 icmp_seq=1 Time to live exceeded
From 212.3.235.202 icmp_seq=1 Time to live exceeded
From 51.158.1.41 icmp_seq=1 Time to live exceeded
From 195.154.1.107 icmp_seq=1 Time to live exceeded
Le même, avec la taille qui va pas:
for i in $(seq 1 10); do ping -n -c 1 -t$i -s 173 ping.online.net; done | grep From
From 192.168.1.1 icmp_seq=1 Time to live exceeded
Donc le coupable c'est 80.10.236.81 ... si vous savez qui c'est ...
Pour enfoncer le clou:
for i in $(seq 1 10); do ping -n -c 1 -t$i -p 00 -s 173 ping.online.net; done | grep From
From 192.168.1.1 icmp_seq=1 Time to live exceeded
From 80.10.236.81 icmp_seq=1 Time to live exceeded
From 193.253.80.250 icmp_seq=1 Time to live exceeded
From 193.252.159.42 icmp_seq=1 Time to live exceeded
From 193.252.137.10 icmp_seq=1 Time to live exceeded
From 4.68.127.233 icmp_seq=1 Time to live exceeded
From 212.3.235.202 icmp_seq=1 Time to live exceeded
From 51.158.1.41 icmp_seq=1 Time to live exceeded
From 195.154.1.107 icmp_seq=1 Time to live exceeded
Bon pour le coup, je vais demander à être rappelé demain ...
-
Et je viens de tomber sur un problème similaire en ipv6 ... bon y a peut être plusieurs problèmes en fait :/
bon je sens que je suis pas sorti de l'auberge ...
-
Ton problème me fait penser à celui-là (en pire) : https://lafibre.info/orange-internet/livebox-6-upload-fibre-limite-a-10mbps/msg949476/#msg949476
Problème de config sur l’OLT ?
-
Salut Zoc,
Peut-être.
J'ai avancé (encore) de mon côté:
* Les paquets sortant de chez moi passent par 80.10.236.81 puis 193.253.80.250, par contre les paquets entrant passent par 193.253.80.249 et ne souffrent pas du même symptôme de drop du ping (c'est ce qu'il y a de cool avec le ttl exceeded, il passe le filtre en retour ce qui permet de dire que le paquet arrive bien sur ma livebox, mais je n'ai pas de retour sur le ping externe depuis mon airbox).
Un technicien doit passer voir mon installe, mais ça a été annulé ce matin car «le service est rétabli». J'ai forcé le RDV sur la demande du support orange, qui a ajouté mes infos sur le dossier a propos du serveur ip qui déconne.
J'en suis arrivé là :
for j in 0 1 2 3 4 5 6 7 8 9 a b c d e f; do for i in $(seq 1 3); do { echo -n "$j $i "; ping -n -c 1 -t$i -p 0000000000000000001$j -s 173 ping.online.net | grep icmp_seq; }; done; echo; done
0 1 From 192.168.1.1 icmp_seq=1 Time to live exceeded
0 2 From 80.10.236.81 icmp_seq=1 Time to live exceeded
0 3 From 193.253.80.250 icmp_seq=1 Time to live exceeded
1 1 From 192.168.1.1 icmp_seq=1 Time to live exceeded
1 2 From 80.10.236.81 icmp_seq=1 Time to live exceeded
1 3 From 193.253.80.250 icmp_seq=1 Time to live exceeded
2 1 From 192.168.1.1 icmp_seq=1 Time to live exceeded
2 2 From 80.10.236.81 icmp_seq=1 Time to live exceeded
2 3 From 193.253.80.250 icmp_seq=1 Time to live exceeded
3 1 From 192.168.1.1 icmp_seq=1 Time to live exceeded
3 2 From 80.10.236.81 icmp_seq=1 Time to live exceeded
3 3 From 193.253.80.250 icmp_seq=1 Time to live exceeded
4 1 From 192.168.1.1 icmp_seq=1 Time to live exceeded
4 2 From 80.10.236.81 icmp_seq=1 Time to live exceeded
4 3 From 193.253.80.250 icmp_seq=1 Time to live exceeded
5 1 From 192.168.1.1 icmp_seq=1 Time to live exceeded
5 2 From 80.10.236.81 icmp_seq=1 Time to live exceeded
5 3 From 193.253.80.250 icmp_seq=1 Time to live exceeded
6 1 6 2 From 80.10.236.81 icmp_seq=1 Time to live exceeded
6 3 From 193.253.80.250 icmp_seq=1 Time to live exceeded
7 1 From 192.168.1.1 icmp_seq=1 Time to live exceeded
7 2 From 80.10.236.81 icmp_seq=1 Time to live exceeded
7 3 From 193.253.80.250 icmp_seq=1 Time to live exceeded
8 1 From 192.168.1.1 icmp_seq=1 Time to live exceeded
8 2 8 3
9 1 From 192.168.1.1 icmp_seq=1 Time to live exceeded
9 2 9 3
a 1 From 192.168.1.1 icmp_seq=1 Time to live exceeded
a 2 a 3
b 1 From 192.168.1.1 icmp_seq=1 Time to live exceeded
b 2 b 3
c 1 From 192.168.1.1 icmp_seq=1 Time to live exceeded
c 2 c 3
d 1 From 192.168.1.1 icmp_seq=1 Time to live exceeded
d 2 d 3
e 1 From 192.168.1.1 icmp_seq=1 Time to live exceeded
e 2 e 3
f 1 From 192.168.1.1 icmp_seq=1 Time to live exceeded
f 2 f 3
et bien sûr -p 00000000000000000020 passe de nouveau ...
Un truc me fait tiquer, c'est le drop sur le 16 par la livebox .... Je vois pas pourquoi ce pattern ne la passerait pas .... Est-ce que ce serait utilisé par orange pour des tests particuliers (ou du «port knocking» ?) ? :-\
Bref peut être que Vanilu76 aura une idée :).
Merci,
Caeies.
-
Bonsoir Vivien,
J'ai pas trouvé de serveur iperf3 en ipv6, tu aurais ça en stock ?
appliwave.iperf.fr permet de tester son débit avec iPerf3 sur tous les ports, du port 1 au port 9199 (sauf le port 5201) en IPv4 et en IPv6
-
Merci Vivien,
ça donne ça:
iperf3 -c appliwave.iperf.fr -6 -O1 -i 5 -Z -t 30 -p 5209 --bidir -u -b 400M --get-server-output
Connecting to host appliwave.iperf.fr, port 5209
[ 5] local ... port 50454 connected to 2a05:46c0:100:1007::5 port 5209
[ 7] local ... port 40440 connected to 2a05:46c0:100:1007::5 port 5209
[ ID][Role] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5][TX-C] 0.00-5.00 sec 238 MBytes 400 Mbits/sec 210065
[ 7][RX-C] 0.00-5.00 sec 238 MBytes 400 Mbits/sec 0.010 ms 0/210061 (0%)
[ 5][TX-C] 5.00-10.00 sec 238 MBytes 400 Mbits/sec 175071
[ 7][RX-C] 5.00-10.00 sec 238 MBytes 400 Mbits/sec 0.019 ms 0/175069 (0%)
[ 5][TX-C] 10.00-15.00 sec 238 MBytes 400 Mbits/sec 175072
[ 7][RX-C] 10.00-15.00 sec 238 MBytes 400 Mbits/sec 0.005 ms 0/175077 (0%)
[ 5][TX-C] 15.00-20.00 sec 238 MBytes 400 Mbits/sec 175065
[ 7][RX-C] 15.00-20.00 sec 238 MBytes 400 Mbits/sec 0.008 ms 0/175062 (0%)
[ 5][TX-C] 20.00-25.00 sec 238 MBytes 400 Mbits/sec 175076
[ 7][RX-C] 20.00-25.00 sec 238 MBytes 400 Mbits/sec 0.006 ms 0/175070 (0%)
[ 5][TX-C] 25.00-30.00 sec 238 MBytes 400 Mbits/sec 175067
[ 7][RX-C] 25.00-30.00 sec 238 MBytes 399 Mbits/sec 0.005 ms 223/175070 (0.13%)
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID][Role] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5][TX-C] 0.00-30.00 sec 1.40 GBytes 400 Mbits/sec 0.000 ms 0/1050425 (0%) sender
[ 5][TX-C] 0.00-30.00 sec 1.40 GBytes 400 Mbits/sec 0.024 ms 149/1050425 (0.014%) receiver
Server output:
Accepted connection from ...., port 46562
[ 5] local 2a05:46c0:100:1007::1af1:b2e port 9235 connected to ... port 50454
[ 6] local 2a05:46c0:100:1007::1af1:b2e port 9235 connected to ... port 40440
[ ID][Role] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5][RX-S] 0.00-1.00 sec 47.4 MBytes 398 Mbits/sec 0.027 ms 96/34911 (0.27%) (omitted)
[ 6][TX-S] 0.00-1.00 sec 47.7 MBytes 400 Mbits/sec 34999 (omitted)
[ 5][RX-S] 0.00-1.00 sec 47.7 MBytes 400 Mbits/sec 0.023 ms 0/35009 (0%)
[ 6][TX-S] 0.00-1.00 sec 47.7 MBytes 400 Mbits/sec 35004
[ 5][RX-S] 1.00-2.00 sec 47.7 MBytes 400 Mbits/sec 0.044 ms 0/35012 (0%)
[ 6][TX-S] 1.00-2.00 sec 47.7 MBytes 400 Mbits/sec 35016
[ 5][RX-S] 2.00-3.00 sec 47.7 MBytes 400 Mbits/sec 0.032 ms 0/35019 (0%)
[ 6][TX-S] 2.00-3.00 sec 47.7 MBytes 400 Mbits/sec 35011
[ 5][RX-S] 3.00-4.00 sec 47.7 MBytes 400 Mbits/sec 0.031 ms 0/35013 (0%)
[ 6][TX-S] 3.00-4.00 sec 47.7 MBytes 400 Mbits/sec 35018
[ 5][RX-S] 4.00-5.00 sec 47.7 MBytes 400 Mbits/sec 0.037 ms 0/35014 (0%)
[ 6][TX-S] 4.00-5.00 sec 47.7 MBytes 400 Mbits/sec 35020
[ 5][RX-S] 5.00-6.00 sec 47.7 MBytes 400 Mbits/sec 0.029 ms 0/35014 (0%)
[ 6][TX-S] 5.00-6.00 sec 47.7 MBytes 400 Mbits/sec 35017
[ 5][RX-S] 6.00-7.00 sec 47.7 MBytes 400 Mbits/sec 0.030 ms 0/35014 (0%)
[ 6][TX-S] 6.00-7.00 sec 47.7 MBytes 400 Mbits/sec 34999
[ 5][RX-S] 7.00-8.00 sec 47.7 MBytes 400 Mbits/sec 0.044 ms 0/35013 (0%)
[ 6][TX-S] 7.00-8.00 sec 47.7 MBytes 400 Mbits/sec 35019
[ 5][RX-S] 8.00-9.00 sec 47.7 MBytes 400 Mbits/sec 0.029 ms 0/35015 (0%)
[ 6][TX-S] 8.00-9.00 sec 47.7 MBytes 400 Mbits/sec 35009
[ 5][RX-S] 9.00-10.00 sec 47.7 MBytes 400 Mbits/sec 0.027 ms 0/35011 (0%)
[ 6][TX-S] 9.00-10.00 sec 47.7 MBytes 400 Mbits/sec 35017
[ 5][RX-S] 10.00-11.00 sec 47.7 MBytes 400 Mbits/sec 0.050 ms 0/35010 (0%)
[ 6][TX-S] 10.00-11.00 sec 47.7 MBytes 400 Mbits/sec 35016
[ 5][RX-S] 11.00-12.00 sec 47.7 MBytes 400 Mbits/sec 0.038 ms 0/35016 (0%)
[ 6][TX-S] 11.00-12.00 sec 47.7 MBytes 400 Mbits/sec 35009
[ 5][RX-S] 12.00-13.00 sec 47.7 MBytes 400 Mbits/sec 0.035 ms 0/35021 (0%)
[ 6][TX-S] 12.00-13.00 sec 47.7 MBytes 400 Mbits/sec 35020
[ 5][RX-S] 13.00-14.00 sec 47.7 MBytes 400 Mbits/sec 0.027 ms 0/35015 (0%)
[ 6][TX-S] 13.00-14.00 sec 47.7 MBytes 400 Mbits/sec 35029
[ 5][RX-S] 14.00-15.00 sec 47.7 MBytes 400 Mbits/sec 0.028 ms 0/35010 (0%)
[ 6][TX-S] 14.00-15.00 sec 47.7 MBytes 400 Mbits/sec 35004
[ 5][RX-S] 15.00-16.00 sec 47.7 MBytes 400 Mbits/sec 0.033 ms 0/35007 (0%)
[ 6][TX-S] 15.00-16.00 sec 47.7 MBytes 400 Mbits/sec 35005
[ 5][RX-S] 16.00-17.00 sec 47.7 MBytes 400 Mbits/sec 0.038 ms 0/35020 (0%)
[ 6][TX-S] 16.00-17.00 sec 47.7 MBytes 400 Mbits/sec 35018
[ 5][RX-S] 17.00-18.00 sec 47.7 MBytes 400 Mbits/sec 0.030 ms 0/35015 (0%)
[ 6][TX-S] 17.00-18.00 sec 47.7 MBytes 400 Mbits/sec 35019
[ 5][RX-S] 18.00-19.00 sec 47.7 MBytes 400 Mbits/sec 0.022 ms 0/35013 (0%)
[ 6][TX-S] 18.00-19.00 sec 47.7 MBytes 400 Mbits/sec 35005
[ 5][RX-S] 19.00-20.00 sec 47.7 MBytes 400 Mbits/sec 0.046 ms 0/35015 (0%)
[ 6][TX-S] 19.00-20.00 sec 47.7 MBytes 400 Mbits/sec 35015
[ 5][RX-S] 20.00-21.00 sec 47.7 MBytes 400 Mbits/sec 0.032 ms 0/35016 (0%)
[ 6][TX-S] 20.00-21.00 sec 47.7 MBytes 400 Mbits/sec 35019
[ 5][RX-S] 21.00-22.00 sec 47.7 MBytes 400 Mbits/sec 0.027 ms 0/35012 (0%)
[ 6][TX-S] 21.00-22.00 sec 47.7 MBytes 400 Mbits/sec 35010
[ 5][RX-S] 22.00-23.00 sec 47.7 MBytes 400 Mbits/sec 0.051 ms 0/35008 (0%)
[ 6][TX-S] 22.00-23.00 sec 47.7 MBytes 400 Mbits/sec 35016
[ 5][RX-S] 23.00-24.00 sec 47.7 MBytes 400 Mbits/sec 0.024 ms 0/35021 (0%)
[ 6][TX-S] 23.00-24.00 sec 47.7 MBytes 400 Mbits/sec 35019
[ 5][RX-S] 24.00-25.00 sec 47.7 MBytes 400 Mbits/sec 0.036 ms 0/35013 (0%)
[ 6][TX-S] 24.00-25.00 sec 47.7 MBytes 400 Mbits/sec 35006
[ 5][RX-S] 25.00-26.00 sec 47.7 MBytes 400 Mbits/sec 0.032 ms 0/35016 (0%)
[ 6][TX-S] 25.00-26.00 sec 47.7 MBytes 400 Mbits/sec 35021
[ 5][RX-S] 26.00-27.00 sec 47.6 MBytes 399 Mbits/sec 0.044 ms 53/35012 (0.15%)
[ 6][TX-S] 26.00-27.00 sec 47.7 MBytes 400 Mbits/sec 35008
[ 5][RX-S] 27.00-28.00 sec 47.6 MBytes 399 Mbits/sec 0.052 ms 0/34934 (0%)
[ 6][TX-S] 27.00-28.00 sec 47.7 MBytes 400 Mbits/sec 35019
[ 5][RX-S] 28.00-29.00 sec 47.8 MBytes 401 Mbits/sec 0.038 ms 0/35091 (0%)
[ 6][TX-S] 28.00-29.00 sec 47.7 MBytes 400 Mbits/sec 35009
[ 5][RX-S] 29.00-30.00 sec 47.7 MBytes 400 Mbits/sec 0.056 ms 0/35009 (0%)
[ 6][TX-S] 29.00-30.00 sec 47.7 MBytes 400 Mbits/sec 35013
[ 5][RX-S] 30.00-30.00 sec 135 KBytes 426 Mbits/sec 0.024 ms 0/97 (0%)
[ 6][TX-S] 30.00-30.00 sec 144 KBytes 452 Mbits/sec 103
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID][Role] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5][RX-S] 0.00-30.00 sec 1.40 GBytes 400 Mbits/sec 0.024 ms 53/1050505 (0.005%) receiver
[ 6][TX-S] 0.00-30.00 sec 1.40 GBytes 400 Mbits/sec 0.000 ms 0/1050513 (0%) sender
[ 7][RX-C] 0.00-30.00 sec 1.40 GBytes 400 Mbits/sec 0.000 ms 0/1050513 (0%) sender
[ 7][RX-C] 0.00-30.00 sec 1.40 GBytes 400 Mbits/sec 0.005 ms 223/1050410 (0.021%) receiver
iperf Done.
iperf3 -c appliwave.iperf.fr -4 -O1 -i 5 -Z -t 30 -p 5209 --bidir -u -b 400M --get-server-output
Connecting to host appliwave.iperf.fr, port 5209
[ 5] local ... port 57189 connected to 45.85.134.189 port 5209
[ 7] local ... port 38751 connected to 45.85.134.189 port 5209
[ ID][Role] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5][TX-C] 0.00-5.00 sec 238 MBytes 400 Mbits/sec 207159
[ 7][RX-C] 0.00-5.00 sec 238 MBytes 400 Mbits/sec 0.006 ms 0/207175 (0%)
[ 5][TX-C] 5.00-10.00 sec 238 MBytes 400 Mbits/sec 172649
[ 7][RX-C] 5.00-10.00 sec 238 MBytes 400 Mbits/sec 0.016 ms 49/172655 (0.028%)
[ 5][TX-C] 10.00-15.00 sec 238 MBytes 400 Mbits/sec 172654
[ 7][RX-C] 10.00-15.00 sec 238 MBytes 400 Mbits/sec 0.011 ms 0/172660 (0%)
[ 5][TX-C] 15.00-20.00 sec 238 MBytes 400 Mbits/sec 172650
[ 7][RX-C] 15.00-20.00 sec 238 MBytes 400 Mbits/sec 0.012 ms 0/172628 (0%)
[ 5][TX-C] 20.00-25.00 sec 238 MBytes 400 Mbits/sec 172654
[ 7][RX-C] 20.00-25.00 sec 238 MBytes 400 Mbits/sec 0.005 ms 3/172665 (0.0017%)
[ 5][TX-C] 25.00-30.00 sec 238 MBytes 400 Mbits/sec 172652
[ 7][RX-C] 25.00-30.00 sec 238 MBytes 400 Mbits/sec 0.006 ms 0/172659 (0%)
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID][Role] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5][TX-C] 0.00-30.00 sec 1.40 GBytes 400 Mbits/sec 0.000 ms 0/1035916 (0%) sender
[ 5][TX-C] 0.00-30.00 sec 1.40 GBytes 400 Mbits/sec 0.023 ms 227/1035916 (0.022%) receiver
Server output:
Accepted connection from ..., port 52636
[ 5] local 45.85.134.186 port 9235 connected to ... port 57189
[ 6] local 45.85.134.186 port 9235 connected to ... port 38751
[ ID][Role] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5][RX-S] 0.00-1.00 sec 47.3 MBytes 396 Mbits/sec 0.058 ms 220/34443 (0.64%) (omitted)
[ 6][TX-S] 0.00-1.00 sec 47.6 MBytes 400 Mbits/sec 34505 (omitted)
[ 5][RX-S] 0.00-1.00 sec 47.7 MBytes 400 Mbits/sec 0.058 ms 0/34530 (0%)
[ 6][TX-S] 0.00-1.00 sec 47.7 MBytes 400 Mbits/sec 34532
[ 5][RX-S] 1.00-2.00 sec 47.7 MBytes 400 Mbits/sec 0.059 ms 0/34528 (0%)
[ 6][TX-S] 1.00-2.00 sec 47.7 MBytes 400 Mbits/sec 34540
[ 5][RX-S] 2.00-3.00 sec 47.7 MBytes 400 Mbits/sec 0.054 ms 0/34533 (0%)
[ 6][TX-S] 2.00-3.00 sec 47.7 MBytes 400 Mbits/sec 34519
[ 5][RX-S] 3.00-4.00 sec 47.7 MBytes 400 Mbits/sec 0.042 ms 0/34531 (0%)
[ 6][TX-S] 3.00-4.00 sec 47.7 MBytes 400 Mbits/sec 34540
[ 5][RX-S] 4.00-5.00 sec 47.7 MBytes 400 Mbits/sec 0.056 ms 0/34530 (0%)
[ 6][TX-S] 4.00-5.00 sec 47.7 MBytes 400 Mbits/sec 34520
[ 5][RX-S] 5.00-6.00 sec 47.7 MBytes 400 Mbits/sec 0.056 ms 0/34530 (0%)
[ 6][TX-S] 5.00-6.00 sec 47.7 MBytes 400 Mbits/sec 34532
[ 5][RX-S] 6.00-7.00 sec 47.7 MBytes 400 Mbits/sec 0.049 ms 0/34530 (0%)
[ 6][TX-S] 6.00-7.00 sec 47.7 MBytes 400 Mbits/sec 34538
[ 5][RX-S] 7.00-8.00 sec 47.7 MBytes 400 Mbits/sec 0.045 ms 0/34535 (0%)
[ 6][TX-S] 7.00-8.00 sec 47.7 MBytes 400 Mbits/sec 34522
[ 5][RX-S] 8.00-9.00 sec 47.7 MBytes 400 Mbits/sec 0.060 ms 7/34523 (0.02%)
[ 6][TX-S] 8.00-9.00 sec 47.7 MBytes 400 Mbits/sec 34531
[ 5][RX-S] 9.00-10.00 sec 47.6 MBytes 399 Mbits/sec 0.053 ms 0/34469 (0%)
[ 6][TX-S] 9.00-10.00 sec 47.7 MBytes 400 Mbits/sec 34537
[ 5][RX-S] 10.00-11.00 sec 47.8 MBytes 401 Mbits/sec 0.075 ms 0/34591 (0%)
[ 6][TX-S] 10.00-11.00 sec 47.7 MBytes 400 Mbits/sec 34530
[ 5][RX-S] 11.00-12.00 sec 47.7 MBytes 400 Mbits/sec 0.067 ms 0/34532 (0%)
[ 6][TX-S] 11.00-12.00 sec 47.7 MBytes 400 Mbits/sec 34529
[ 5][RX-S] 12.00-13.00 sec 47.7 MBytes 400 Mbits/sec 0.062 ms 0/34532 (0%)
[ 6][TX-S] 12.00-13.00 sec 47.7 MBytes 400 Mbits/sec 34532
[ 5][RX-S] 13.00-14.00 sec 47.7 MBytes 400 Mbits/sec 0.050 ms 0/34534 (0%)
[ 6][TX-S] 13.00-14.00 sec 47.7 MBytes 400 Mbits/sec 34523
[ 5][RX-S] 14.00-15.00 sec 47.7 MBytes 400 Mbits/sec 0.063 ms 0/34526 (0%)
[ 6][TX-S] 14.00-15.00 sec 47.7 MBytes 400 Mbits/sec 34539
[ 5][RX-S] 15.00-16.00 sec 47.7 MBytes 400 Mbits/sec 0.046 ms 0/34534 (0%)
[ 6][TX-S] 15.00-16.00 sec 47.7 MBytes 400 Mbits/sec 34532
[ 5][RX-S] 16.00-17.00 sec 47.7 MBytes 400 Mbits/sec 0.054 ms 0/34530 (0%)
[ 6][TX-S] 16.00-17.00 sec 47.7 MBytes 400 Mbits/sec 34528
[ 5][RX-S] 17.00-18.00 sec 47.7 MBytes 400 Mbits/sec 0.027 ms 0/34527 (0%)
[ 6][TX-S] 17.00-18.00 sec 47.7 MBytes 400 Mbits/sec 34527
[ 5][RX-S] 18.00-19.00 sec 47.7 MBytes 400 Mbits/sec 0.052 ms 0/34534 (0%)
[ 6][TX-S] 18.00-19.00 sec 47.7 MBytes 400 Mbits/sec 34527
[ 5][RX-S] 19.00-20.00 sec 47.7 MBytes 400 Mbits/sec 0.018 ms 0/34520 (0%)
[ 6][TX-S] 19.00-20.00 sec 47.7 MBytes 400 Mbits/sec 34532
[ 5][RX-S] 20.00-21.00 sec 47.7 MBytes 400 Mbits/sec 0.059 ms 0/34537 (0%)
[ 6][TX-S] 20.00-21.00 sec 47.7 MBytes 400 Mbits/sec 34529
[ 5][RX-S] 21.00-22.00 sec 47.7 MBytes 400 Mbits/sec 0.059 ms 0/34530 (0%)
[ 6][TX-S] 21.00-22.00 sec 47.7 MBytes 400 Mbits/sec 34531
[ 5][RX-S] 22.00-23.00 sec 47.7 MBytes 400 Mbits/sec 0.059 ms 0/34531 (0%)
[ 6][TX-S] 22.00-23.00 sec 47.7 MBytes 400 Mbits/sec 34533
[ 5][RX-S] 23.00-24.00 sec 47.7 MBytes 400 Mbits/sec 0.047 ms 0/34534 (0%)
[ 6][TX-S] 23.00-24.00 sec 47.7 MBytes 400 Mbits/sec 34533
[ 5][RX-S] 24.00-25.00 sec 47.7 MBytes 400 Mbits/sec 0.024 ms 0/34521 (0%)
[ 6][TX-S] 24.00-25.00 sec 47.7 MBytes 400 Mbits/sec 34524
[ 5][RX-S] 25.00-26.00 sec 47.7 MBytes 400 Mbits/sec 0.029 ms 0/34534 (0%)
[ 6][TX-S] 25.00-26.00 sec 47.7 MBytes 400 Mbits/sec 34536
[ 5][RX-S] 26.00-27.00 sec 47.7 MBytes 400 Mbits/sec 0.053 ms 0/34535 (0%)
[ 6][TX-S] 26.00-27.00 sec 47.7 MBytes 400 Mbits/sec 34533
[ 5][RX-S] 27.00-28.00 sec 47.7 MBytes 400 Mbits/sec 0.063 ms 0/34527 (0%)
[ 6][TX-S] 27.00-28.00 sec 47.7 MBytes 400 Mbits/sec 34527
[ 5][RX-S] 28.00-29.00 sec 47.7 MBytes 400 Mbits/sec 0.059 ms 0/34531 (0%)
[ 6][TX-S] 28.00-29.00 sec 47.7 MBytes 400 Mbits/sec 34535
[ 5][RX-S] 29.00-30.00 sec 47.7 MBytes 400 Mbits/sec 0.049 ms 0/34535 (0%)
[ 6][TX-S] 29.00-30.00 sec 47.7 MBytes 400 Mbits/sec 34526
[ 5][RX-S] 30.00-30.00 sec 86.3 KBytes 382 Mbits/sec 0.023 ms 0/61 (0%)
[ 6][TX-S] 30.00-30.00 sec 90.5 KBytes 401 Mbits/sec 64
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID][Role] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5][RX-S] 0.00-30.00 sec 1.40 GBytes 400 Mbits/sec 0.023 ms 7/1035975 (0.00068%) receiver
[ 6][TX-S] 0.00-30.00 sec 1.40 GBytes 400 Mbits/sec 0.000 ms 0/1035981 (0%) sender
[ 7][RX-C] 0.00-30.00 sec 1.40 GBytes 400 Mbits/sec 0.000 ms 0/1035972 (0%) sender
[ 7][RX-C] 0.00-30.00 sec 1.40 GBytes 400 Mbits/sec 0.006 ms 52/1035928 (0.005%) receiver
iperf Done.
Le problème n'est clairement pas un souci de «saleté» sur la fibre ... c'est vraiment un problème lié à certain motifs de paquets ...
Cordialement,
-
Hello !
Tous ces tests, ça dépasse un peu ma compréhension et mes connaissances.
Je peux tout de même essayer de casser/recréer ta config dans l'OLT, ça ne coute rien.
Peux-tu m'envoyer ton numéro de support fibre via MP ?
-
Vanilu, je ne sais pas si tu as déjà cassé / recréé dans l'olt, mais si c'est pas le cas, ne le fait pas.
il y a définitivement quelque chose de moche là dessous. Donc soit on reinitialise, le pb disparait et on considère ça réglé, pour l'instant, ou alors on essaye d'investiguer un peu plus.
=> auquel cas je veux bien le numéro de support fibre également en mp.
-
Bonjour à tous les deux,
J'ai enfin eu une personne compétente au support d'orange hier en fin d'après midi. Ils vont envoyer un expert réseau chez moi pour «voir par eux mêmes» et tenter de remonter à la source. Le rendez-vous est pour Mercredi matin, j'espère qu'il va réussir à identifier le souci et pouvoir le résoudre rapidement.
Pour Petrus, je ne pense pas que Vanilu l'ai fait, et même s'il l'a fait, je ne pense pas que cela est résolu le problème. D'après le technicien qui est venu vérifier la qualité de ma fibre, le reset de l'OLT a déjà été fait, et c'est pour ça que le rendez-vous avec lui avait été initialement annulé.
Mon expérience me fait pencher pour une carte réseau défectueuse sur l'une des machines, mais vu que c'est très systématique, j'hésites avec une configuration de la dite machine un peu «agressive».
Je vais essayer de vivre avec pour encore 3j :/.
Merci encore pour votre aide.
-
Bon, en creusant un peu, je ne crois plus a un probleme de configuration.
Un ping avec les motifs 0f ou 1f ou 2f ou 3f de taille 13+Nx16 (N >= 1) est systematiquement perdu. Le fait qu'il soit perdu me fait penser a une somme de controle erronée et donc le controleur reseau rejette systematiquement celui-ci.
Reste à trouver quel élément physique provoque le probleme, mais ce n'est plus de mon ressort ...
(Je peux pas faire de copie/paste, je corrigerais le message ce soir).
Pour le ping linux ce sont les options -p 0f et -s $((13+$i*16))
$ bash pattern.sh
drop 29 drop 45
drop 61 drop 77 drop 93 drop 109 drop 125
drop 141 drop 157 drop 173
drop 189
drop 205 drop 221
drop 237 drop 253
drop 269
drop 285 drop 301
drop 317
drop 333 drop 349 drop 365 drop 381 drop 397
drop 413 drop 429 drop 445
drop 461 drop 477
drop 493 drop 509
drop 525 drop 541 drop 557
drop 573 drop 589
drop 605
drop 621
drop 637 drop 653
drop 669 drop 685
drop 701
drop 717 drop 733
drop 749 drop 765
drop 781 drop 797 drop 813 drop 829 drop 845
drop 861 drop 877 drop 893
drop 909
drop 925 drop 941
drop 957 drop 973
drop 989
drop 1005 drop 1021
drop 1037
drop 1053 drop 1069 drop 1085 drop 1101
drop 1101 drop 1117
drop 1133 drop 1149 drop 1165
drop 1181 drop 1197
drop 1213 drop 1229
drop 1245 drop 1261 drop 1277
drop 1293 drop 1309
drop 1325
drop 1341 drop 1357 drop 1373
drop 1389 drop 1405
drop 1421 drop 1437 drop 1453
drop 1469 drop 1485for j in $(seq 13 16 1500) ; do if ! ping -n -c 1 -q -w1 -p 3f -s $j xx.yy.ww.zz >/dev/null; then echo drop $j; fi ; done
Merci a tous pour votre aide.
Caeies
-
Bon fausse joie,
Le support Orange m'envoie quelqu'un qui doit me faire du conseil (et me facturer) et qui va constater que la connection ne marche pas. Autrement dit je suis reparti pour un tour :(.
Il ne faut pas que le problème soit résolu avant que le gars constate le souci, sinon ça va être une grosse facture :(.
:'(
Caeies.
-
Bon fausse joie,
Le support Orange m'envoie quelqu'un qui doit me faire du conseil (et me facturer) et qui va constater que la connection ne marche pas. Autrement dit je suis reparti pour un tour :(.
Il ne faut pas que le problème soit résolu avant que le gars constate le souci, sinon ça va être une grosse facture :(.
:'(
Caeies.
Il va voir que tout est en vert, faire un Speedtest et voir que tout fonctionne selon ses critères, non?
-
Bah, moi je vais lui montrer que le ping ne passe pas donc ça marche pas.
Mais oui je crains fort que ça ne finisse au contentieux cette histoire :(.
Caeies,
-
Quand j'ai emménagé ici, le tech m'a demandé de faire un speedtest, je suis donc allé sur https://testdebit.info/ comme toujours, et ça ne lui allait pas, il ne connaissait pas le site, j'ai dû refaire sur le classique Speedtest.net.
Donc prépare toi à ce qu'il te dise que c'est ton protocole de test qui va pas :D
-
Bon,
Bilan des courses, le gars qui devait prendre contact a été optimisé sur un autre planning et son remplaçant pas à la hauteur, n'a pas voulu ouvrir le ticket, il a juste demandé à relancer la chose (mais sur un ticket qui n'existe pas ?).
D'après lui le 3900 doit me rappeler, mais j'ai du mal à y croire. J'essaierai d'appeler demain, on verra.
Je sens qu'il va falloir que je garde mon calme.
Merci a Petrus pour sa tentative, peut être qu'avec un peu de chance elle aboutira :/.
Pour info et pour être complet :
Il faut: -s 13+$(($N*16)) avec N > 0, et -p $k$j avec k ∈ [0,3]∪[8,b] et j ∈ [8,f].
Vérifiable simplement avec le ping unix (quelque soit l'orde des valeurs testés):
for k in 0 1 2 3 4 5 6 7 8 9 a b c d e f; do for j in 0 1 2 3 4 5 6 7 8 9 a b c d e f; do { if ! ping -q -4 -w 1 -n -c 1 -p $k$j -s 29 appliwave.iperf.fr > /dev/null; then echo "$k$j dropped"; fi }; done; done;
Qui donne chez moi :
08 dropped
09 dropped
0a dropped
0b dropped
0c dropped
0d dropped
0e dropped
0f dropped
18 dropped
19 dropped
1a dropped
1b dropped
1c dropped
1d dropped
1e dropped
1f dropped
28 dropped
29 dropped
2a dropped
2b dropped
2c dropped
2d dropped
2e dropped
2f dropped
38 dropped
39 dropped
3a dropped
3b dropped
3c dropped
3d dropped
3e dropped
3f dropped
88 dropped
89 dropped
8a dropped
8b dropped
8c dropped
8d dropped
8e dropped
8f dropped
98 dropped
99 dropped
9a dropped
9b dropped
9c dropped
9d dropped
9e dropped
9f dropped
a8 dropped
a9 dropped
aa dropped
ab dropped
ac dropped
ad dropped
ae dropped
af dropped
b8 dropped
b9 dropped
ba dropped
bb dropped
bc dropped
bd dropped
be dropped
bf dropped
Au besoin, je peux filer un bout de code c# pour windows pour faire la même chose (je suis pas expert c#, donc le code est un copié collé du site de microsoft sur le sujet, modifé pour faire le taff): (ne marche pas avec mono sous linux car il ne passe pas les bons params au ping).
cat ping.cs
using System;
using System.Net;
using System.Net.NetworkInformation;
using System.Text;
namespace Examples.System.Net.NetworkInformation.PingTest
{
public class PingExample
{
// args[0] can be an IPaddress or host name.
public static void Main (string[] args)
{
Ping pingSender = new Ping ();
PingOptions options = new PingOptions ();
// Use the default Ttl value which is 128,
// but change the fragmentation behavior.
options.DontFragment = true;
char pattern = '\x0f'; // you can choose any value $k$j with k ∈ [0,3]∪[8,b] et j ∈ [8,f]
for (int i = 13; i < 13+5*16; i++)
{
string data = new string(pattern, i);
byte[] buffer = Encoding.ASCII.GetBytes (data);
int timeout = 120;
PingReply reply = pingSender.Send (args[0], timeout, buffer, options);
if (reply.Status == IPStatus.Success)
{
//Console.WriteLine ("Address: {0}", reply.Address.ToString ());
//Console.WriteLine ("RoundTrip time: {0}", reply.RoundtripTime);
//Console.WriteLine ("Time to live: {0}", reply.Options.Ttl);
//Console.WriteLine ("Don't fragment: {0}", reply.Options.DontFragment);
//Console.WriteLine ("Buffer size: {0}", reply.Buffer.Length);
}
else
{
Console.WriteLine ("Dropped with Buffer size: {0}", buffer.Length);
}
}
}
}
}
Qui a dit que windows était network ready ? :o
Caeies,
-
for j in 0 1 2 3 4 5 6 7 8 9 a b c d e f; do for i in $(seq 1 3); do { echo -n "$j $i "; ping -n -c 1 -t$i -p 0000000000000000001$j -s 173 ping.online.net | grep icmp_seq; }; done; echo; done
Il manque un sleep, sinon ça envoie des pings trop rapprochés et la Livebox ne répond pas toujours.
J'ai vérifié via une capture wireshark entre l'ONT et la livebox 4 que les paquets TCP qui sont rejoués sont tous bien bloqués, et ce jusqu'au reset de la connection par la partie «Home»
Qu'est-ce que tu entends par bloqués ?
Que les paquets sortent bien de la Livebox, et comme le serveur les redemande tu en déduis que le réseau les a perdus ?
En IPv4, la Livebox doit recalculer les checksums :
- IP : NAT (changement de l'IP source) et TTL
- TCP/UDP : NAT (changement de l'IP source et éventuellement du port source)
-
Salut Hwti,
Il manque un sleep, sinon ça envoie des pings trop rapprochés et la Livebox ne répond pas toujours.
Ouais, j'ai testé avec un sleep c'est pareil ... et non réponse sur 3 ping de suite .... ça saute de temps en temps, normal, mais si tu prends chaque ping généré ça explose à la main aussi. J'avoue que plein de monde me dit que si on ping trop, la livebox drop, ben pour l'instant j'ai pas constaté ça dans les faits.
pour preuve:
for j in 0 1 2 3 4 5 6 7 8 9 a b c d e f; do for i in $(seq 3 3); do { echo -n "$j $i "; ping -n -w1 -c 1 -t$i -p 0000000000000000001$j -s 173 ping.online.net | grep icmp_seq; }; done; echo; sleep 0.1; done
0 3 From 193.253.80.250 icmp_seq=1 Time to live exceeded
1 3 From 193.253.80.250 icmp_seq=1 Time to live exceeded
2 3 From 193.253.80.250 icmp_seq=1 Time to live exceeded
3 3 From 193.253.80.250 icmp_seq=1 Time to live exceeded
4 3 From 193.253.80.250 icmp_seq=1 Time to live exceeded
5 3 From 193.253.80.250 icmp_seq=1 Time to live exceeded
6 3 From 193.253.80.250 icmp_seq=1 Time to live exceeded
7 3 From 193.253.80.250 icmp_seq=1 Time to live exceeded
8 3
9 3
a 3
b 3
c 3
d 3
e 3
f 3
Que les paquets sortent bien de la Livebox, et comme le serveur les redemande tu en déduis que le réseau les a perdus ?
Non le serveur ne redemande pas, il ne les acks pas, et continue d'envoyer d'autres paquets tcp sans faire les ack du paquet retransmis. Donc oui j'en déduis qu'en plus du ping, il drop des paquets tcp sur la ligne (car le routage n'est pas le même en sortie et en retour).
Il me semble que j'ai mis les traces de l'extérieur de mon réseau (via l'airbox) sur le thread, je trouve ça très parlant.
On est d'accord, la livebox fait le nat et pourrait se tromper dans le calcul des CHCK ... on parle de linux tout de même qui marche très bien pour le reste du monde. ou alors le chksum est calculé dans la carte réseau elle-même et borké ici: 2 livebox seraient HS chez moi et fonctionnelles chez d'autres ... j'ai du mal à y croire aussi (surtout que j'ai eu deux versions différentes de livebox 4, et deux versions différentes d'ONT).
De mémoire, lorsque j'ai fait la capture wireshark entre la livebox et l'ONT je n'ai pas vu d'erreur de checksum sur les paquets qui sortaient. (surtout que dans wireshark c'est en gros et en noir, ça se rate difficilement). MAIS comme ce sont des retransmits, je peux pas exclure de ne pas y avoir prêté attention. Je revérifierais.
Je viens de vérfier pourquoi mon 16 échoue à chaque fois sur la livebox, et il y a bien un rate limiting sur certains messages ICMP émis par la livebox (comme te ttl exceeded). Mais clairement pas dans les transmissions:
sudo ping -n -f -s 29 -c 100 -p 00 ping.online.net
PATTERN: 0x00
PING ping.online.net (62.210.18.40) 29(57) bytes of data.
--- ping.online.net ping statistics ---
100 packets transmitted, 100 received, 0% packet loss, time 299ms
rtt min/avg/max/mdev = 2.799/2.939/4.737/0.187 ms, ipg/ewma 3.019/2.980 ms
sudo ping -n -w1 -f -s 29 -c 10 -p 0f ping.online.net
PATTERN: 0x0f
PING ping.online.net (62.210.18.40) 29(57) bytes of data.
..............................................................
--- ping.online.net ping statistics ---
62 packets transmitted, 0 received, 100% packet loss, time 992ms
Caeies,
PS: rien que pour se post, il a fallu que je tente 3 fois avant qu'il passe :(.
-
pour clore ce débat sur la livebox (de mon point de vue):
for j in 8 9 a b c d e f 0 1 2 3 4 5 6 7 ; do for i in $(seq 1 3); do { echo -n "$j $i "; ping -n -w1 -c 1 -t$i -p 0000000000000000001$j -s 173 ping.online.net | grep icmp_seq; }; sleep 1; done; echo; sleep 1; done
8 1 From 192.168.1.1 icmp_seq=1 Time to live exceeded
8 2 8 3
9 1 From 192.168.1.1 icmp_seq=1 Time to live exceeded
9 2 9 3
a 1 From 192.168.1.1 icmp_seq=1 Time to live exceeded
a 2 a 3
b 1 From 192.168.1.1 icmp_seq=1 Time to live exceeded
b 2 b 3
c 1 From 192.168.1.1 icmp_seq=1 Time to live exceeded
c 2 c 3
d 1 From 192.168.1.1 icmp_seq=1 Time to live exceeded
d 2 d 3
e 1 From 192.168.1.1 icmp_seq=1 Time to live exceeded
e 2 e 3
f 1 From 192.168.1.1 icmp_seq=1 Time to live exceeded
f 2 f 3
0 1 From 192.168.1.1 icmp_seq=1 Time to live exceeded
0 2 From 80.10.236.81 icmp_seq=1 Time to live exceeded
0 3 From 193.253.80.250 icmp_seq=1 Time to live exceeded
1 1 From 192.168.1.1 icmp_seq=1 Time to live exceeded
1 2 From 80.10.236.81 icmp_seq=1 Time to live exceeded
1 3 From 193.253.80.250 icmp_seq=1 Time to live exceeded
2 1 From 192.168.1.1 icmp_seq=1 Time to live exceeded
2 2 From 80.10.236.81 icmp_seq=1 Time to live exceeded
2 3 From 193.253.80.250 icmp_seq=1 Time to live exceeded
3 1 From 192.168.1.1 icmp_seq=1 Time to live exceeded
3 2 From 80.10.236.81 icmp_seq=1 Time to live exceeded
3 3 From 193.253.80.250 icmp_seq=1 Time to live exceeded
4 1 From 192.168.1.1 icmp_seq=1 Time to live exceeded
4 2 From 80.10.236.81 icmp_seq=1 Time to live exceeded
4 3 From 193.253.80.250 icmp_seq=1 Time to live exceeded
5 1 From 192.168.1.1 icmp_seq=1 Time to live exceeded
5 2 From 80.10.236.81 icmp_seq=1 Time to live exceeded
5 3 From 193.253.80.250 icmp_seq=1 Time to live exceeded
6 1 From 192.168.1.1 icmp_seq=1 Time to live exceeded
6 2 From 80.10.236.81 icmp_seq=1 Time to live exceeded
6 3 From 193.253.80.250 icmp_seq=1 Time to live exceeded
7 1 From 192.168.1.1 icmp_seq=1 Time to live exceeded
7 2 From 80.10.236.81 icmp_seq=1 Time to live exceeded
7 3 From 193.253.80.250 icmp_seq=1 Time to live exceeded
-
J'avoue que plein de monde me dit que si on ping trop, la livebox drop, ben pour l'instant j'ai pas constaté ça dans les faits.
Sans sleep sur le test j'ai quelques fois où la Livebox ne répond pas, mais les routeurs derrières si (donc c'est juste une limite de fréquence d'émission de TTL exceeded par la Livebox).
Il me semble que j'ai mis les traces de l'extérieur de mon réseau (via l'airbox) sur le thread, je trouve ça très parlant.
Je n'ai pas vu de capture, juste les tests avec ping et iperf.
On est d'accord, la livebox fait le nat et pourrait se tromper dans le calcul des CHCK ... on parle de linux tout de même qui marche très bien pour le reste du monde. ou alors le chksum est calculé dans la carte réseau elle-même et borké ici: 2 livebox serait HS chez moi et fonctionnelles chez d'autres ... j'ai du mal à y croire aussi (surtout que j'ai eu deux versions différentes de livebox 4, et deux versions différentes d'ONT)
Sur les box, il y a deux chemins possibles :
- via Linux de manière classique pour les premiers paquets (avec probablement les offloads du contrôleur pour les checksums)
- via le NAT HW, une fois le flux établi (les checksums sont donc gérés par l'accélérateur)
Il pourrait y avoir des bugs, peut-être uniquement sur certaines versions de firmware.
Mais je ne vois pas pourquoi ça t'affecterait spécifiquement.
J'ai eu des problèmes de pertes de paquets en download, mais je n'ai pas eu le temps de les caractériser (je n'ai pas pensé à un lien possible avec la taille), maintenant c'est corrigé.
De mémoire, lorsque j'ai fait la capture wireshark entre la livebox et l'ONT je n'ai pas vu d'erreur de checksum sur les paquets qui sortaient. (surtout que dans wireshark c'est en gros et en noir, ça se rate difficilement). MAIS comme ce sont des retransmits, je peux pas exclure de ne pas y avoir prêté attention. Je revérifierais.
Je ne suis pas sûr que Wirehark vérifie les checksums dans tous les cas.
Il y a au moins le cas de la capture locale, où il est ignoré pour les paquets émis.
De même si les paquets sont combinés ou découpés par la carte ou le driver (TSO, GRO, ...), Wireshark ne voit pas les paquets réels.
-
Sans sleep sur le test j'ai quelques fois où la Livebox ne répond pas, mais les routeurs derrières si (donc c'est juste une limite de fréquence d'émission de TTL exceeded par la Livebox).
Oui, on est en phase.
Je n'ai pas vu de capture, juste les tests avec ping et iperf.
Oui, je m'aperçois que j'en ai parlé mais j'ai rien publié de vraiment concret. Pour la capture wireshark, j'arrive pas à l’anonymiser proprement pour ne pas tout casser, tout en étant assez anonyme. Si vous avez un bon outil sur le sujet, je prends.
Pour le ping externe, j'ai pas retrouvé alors que je suis sûr de l'avoir fait quelque part... Je vais reposter ça après le boulot.
Il pourrait y avoir des bugs, peut-être uniquement sur certaines versions de firmware.
Mais je ne vois pas pourquoi ça t'affecterait spécifiquement.
Oui je suis d'accord. Et ça rend la connexion à la limite de l'inutilisable. Donc j'ose espérer que le problème n'est pas lié à une config particulière de la livebox qui s'est contaminée via la sauvegarde en ligne de sa configuration entre les 2 ...
Pour écarter cette hypothèse, il va falloir que je trouve le temps de bricoler un pc pour me substituer à la livebox et faire le test pour en avoir le cœur net. Bon, ça vaut le coup de tenter, je verras cette partie ce WE si j'ai pas de news du support d'ici là (ça avait été suggéré avant dans le thread, mais là je vais devoir me résoudre à le faire).
Je vais refaire une capture des trois cas ce WE (ping interne / ping externe / connexion tcp qui retry).
Caeies,
-
Tous,
Suite des tribulations: Un ticket Oceane à bien été ouvert chez Orange ... maintenant il faut être .... «patient».
Pour hwti:
Via mon Airbox, voila ce que ça donne:
for i in $(seq 1 18); do { echo -n "$i "; ping -n -c 1 -t$i -p 0f -s 29 -w1 90.127.xx.yy| grep icmp_seq; }; sleep 1; done
1 From 192.168.1.1: icmp_seq=1 Time to live exceeded
2 From 10.68.211.64: icmp_seq=1 Time to live exceeded
3 From 10.68.210.49: icmp_seq=1 Time to live exceeded
4 From 10.68.210.54: icmp_seq=1 Time to live exceeded
5 From 10.68.210.62: icmp_seq=1 Time to live exceeded
6 From 10.68.210.65: icmp_seq=1 Time to live exceeded
7 From 193.252.137.34: icmp_seq=1 Time to live exceeded
8 From 193.251.110.209: icmp_seq=1 Time to live exceeded
9 From 193.252.98.145: icmp_seq=1 Time to live exceeded
10 From 193.251.126.102: icmp_seq=1 Time to live exceeded
11 From 193.252.98.93: icmp_seq=1 Time to live exceeded
12 From 193.253.80.249: icmp_seq=1 Time to live exceeded
13 From 90.127.xx.yy: icmp_seq=1 Time to live exceeded #<= c'est la preuve que le paquet arrive à la livebox car il passe par 80.249)
14 15 16 17 18
$ for i in $(seq 1 18); do { echo -n "$i "; ping -n -c 1 -t$i -p 00 -s 29 -w1 90.127.xx.yy | grep icmp_seq; }; sleep 1; done
1 From 192.168.1.1: icmp_seq=1 Time to live exceeded
2 From 10.68.211.64: icmp_seq=1 Time to live exceeded
3 From 10.68.210.49: icmp_seq=1 Time to live exceeded
4 From 10.68.210.54: icmp_seq=1 Time to live exceeded
5 From 10.68.210.62: icmp_seq=1 Time to live exceeded
6 From 10.68.210.65: icmp_seq=1 Time to live exceeded
7 From 193.252.137.34: icmp_seq=1 Time to live exceeded
8 From 193.251.110.209: icmp_seq=1 Time to live exceeded
9 From 193.252.98.145: icmp_seq=1 Time to live exceeded
10 From 193.251.126.102: icmp_seq=1 Time to live exceeded
11 From 193.252.98.93: icmp_seq=1 Time to live exceeded
12 From 193.253.80.249: icmp_seq=1 Time to live exceeded
13 From 90.127.xx.yy icmp_seq=1 Time to live exceeded
14 37 bytes from 90.127.xx.yy icmp_seq=1 ttl=50 time=53.3 ms # le paquet revient par 80.10.236.81 puis 193.253.80.250
15 37 bytes from 90.127.xx.yyicmp_seq=1 ttl=50 time=47.9 ms
16 37 bytes from 90.127.xx.yy icmp_seq=1 ttl=50 time=47.1 ms
17 37 bytes from 90.127.xx.yy icmp_seq=1 ttl=50 time=53.7 ms
18 37 bytes from 90.127.xx.yy: icmp_seq=1 ttl=50 time=49.8 ms
Je regarde pour la suite ce WE.
Cordialement,
-
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 :
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
-
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,
-
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):
=>
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
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é.
-
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.
-
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,
-
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.
-
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.
-
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é.
-
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 :) ).
-
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.
-
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 (https://lafibre.info/orange-business-services/livebox-pro-v3-problemes-suite-mises-a-jours/) 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.
-
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,
-
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.
Tu as changé de type d'ONT ?
Sauf configuration spécifique de la ligne, il n'y a qu'un seul numéro de série qui est autorisé, donc tu ne peux pas remettre un autre ONT Orange.
-
Sauf configuration spécifique de la ligne, il n'y a qu'un seul numéro de série qui est autorisé, donc tu ne peux pas remettre un autre ONT Orange.
Oui je suis au courant vu les problèmes que j'ai eu [HINT: c'était la première étape du niveau 2 lors du ticket précédent: on change l'ONT] :).
J'ai un ONT dédié qui est relié en RJ45 à la livebox (et c'est pour ça que pour l'instant je reste sur une livebox 4). Mais j'ai toujours l'ONT SFP de la livebox 4 initiale. Donc vendredi lorsque le support appellera, on fera le test d’utiliser le SFP ONT sur la livebox pour que les gars du niveaux 3 n’utilisent pas cette excuse pour traiter le ticket par dessus la jambe ...
J'espère juste que ça ne bloquera pas encore comme la dernière fois ou «ça devait marcher out-of-the-box» suite au changement de l'ONT et en fait ça n'a pas marché car il y avait un conflit entre l'update manuelle et automatique de la livebox ... (c'est pas comme si le technicien qui m'a installé la fibre n'avait pas eu des galères lors de l'installation de la ligne, probablement rien à voir, mais j'étais déjà au courant des «limitations» par ONT :/).
Donc je ne ferais la manipulation QUE si le gars peut intervenir immédiatement en cas de blocage du changement d'ONT (surtout qu'il faudra que je fasse le rollback, je peux pas laisser le SFP sur la livebox).
Bref va y avoir du sport.
-
Bonjour à tous,
Je profite d'un court (très très court) répit pour donner quelques nouvelles.
Ça ne marche toujours pas (normal).
Cependant, j'ai «un peu» avancé avec le support. Suite à «l'escalade» de la semaine dernière et à l'impasse, j'ai déposé une réclamation qui a planifié un nouveau rendez-vous. Celui-ci a eu lieu Mercredi matin. Après une nmième explication (rebelote toujours le même scenario) le technicien m'a dit qu'il contactait l'expert et qu'il me rappelait après. Chose faite deux heures plus tard, en me disant qu'ils avaient un problème de «charge» sur la machine qui collecte (je suppose) les arrivées des abonnés dans mon coin, qu'ils mettaient en place une sonde (un robot dans leur jargon) pendant 8 jours pour voir qui était impacté et qu'ils migreraient vers une nouvelle machine une fois les personnes impactées identifiées. Et il mettait en place un geste commercial sur les factures à venir (dont acte).
Du même coup, j'ai lancé un ping en boucle toutes les minutes pour me notifier du rétablissement de la connexion, mais j'ai un peu de mal à croire aux explications fournies. Pour moi, si c'était un problème de charge, j'aurais eu des sautes de débits voir des paquets jetés aléatoirement ... et c'est pas du tout le cas. Bref je suis pas sûr que les gars aient bien compris le problème, mais l'effet pourrais être le même, si je change de machine => une solution pour moi, mais je pleures en avance pour ceux qui resteront sur la dite machine ... (à moins q'à la faveur de la reconfiguration, ils fassent le ménage et «par accident» réparent le problème).
En tout cas, c'est toujours la croix et la bannière pour l'internet de tous les jours (l'airbox c'est terriblement lent tout de même).
Merci à tous.
Caeies.
-
Pour info à tout le monde, j'ai essayé la manip de casser/recréer le profil technique dans l'OLT mais sans succès.
-
Merci pour ton test et ton retour Vanilu76 !
Caeies,
-
Tous,
Il semblerait que le problème soit résolu depuis ~18:08 ce soir. 8)
Me reste à tester tout ce qui ne marchait pas pour vérifier que c'est de nouveau opérationnel !
Merci à tous pour votre aide.
Caeies.