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

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

Fuli10 · « **Réponse #1 le:** 22 juin 2022 à 09:19:24 »

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.

vivien · « **Réponse #2 le:** 22 juin 2022 à 09:28:04 »

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.

caeies · « **Réponse #3 le:** 22 juin 2022 à 09:50:11 »

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.

caeies · « **Réponse #4 le:** 22 juin 2022 à 10:45:19 »

Bon,

voici un test en upload sur ping.online.net (udp) (abrégé):

Code: [Sélectionner]

- - - - - - - - - - - - - - - - - - - - - - - - -
[ 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,

vivien · « **Réponse #5 le:** 22 juin 2022 à 10:46:47 »

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é.

caeies · « **Réponse #6 le:** 22 juin 2022 à 17:54:26 »

Un problème comme ça par exemple :

Code: [Sélectionner]

 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.

vivien · « **Réponse #7 le:** 22 juin 2022 à 19:44:47 »

Le pourcentage de perte de paquet est trop faible pour avoir un impact fort sur ta connexion.

C'est étrange.

caeies · « **Réponse #8 le:** 22 juin 2022 à 21:08:29 »

Bon je viens de faire le test, mais dans l'autre sens:

Code: [Sélectionner]

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,

caeies · « **Réponse #9 le:** 22 juin 2022 à 21:22:05 »

J'en ai fait un plus long, avec un débit plus faible:

Code: [Sélectionner]

 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).

caeies · « **Réponse #10 le:** 22 juin 2022 à 21:40:56 »

Ok, en faisant un ping sweep sur ping.online.net:

Code: [Sélectionner]

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:

Code: [Sélectionner]

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:

Code: [Sélectionner]

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,

caeies · « **Réponse #11 le:** 22 juin 2022 à 22:05:09 »

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 ....

Code: [Sélectionner]

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.