Ping wird ab bestimmter Länge 'verschluckt'

Hallo zusammen,

nach einigen Problemen mit meiner Internetverbindung habe ich jetzt noch ein kleines Performance-Restproblem (erreiche nach Modemtausch durch Provider nur noch die Hälfte der vollen 32MBit im Downstream, wenn der Rechner im LAN hängt, und nicht direkt am Kabel-Modem. LAN ist vom Rechner über Switche und Router alles GBit).

Dieses Problem geht mit einem für mich nicht erklärbaren Ping-Verhalten einher:

Pinge ich innerhalb meines LANs umher mit „ping zielrechner -l Länge -f“ funktioniert alles tip-top. Alle Framegrößen gehen bis 1472 Byte ohne Fragmentierung und ohne Performance-Probleme durch.

Pinge ich einen Rechner ausserhalb meines LANs an (z.B. „ping google.de -f -l 1024“) funktioniert das auch solange ich die Framesize nicht größer als 1024 setze. Ab „-l 1025“ kommt einfach gar nichts mehr zurück außer der Meldung „Zeitüberschreitung der Anforderung“. Irgendwo wird mein Ping verschluckt. Die MTU ist aber bei allen beteiligten Geräten weit größer als 1024 eingestellt, daran sollte es also nicht liegen.

Kann mir jemand dieses Ping-Verhalten erklären? - (Ich vermute hier auch eine Ursache für das Performance-Prob. bei der Internet-Anbindung.)

Pinge ich einen Rechner ausserhalb meines LANs an (z.B. „ping
google.de -f -l 1024“)

Ob google.de nu so das ideal Ziel für Pingversuche ist…

google.de ping statistics —
1024 packets transmitted, 116 packets received, 88% packet loss

ICMP-Echo-Pakete werden gerne verworfen, da sie schlicht unwichtig sind.

Hi,

Pinge ich einen Rechner ausserhalb meines LANs an (z.B. „ping
google.de -f -l 1024“) funktioniert das auch solange ich die
Framesize nicht größer als 1024 setze. Ab „-l 1025“ kommt
einfach gar nichts mehr zurück außer der Meldung
„Zeitüberschreitung der Anforderung“. Irgendwo wird mein Ping
verschluckt. Die MTU ist aber bei allen beteiligten Geräten
weit größer als 1024 eingestellt, daran sollte es also nicht
liegen.

vielleicht hat ein Router auf dem Weg eine kleinere MTU eingestellt, und außerdem hat eigentlich jeder Router im Internet ein ICMP rate-limit konfiguriert. Mit dem Tool MTR kannst Du das etwas schöner diagnostizieren, gibt’s sogar für Windows.

Gruß,

Malte

Hallo,

wie Hermann bereits sagte: Google ist nicht das geeignete Testobjekt. Versuche es mal mit „rabenblicke.net“.

mfg, tf

Google war nur ein Beispiel als Ping-Ziel, ich habe dieses Verhalten bei allen externen Domains, auch bei meiner eigenen, die bei Schlund & Partner gehostet ist.

vielleicht hat ein Router auf dem Weg eine kleinere MTU
eingestellt, und außerdem hat eigentlich jeder Router im
Internet ein ICMP rate-limit konfiguriert.

Kann ich mir nicht so recht vorstellen, dann müßten ja alle Domainbetreiber den gleichen Mist eingestellt haben, es sei denn - fällt mir gerade ein, mein Kabel-Provider… Der hat nämlich vor Kurzem in unserem Gebiet von Docsis2 auf Docsis3 umgestellt, seither habe ich diverse Probleme auf der Leitung (hat inzwischen die Straße aufgegraben, Kabel geflickt, Modem getauscht, etc. --> Da könnten auch andere Dinge im Argen liegen als nur die Umstellung vom einen auf den anderen Standard)

Mit dem Tool MTR
kannst Du das etwas schöner diagnostizieren, gibt’s sogar für
Windows.

MTR kommt aus der Linux-Welt, oder? - Die Windows-Version habe ich nicht finden können. Gehe wohl mal mit Wire-Shark an das Problem ran. Vielleicht seh ich da was, habe aber keine große Hoffnung.

Das Verhalten ist domänenunabhängig, google war nur ein Beispiel.

Stell die MTU auf 1024
Hei!

Pinge ich einen Rechner ausserhalb meines LANs an (z.B. „ping
google.de -f -l 1024“) funktioniert das auch solange ich die
Framesize nicht größer als 1024 setze. Ab „-l 1025“ kommt
einfach gar nichts mehr zurück außer der Meldung
„Zeitüberschreitung der Anforderung“. Irgendwo wird mein Ping
verschluckt. Die MTU ist aber bei allen beteiligten Geräten
weit größer als 1024 eingestellt, daran sollte es also nicht
liegen.

Doch, genau daran liegt es!

Jeder Abschnitt auf dem Weg von deinem Rechner bis nach Google hat seine eigene Paketgröße. Auch Abschnitte/Netze/Router bei deinem Provider.
Irgendein Abschnitt hat offensichtlich eine maximale Paketgröße von 1024.

Wenn du gößere Pings mit -f (Schalter für: darf nicht fragmentiert werden) losschickst, werden die an genau dieser Stelle verworfen.
So bekommt man die MTU heraus. Das ist einfach nur das größtmögliche Paket, das man ohne Fragmentierung versenden kann.

Stelle die MTU auf deinen Rechnern und deinem Router auf 1024 ein, dann wird es gehen (und du wirst auch bessere Übertragungsraten bekommen, weil du jetzt durch die Framgentiererei zuviel Protokolloverhead produzierst).

Und ja, je nach Übertragungstechnik und Provider hat man immer verschiedene MTUs. Teilweise sogar verschiedene beim gleichen Provider in verschiedenen Orten (selbst erlebt!)

lg, mabuse

Hi,
vielen Dank für den Hinweis, probier ich mal aus, auch wenns mir komisch vorkommt.

Warum kommts mir komisch vor?

  1. Weil der Provider (Kabel BW) selbst behauptet ich solle die MTU auf 1460 einstellen.
  2. Ich das Problem bei allen Domains habe
  3. Wenn ich den Paramter -f angebe und das Paket zu groß ist nicht einfach keine Antwort mehr zurückkommt, sondern normalerweise die Meldung „Paket müsste fragmentiert werden, DF-Flag ist jedoch gesetzt.“
  4. Dieses seltsame Verhalten nur bei Framesizes zwischen 1025 und 1472 Bytes vorhanden ist. Ab 1473 bekomme ich die unter 3. genannte Meldung.

… Du verstehst meine Verwirrung?

Hi mabuse…

da fällt mir noch was ein…
Nach meinen Informationsstand gehen in einen IP-Frame brutto 1500
Byte. Für die Bestimmung der MTU gehen jetzt noch 28 Byte für den
Header wech, bleiben 1772.
Hat man eine Anbindung über PPPOE (hab ich nicht) gehen nochmal
12 Byte wech für den PPPOE-Header, bleiben noch 1460.

Welcher Scherzkeks verbraucht mir dann die noch verbleibenden 436
Byte? - Wenn das so ist, wie Du beschreibst, kann das für mich
nur ein Konfig-Fehler auf Seiten des Providers sein, da doch
eigentlich jeder der solche Gerätschaften professionell
betreibt ein Interess daran hat die mögliche Framegröße möglichst
gut auszunutzen um den Overhead durch die Header möglichst klein
zu halten. Oder sehe ich das so falsch?

Sollte ich da nicht nochmal mit meinem Provider drüber
philosophieren bevor sich mir angesichts einer 1024er-MTU
sämtliche Nackenhaare aufstellen?

vielleicht hat ein Router auf dem Weg eine kleinere MTU
eingestellt, und außerdem hat eigentlich jeder Router im
Internet ein ICMP rate-limit konfiguriert.

Kann ich mir nicht so recht vorstellen, dann müßten ja alle
Domainbetreiber den gleichen Mist eingestellt haben

Es reicht, wenn ein Router von Deinem Upstream fehlkonfiguriert ist :wink:

es sei denn - fällt mir gerade ein, mein Kabel-Provider…

Genau…

MTR kommt aus der Linux-Welt, oder? - Die Windows-Version habe
ich nicht finden können.

http://winmtr.sourceforge.net/

Poste mal das Ergebnis hier, könnte erleuchtend sein. Allerdings weiß ich nicht, welche Optionen die Windowsversion bietet. In der Lunix-Version kann man auch ICMP ODER UDP Pakete benutzen, auch das wäre interessant.

Viele Grüße,

Malte

Hallo,

ICMP-Echo-Pakete werden gerne verworfen, da sie schlicht
unwichtig sind.

Dieser Thread zeigt doch gerade, wie wichtig ICMP Typ 3, Code 4 (fragmentation required) Nachrichten sind und warum diese eben *nicht* verworfen werden sollten.

Diese Unsitte, jeglichen ICMP Traffic zu verwerfen, hat Path MTU discovery auf dem Gewissen. Jetzt gibt es nur noch die Krücke über MSS clamping.

Es ist zu hoffen, dass das mit der Umstellung auf IPv6 und dem einhergehenden ICMPv6 wieder korrigiert wird.

Gruß

Fritze

Hallo,

da fällt mir noch was ein…
Nach meinen Informationsstand gehen in einen IP-Frame brutto
1500 Byte.

Das ist nicht korrekt. Das Längenfeld hat eine Größe von 16 Bit, d.h. IP Pakete mit einer Länge von 65535 Bytes sind zulässig.

Die 1518 Byte Grenze (1500 Byte Payload) stammt von einem Layer weiter unten: Ethernet.

Byte? - Wenn das so ist, wie Du beschreibst, kann das für mich
nur ein Konfig-Fehler auf Seiten des Providers sein, da doch
eigentlich jeder der solche Gerätschaften professionell
betreibt ein Interess daran hat die mögliche Framegröße
möglichst
gut auszunutzen um den Overhead durch die Header möglichst
klein
zu halten. Oder sehe ich das so falsch?

Kommt darauf an. Vielleicht möchte man ja auch viele VoIP Pakete (die sind eher klein) übertragen und nicht so viele große HTTP Pakete, die Jitter erzeugen können?

Sollte ich da nicht nochmal mit meinem Provider drüber
philosophieren bevor sich mir angesichts einer 1024er-MTU
sämtliche Nackenhaare aufstellen?

Warum eigentlich?

Gruß

Fritze

Hei!

Nach meinen Informationsstand gehen in einen IP-Frame brutto 1500

Byte. Für die Bestimmung der MTU gehen jetzt noch 28 Byte für den
Header wech, bleiben 1772.
Nein.
1.) es sind 1500 Netto.
2.) IP-Frame kann beliebige Größe haben (siehe z.B. DNS-Abfragen oder ACK-Pakete, das sind nur eine handvoll Bytes).
3.) Die 1500 kommen aus dem Ethernet
4.) Es gibt auch noch andere Netzwerk-Arten. Insbesondere die Anbindung an’s Web (sprich: die Leitung vom Access-Concentrator zur Zentrale deines Providers und besonders die dicken Transatlantik-Leitungen) haben mit Ethernet nicht das geringste zu tun. Ethernet ist aufgrund der Längen-Beschränkungen (max. 100 m zwischen zwei Geräten, max. 300 m zwischen zwei Endgeräten) prinzipiell nur innerhalb eines Gebäudes bzw. eines kleineren Komplexes geeignet. Sobald eine längere Strecke dazwischen liegt, muss man auf ein anderes Netz wechseln, ATM oder was es da alles gibt (da hab ich jetzt auch nur ein nebulöses halbwissen).
Und andere Netze können durchaus andere Framegrößen haben.

Speziell deshalb gibt es die ja Möglichkeit, Pakte zu fragmentieren.

Und es ist immer sinnvoll, seine Geräte an diese Technik anzupassen:
Hast du eine zu große MTU, dann werden deine Pakte an der dünnsten Stelle auf zwei Pakete (oder mehr) verteilt. Das kostet a) Zeit und b) zusätzlichen Protokoll-Overhaed, also Bandbreite.
Hast du eine zu kleine MTU, dann ist das Verhältnis Gesamtdaten zu Nutzlast nicht mehr optimal, du verschenkst also auch ein bischen (nur wenig) Bandbreite.

Vor allem gibt es aber einige Seiten (besonders Banken!), die keine fragmentierten Frames akzeptieren! Ich hab in meinem Bekanntenkreis einige Leute, die nur mit einer richtig eingestellten MTU Online-Banking machen können (ist wohl eine Sicherheitsmaßnahme der Banken), auch eBay ist bei falscher MTU machmal störrisch.

Welcher Scherzkeks verbraucht mir dann die noch verbleibenden 436 Byte? - Wenn das so ist, wie Du beschreibst, kann das für mich nur ein Konfig-Fehler auf Seiten des Providers sein, da doch eigentlich jeder der solche Gerätschaften professionell betreibt ein Interess daran hat die mögliche Framegröße möglichst gut auszunutzen um den Overhead durch die Header möglichst klein zu halten. Oder sehe ich das so falsch?

Das siehst du in der Tat falsch. Die Bytes werden nicht verbraucht. Es gibt zwischendurch nur eine technische Einheit (Netzwerk, Gerät), die mit solchen großen Frames nicht zurechtkommt - aus welchen Gründen auch immer - und deshalb dein großes Frame auf zwei kleinere verteilt.

Das ist absolut gängige Technik, auch wenn die reine Größe deiner MTU von 1024 eher ungewöhnlich ist. Also, ungewöhnlich im Sinne dessen, was es bei anderen Providern gibt.
Sie ist außerordentlich logisch, wenn es verarbeitende Geräte in der Leitung gibt (transparente Proxys, Filter oder sowas), weil Speicher in solchen Geräten natürlich meist volle KiloBytes sein werden.

Sollte ich da nicht nochmal mit meinem Provider drüber
philosophieren bevor sich mir angesichts einer 1024er-MTU
sämtliche Nackenhaare aufstellen?

Ich bezweifle ernsthaft, das du da jemanden finden wirst, der das Problem nachvollziehen kann. Die kaufen einfach Geräte von der Stange (Okay, Stange im Fachhandel) und stöpseln die mit minimalem Konfigurationsaufwand zusammen. Selbst wenn man die Frame-Größe einstellen kann (was je nach Art des Engpasses nicht unbedingt möglich sien muss), dann werden die das kaum aus dem Ärmel können, sondern sich erstmal einlesen müssen - und ob die in Anbetracht ihres Geräteparkes da überhaupt Lust zu haben (es dürfte ja nicht nur ein Übergabepunkt, sondern Dutzende bis Tausende sein) - also, ich hab da so meine Zweifel . . .

Besorg dir den TCP-Optimizer (http://sg-tcp-optimizer.softonic.de/, Freeware), der analysiert deine Verbindung und passt MTU (und ein paar andere Einstellungen) optimal an. Dauert nur eine Minute, dannach läuft deine Leitung auf max.

lg, mabuse

Hi,
vielen Dank für den Hinweis, probier ich mal aus, auch wenns mir komisch vorkommt.

Ganz offen: mir kommt diese Zahl auch komisch vor.
Ich gehe mal davon aus, das der „Fehler“ in deiner unmittelbaren Nähe liegt (Konfiguration des Access-Concentrators). Aber ich bezweifele wirklich, das sich der Provider von deinen Fehlermeldungen groß was annehmen wird. Und selbst wenn, dann wird das wohl eher Monate als Wochen dauern, bis die da was ändern.

Warum kommts mir komisch vor?

  1. Weil der Provider (Kabel BW) selbst behauptet ich solle die MTU auf 1460 einstellen.

Das heisst nichts. Die haben ja auch nicht überall die gleiche Hardware. Ich selber musste nach einem Umzug (zwei verschiedene Städte) auch die MTU umstellen, obwohl ich beim gleichen Provider (Telekom) geblieben bin. In MG war die MTU 1472, in Krefeld sind’s „nur“ noch 1456. Aber der Unterschied verhagelt einem schon die eine oder andere Seite.

  1. Ich das Problem bei allen Domains habe

Das ist nur logisch. Wenn’s einen Engpass auf dem Weg ins Internet gibt, dann betrifft der natürlich das gesamte Internet.

  1. Wenn ich den Paramter -f angebe und das Paket zu groß ist nicht einfach keine Antwort mehr zurückkommt, sondern normalerweise die Meldung „Paket müsste fragmentiert werden, DF-Flag ist jedoch gesetzt.“

Nein, die werden einfach nur verworfen.
hab ich gerade mal eben ausprobiert, wenn ich Google oder andere mit 1500 anpinge, dann kommt einfach nur „Zeitüberschreitung der Anforderung“

  1. Dieses seltsame Verhalten nur bei Framesizes zwischen 1025 und 1472 Bytes vorhanden ist. Ab 1473 bekomme ich die unter 3. genannte Meldung.

Das überrascht mich. Ich hab solch eine Meldung noch nie zu gesicht bekommen. Vieleicht eine Sonderfunktion irgendeines Gerätes vor der eigentlichen Engstelle, die vorher schon auf etwas kleineres fragmentieren müsste.
Dieses würde dann bei den großen Paketen diese Fehlermeldung zurückschicken und kleinere durchlassen. Und die kleineren werden dann erst später bei einem anderen Gerät verworfen, wenn das erste Gerät keine Meldung mehr zurücksendet, weil es denkt, alles wäre in Ordnung.

… Du verstehst meine Verwirrung?

Sagen wir: ich kann sie nachvollziehen.
Aber du wirst schwerlich was ändern können.

Wie oben schon geschrieben: zieh dir den TCP-Optimizer und pass dich an die Technik deiner Leitung an. Du kannst ja außerdem mit deinem Provider kommunizieren, vieleicht hast du ja Glück, und der ändert etwas. Daher den TCP-Optimizer einmal die Woche oder so laufen lassen, damit du es auch mitbekommst, wenn sich was ändert.

Und nicht vergessen: alle Geräte deines lokalen Netzes anpassen, vor allem auch den Router.

lg, mabuse

Hallo,

hast Du mal einen Domain-Namen für mich. Würde gerne mal etwas überprüfen.

mfg, tf

Hallo,

ICMP-Echo-Pakete werden gerne verworfen, da sie schlicht
unwichtig sind.

Dieser Thread zeigt doch gerade, wie wichtig ICMP Typ 3, Code
4 (fragmentation required) Nachrichten sind und warum diese
eben *nicht* verworfen werden sollten.

Diese Unsitte, jeglichen ICMP Traffic zu verwerfen, hat Path
MTU discovery auf dem Gewissen. Jetzt gibt es nur noch die
Krücke über MSS clamping.

Das Problem ist eher, daß viele Leute „bekannte“ Server/Adressen mißbrauchen. Als Admin dort würde ich auch Pingfloods abwürgen und schlicht auf drop stellen, speziell bei aufgefüllten Echos, denn die verbraten eben auch Bandbreite. Und muss ein Router, weil seine Queue voll ist, verwerfen, sind ICMP-Echo-Pakete sicherlich eine gute Wahl.

Wenn Du einen Domänennamen meinst bei dem bei mir das beschriebene Verhalten auftritt? - Klar, da kannst Du eigentlich jeden nehmen.

Mit den folgenden hab ich es z.B. mal probiert, bei allen das gleiche Verhalten: google.de ; rabenblick.de ; narrenkappe.de ; jhohlwegler.de und speedtest.org

Hi Malte,
also, ich hab jetzt mal ausprobiert, kann aber nix Erhellendes entdecken.
Hier wie gewünscht das WinMTR-Ergebnis und vorher noch das Ganze mit nem Standard-Ping:

Hier die Standard-Pings:
*********************************************************
*************** Standard-Ping ON ************************
*********************************************************
C:\>ping speedtest.org -f -l 1024

Ping speedtest.org [72.233.89.199] mit 1024 Bytes Daten:

Antwort von 72.233.89.199: Bytes=1024 Zeit=144ms TTL=111
Antwort von 72.233.89.199: Bytes=1024 Zeit=144ms TTL=111
Antwort von 72.233.89.199: Bytes=1024 Zeit=148ms TTL=111
Antwort von 72.233.89.199: Bytes=1024 Zeit=146ms TTL=111

Ping-Statistik für 72.233.89.199:
Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0 (0% Verlust),
Ca. Zeitangaben in Millisek.:
Minimum = 144ms, Maximum = 148ms, Mittelwert = 145ms

C:\>ping speedtest.org -f -l 1025

Ping speedtest.org [72.233.89.199] mit 1025 Bytes Daten:

Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.

Ping-Statistik für 72.233.89.199:
Pakete: Gesendet = 4, Empfangen = 0, Verloren = 4 (100% Verlust),

C:\>ping speedtest.org -f -l 1461

Ping speedtest.org [72.233.89.199] mit 1461 Bytes Daten:

Paket müsste fragmentiert werden, DF-Flag ist jedoch gesetzt.
Paket müsste fragmentiert werden, DF-Flag ist jedoch gesetzt.
Paket müsste fragmentiert werden, DF-Flag ist jedoch gesetzt.
Paket müsste fragmentiert werden, DF-Flag ist jedoch gesetzt.

Ping-Statistik für 72.233.89.199:
Pakete: Gesendet = 4, Empfangen = 0, Verloren = 4 (100% Verlust),

C:\>
*********************************************************
*************** Standard-Ping OFF ***********************
*********************************************************

*********************************************************
*************** WinMTR-Erg. ON **************************
*********************************************************
Auch wieder speedtest.org mit Frame-Größe 1024:
|------------------------------------------------------------------------------------------|
| WinMTR statistics |

Host - % Sent Recv Best Avrg Wrst Last
172.16.1.253 - 0 9 9 0 3 16 0
No response from host - 100 9 0 0 0 0 0
172.30.12.33 - 0 8 8 0 13 16 16
172.30.12.253 - 13 8 7 0 17 46 15
ae0.FRA-M1.ip-bb.kabel-badenwuerttemberg.de - 0 8 8 15 15 16 15
9-3-0.edge5-frankfurt.eu.level3.net - 0 8 8 15 21 31 31
vlan99.csw4.Frankfurt1.Level3.net - 0 8 8 15 25 32 15
ae-92-92.ebr2.Frankfurt1.Level3.net - 0 8 8 16 23 32 31
ae-43-43.ebr2.Washington1.Level3.net - 0 8 8 94 111 125 110
ae-72-72.csw2.Washington1.Level3.net - 0 8 8 94 117 125 94
ae-71-71.ebr1.Washington1.Level3.net - 0 8 8 109 121 125 110
ae-2.ebr3.Atlanta2.Level3.net - 13 8 7 125 129 141 125
ae-7.ebr3.Dallas1.Level3.net - 0 8 8 140 150 157 157
ae-4-90.edge3.Dallas1.Level3.net - 0 8 8 140 144 157 157
DATABANK-HO.edge3.Dallas1.Level3.net - 0 8 8 140 142 157 157
dbce10glt.layeredtech.com - 0 8 8 140 146 156 141
No response from host - 100 8 0 0 0 0 172
199.89.233.72.static.reverse.ltdomains.com - 0 8 8 140 146 156 141
________________________________________________ ______ ______ ______ ______ ______ ______

WinMTR - 0.8. Copyleft @2000-2002 Vasile Laurentiu Stanimir ( [email protected] )

Und nochmal mit Frame-Größe 1025:
|------------------------------------------------------------------------------------------|
| WinMTR statistics |

Host - % Sent Recv Best Avrg Wrst Last
172.16.1.253 - 0 9 9 0 0 0 0
No response from host - 100 9 0 0 0 0 0
172.30.12.33 - 0 8 8 15 15 16 15
172.30.12.253 - 13 8 7 15 15 16 15
ae0.FRA-M1.ip-bb.kabel-badenwuerttemberg.de - 0 8 8 15 23 46 46
9-3-0.edge5-frankfurt.eu.level3.net - 0 8 8 15 25 78 16
vlan99.csw4.Frankfurt1.Level3.net - 0 8 8 16 27 32 16
ae-92-92.ebr2.Frankfurt1.Level3.net - 0 8 8 15 15 16 16
ae-43-43.ebr2.Washington1.Level3.net - 0 8 8 109 111 125 110
ae-72-72.csw2.Washington1.Level3.net - 0 8 8 109 117 125 110
ae-71-71.ebr1.Washington1.Level3.net - 0 8 8 109 125 141 141
ae-2.ebr3.Atlanta2.Level3.net - 50 8 4 125 129 141 125
ae-7.ebr3.Dallas1.Level3.net - 13 8 7 140 147 156 156
ae-4-90.edge3.Dallas1.Level3.net - 0 8 8 140 144 156 140
DATABANK-HO.edge3.Dallas1.Level3.net - 0 8 8 140 150 157 140
dbce10glt.layeredtech.com - 0 8 8 141 146 156 141
No response from host - 100 8 0 0 0 0 172
199.89.233.72.static.reverse.ltdomains.com - 0 8 8 140 142 156 141
________________________________________________ ______ ______ ______ ______ ______ ______

WinMTR - 0.8. Copyleft @2000-2002 Vasile Laurentiu Stanimir ( [email protected] )
*********************************************************
*************** WinMTR-Erg. OFF **************************
*********************************************************

Ich kann da keinen Unterschied erkennen, der mir zu meinem Problem etwas sagen würde, zumal ich
bei diesem Prog kein DF-Flag setzen kann.

Ich habe aber mal mit Wire-Shark draufgeschaut und der behauptet, dass bei Frame-Größe 1025-1460
ein „Port nicht verfügbar“ zurückkommt. Die Meldung kann ich aber auch nicht mit dem Ping-Verhalten
zusammen bringen.

D.h. - die Ratlosigkeit bleibt.

Hi,

also, es gibt für das Linux-MTR patches, die zeigen, an welcher Stelle ein „MTU-Engpass“ vorliegt, für die Windowsversion hingegen wohl leider nicht. Mir fällt jetzt auf die Schnelle auch nichts ein, als Dich an Deinen Provider zu verweisen, mit all den Infos, die Du hier schon so schön gesammelt hast.

Gruß,

Malte