6
Ping funktioniert bei bestimmten Paketgrößen nicht
Ich nutze hier ein Netzwerk, dass über (vermutlich einen Tunnel von) HOTSPLOTS Internetzugang bereitstellt. Dieser ist leider oft gestört (Paketverluste); ein Fehler konnte durch den Betreiber nicht gefunden werden.
Ich habe nun festgestellt, dass ping je nach Paketgröße mal funktioniert, mal nicht ($target ist ein Server im WWW, die MTU der WLAN-Netzwerkkarte liegt bei 1500):
Bei 0 <= $psize <= 1420 funktioniert der ping.
Bei 1420 < $psize <= 1472 funktioniert er nicht.
Bei 1472 < $psize funktioniert er wieder.
Nicht funktionieren heißt, dass der ping beim Zielrechner nicht ankommt. Woran kann das liegen? Oder wie kann ich dem genauer nachgehen?
Beispiele aus tcpdump:
$psize = 1420
Senkt man $psize, dann sinken die beiden length-Werte gleichermaßen.
$psize = 1471
$psize = 1472
$psize = 1473
Erhöht man $psize, ändern sich die length-Werte dennoch nicht.
Ich habe nun festgestellt, dass ping je nach Paketgröße mal funktioniert, mal nicht ($target ist ein Server im WWW, die MTU der WLAN-Netzwerkkarte liegt bei 1500):
ping -s $psize $targetBei 0 <= $psize <= 1420 funktioniert der ping.
Bei 1420 < $psize <= 1472 funktioniert er nicht.
Bei 1472 < $psize funktioniert er wieder.
Nicht funktionieren heißt, dass der ping beim Zielrechner nicht ankommt. Woran kann das liegen? Oder wie kann ich dem genauer nachgehen?
Beispiele aus tcpdump:
$psize = 1420
23:00:38.782680 IP (tos 0x0, ttl 64, id 57655, offset 0, flags [DF], proto ICMP (1), length 1448) 192.168.46.34 > $target: ICMP echo request, id 23436, seq 3, length 142823:00:38.801062 IP (tos 0x0, ttl 55, id 20557, offset 0, flags [none], proto ICMP (1), length 1448) $target > 192.168.46.34: ICMP echo reply, id 23436, seq 3, length 1428Senkt man $psize, dann sinken die beiden length-Werte gleichermaßen.
$psize = 1471
23:13:56.614122 IP (tos 0x0, ttl 64, id 16379, offset 0, flags [DF], proto ICMP (1), length 1449) 192.168.46.34 > $target: ICMP echo request, id 24033, seq 1, length 1429$psize = 1472
23:11:07.649046 IP (tos 0x0, ttl 64, id 50701, offset 0, flags [DF], proto ICMP (1), length 1500) 192.168.46.34 > $target: ICMP echo request, id 23924, seq 1, length 1480$psize = 1473
23:12:22.681198 IP (tos 0x0, ttl 64, id 64560, offset 0, flags [+], proto ICMP (1), length 1500) 192.168.46.34 > $target: ICMP echo request, id 23947, seq 1, length 148023:12:22.702337 IP (tos 0x0, ttl 55, id 62310, offset 0, flags [+], proto ICMP (1), length 1444) $target > 192.168.46.34: ICMP echo reply, id 23947, seq 1, length 1424Erhöht man $psize, ändern sich die length-Werte dennoch nicht.
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 6617522199
Url: https://administrator.de/contentid/6617522199
Printed on: May 5, 2024 at 22:05 o'clock
6 Comments
Latest comment
tracepath -n -l 1448 $target
1: 192.168.44.1 3.122ms
2: 172.30.0.1 6.788ms
3: 77.247.85.97 6.848ms
etc.
tracepath -n -l 1449 $target
1: 192.168.44.1 29.163ms
2: no reply
3: no reply
etc.
tracepath erstmal ohne den Parameter "-l" aufrufen! Dann sucht tracepath sich selbst die MTUs raus und schreibt die pmtu auch hin.
lks
lks
Woran kann das liegen?
Du hast eine falsche Tunnel MTU und eine falsche MSS Size gesetzt mit anderen Worten ein falsche Tunnel Setup so das es zu Fragmentierungen kommt.In einem Tunnel muss die MTU natürlich kleiner sein wegen des Encapsulation Overheads. Bzw. die MSS Size im lokalen LAN.
https://de.wikipedia.org/wiki/Maximum_Transmission_Unit
https://baturin.org/tools/encapcalc/
Nur zur Klarstellung: Das Setup des Tunnels macht Hotsplots, nicht ich. Mir geht es auch darum, Hotsplots eine korrekte Fehlerangabe machen zu können, da sie auf die bloße Störungsmeldung hin seit einem Jahr den Fehler nicht beheben konnten/wollten.
Sehe ich es richtig, dass eine Fragmentierung alleine noch nicht erklärt, warum hier Pakete ohne Fehlermeldung gar nicht ankommen?
Sehe ich es richtig, dass eine Fragmentierung alleine noch nicht erklärt, warum hier Pakete ohne Fehlermeldung gar nicht ankommen?
Das Setup des Tunnels macht Hotsplots, nicht ich.
Igitt, einer dieser gruseligen öffentlichen Tunnelprovider...?! 
Aber abgesehen davon hat das damit nichts zu tun, weil du grundsätzlich in einem VPN Tunnel ja ein Tunnel Encapsulation Protokoll hast was damit deine Produktivdaten verschlüsselt transportiert.
Eine andere MTU als die klassische 1500er Eternet MTU ist dann also immer evident!
da sie auf die bloße Störungsmeldung hin seit einem Jahr den Fehler nicht beheben konnten/wollten.
Das hängt ja nicht nur von denen ab. Wenn DU auf deinem Tunnel Endpoint weiterhin eine falsche MTU und MSS nutzt, also keinerlei VPN Clamping dann können die Räuber Hotsenplots soviel ändern wie sie wollen, dann wird das nix. Einfache Logik....warum hier Pakete ohne Fehlermeldung gar nicht ankommen?
Doch, deren Engeräte setzen das DF Bit und damit unterbleibt dann eine Fragmentierung. Sprich der Router droppt (schmeisst weg) dann einfach diese Frames weil er sie ja durch die fehlende Fragmentierung nicht loswerden kann. Was soll er auch sonst machen...?!