Question POST de MTU + ~ 798 octets est perdu


J'ai un problème très étrange avec certains paquets qui n'arrivent pas sur l'hôte de destination. Cela se produit lorsque nous transmettons un POST un peu plus grand que le MTU. Nous pouvons le reproduire avec ce script:

#!/usr/bin/python

import urllib2

magic_length = 2297
logurl = 'http://www.example.nl/'
data = (magic_length - len(logurl)) * 'X'
headers = {'content-type': 'application/x-www-form-urlencoded', 'User-Agent': 'Fake'}
request = urllib2.Request(logurl, data, headers)                                        
handler = urllib2.build_opener(urllib2.HTTPHandler())                                   
answer = handler.open(request, timeout=5)

La partie d'envoi ne reçoit pas d'accusé de réception et effectue des retransmissions. La partie qui reçoit ne le voit jamais.

Cela dépend de l'endroit où vous exécutez le script et de l'endroit où vous postez. Ma connexion à domicile est une connexion qui échoue (et, accessoirement, des problèmes d’AJAX POST ne s’aboutissent pas depuis quelques mois; depuis que j’ai un nouveau modem).

Si je réduis le MTU de la machine d'envoi de 100, cela fonctionne à nouveau. Mais si je réduis magic_length par 100 aussi, il échoue à nouveau. Une première théorie était qu'une couche de mon ADSL (comme PPPoA) ajoute des en-têtes et entraîne la division erronée des paquets, mais cela ne semble pas être le cas.

Peut-être que quelque chose ne va pas avec la découverte de MTU. Certains sautent sur la ligne bloquant tous les ICMP peut-être? Ceci est la première partie d'un traceroute à google de chez moi:

traceroute to google.com (74.125.133.102), 30 hops max, 60 byte packets
 1  dsldevice.lan (192.168.2.254)  0.453 ms  0.547 ms  0.636 ms
 2  195.190.243.7 (195.190.243.7)  29.836 ms  29.947 ms  29.986 ms
 3  nl-zl-dc2-git-cr02.kpn.net (213.75.64.237)  37.004 ms  37.153 ms  37.204 ms
 4  nl-rt-dc2-ice-ir02.kpn.net (213.75.64.236)  37.261 ms  37.300 ms  37.339 ms
 5  72.14.198.161 (72.14.198.161)  38.351 ms  38.395 ms  38.405 ms
 6  209.85.254.92 (209.85.254.92)  37.976 ms  38.103 ms  37.972 ms
 7  209.85.253.247 (209.85.253.247)  38.612 ms 72.14.238.153 (72.14.238.153)  33.709 ms 209.85.253.249 (209.85.253.249)  36.890 ms
 8  209.85.240.158 (209.85.240.158)  41.052 ms  41.104 ms 209.85.244.102 (209.85.244.102)  41.164 ms
 9  209.85.249.12 (209.85.249.12)  38.392 ms 209.85.249.14 (209.85.249.14)  38.247 ms  38.851 ms^C

Si je fais un ping sur 213.75.64.237, je reçois (je n'ai jamais vu réellement «paquet filtré» en réponse à STDOUT ...):

PING 213.75.64.237 (213.75.64.237) 56(84) bytes of data.
From 213.75.64.237 icmp_seq=1 Packet filtered

Le reste je peux cingler.

Cette réponse semble similaire. Cependant, mon script ne définit pas l'indicateur DF (ne fragmente pas) (édition: correction, le tcpdmp indique que cet indicateur est défini sur la demande POST), et je ne peux pas voir les demandes ICMP me revenir lorsque j'exécute l'application. script sur un hôte qui Est-ce que travail. De plus, les paquets sont déjà divisés par l'expéditeur et l'envoi du second paquet échoue.

Comment je procède? Les CNO des FAI sont assez difficiles à atteindre tels quels. J'ai donc besoin de preuves de ce qui se passe. Ils ne vont pas m'aider à comprendre ça ...

Edit: pour confirmer ou infirmer les hypothèses de type 4 d’ICMP (fragmentation requise), j’ai fait ceci:

$ ping -c 1 -M do -s 1472 host
PING host (1.2.3.4) 1472(1500) bytes of data.
1480 bytes from host (1.2.3.4): icmp_req=1 ttl=50 time=33.8 ms

Cela fonctionne, mais je suis un peu confus. Le "(1500)" signifie-t-il la taille totale du fragment? Je suppose que oui, car l’en-tête IP de 1480 octets + 20 octets correspond à 1500 octets.

Si j'augmente la taille du ping de un:

$ ping -c 1 -M do -s 1473 host
PING host (1.2.3.4) 1473(1501) bytes of data.
From pannekoek.lan (192.168.2.5) icmp_seq=1 Frag needed and DF set (mtu = 1500)

Cela signifie donc que le chemin entre les deux hôtes autorise les paquets de 1500 octets et qu'aucun problème de fragmentation ne se produit. Il semble que je suis de retour à la case départ.

Modifier à nouveau: j'ai trouvé quelque chose d'important. Le problème est simplement que des paquets de certaines tailles n'arrivent pas. Cela se produit entre mon modem et la première passerelle du FAI:

$ for i in `seq 1025 1030`; do ping -c 1 -M do -s $i 195.190.243.7; done
PING 195.190.243.7 (195.190.243.7) 1025(1053) bytes of data.
1033 bytes from 195.190.243.7: icmp_req=1 ttl=254 time=31.2 ms  <- works

--- 195.190.243.7 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 31.273/31.273/31.273/0.000 ms
==========================
PING 195.190.243.7 (195.190.243.7) 1026(1054) bytes of data.

--- 195.190.243.7 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms <- packet loss   
==========================
PING 195.190.243.7 (195.190.243.7) 1027(1055) bytes of data.

--- 195.190.243.7 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms <- packet loss
==========================
PING 195.190.243.7 (195.190.243.7) 1028(1056) bytes of data.

--- 195.190.243.7 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms <- packet loss
==========================
PING 195.190.243.7 (195.190.243.7) 1029(1057) bytes of data.

--- 195.190.243.7 ping statistics --- 
1 packets transmitted, 0 received, 100% packet loss, time 0ms <- packet loss
==========================
PING 195.190.243.7 (195.190.243.7) 1030(1058) bytes of data.
1038 bytes from 195.190.243.7: icmp_req=1 ttl=254 time=31.1 ms <- works

--- 195.190.243.7 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 31.177/31.177/31.177/0.000 ms

Je suppose que je dois les convaincre que c'est leur problème.


5
2017-10-27 10:59


origine


Ce type de problème est généralement dû à un blocage des réponses ICMP résultant de Path MTU Discovery. Le problème est que le retour des messages ICMP ne fait pas partie du problème - s'ils n'étaient pas bloqués, votre ordinateur les recevrait et abaisserait le MTU du chemin comme requis. - Barmar
@Barmar, c’était bien mes hypothèses, mais je pense que j’ai prouvé le contraire. Voir ma dernière édition. - Halfgaar
Bizarre. Une remarque - assurez-vous que vous avez plus d'une séquence de pings pour montrer un modèle de taille de paquet. La priorité la plus basse d'un routeur est de répondre aux pings. Ainsi, si le routeur est occupé, il abandonnera les demandes plutôt que de répondre. Vous l'avez peut-être déjà fait, mais votre exemple ne montre que l'exécution. - Dan Pritts
@DanPritts J'ai été capable de le faire de manière constante depuis ce poste. Le fournisseur de services Internet dit qu'il étudie la question, mais je me demande s'ils sont vraiment ... - Halfgaar
Un test relativement simple consiste à remplacer votre modem. Un bogue dans le micrologiciel qui pourrait faire quelque chose comme ça. Sans aucune visibilité sur le réseau, vous ne pouvez pas faire grand chose. - Dan Pritts


Réponses:


Quelque part le long de la ligne allant du point A au point B, un routeur a été configuré avec un MTU inférieur et c’est ce qui rompt. Avez-vous essayé de tracer pour voir où exactement les paquets ICMP sont perdus?


1
2018-01-31 07:43



Je ne pense pas que ce soit / était-ce, parce que je ne reçois pas la réponse requise de fragmentation. Et, cela est arrivé lors de la connexion à la première passerelle derrière le modem. - Halfgaar