Diverse Webseiten können nicht angezeigt werden...

[Thomas Wildgruber]

Hi Group,

ich versuche gerade im HDS-Forum ein Problem mit Snow Leopard zu debuggen,
wo einige Internetseiten nicht angezeigt werden können. Auf den Thread ist
ein anderer User aufgesprungen, welcher ein ähnliches Problem hat und damit
schon seit Januar rumdoktert. Bei diesem zweiten User habe ich das
Fehlerbild so verstanden, dass *alle* Rechner im Netz von der selben
Problematik betroffen sind, was mich erstmal ein DNS Problem vermuten lies
aber ein nslookup im Doublecheck (er hat meinen DNS Server probiert, ich
den seinen) hat jeweils die selbe IP ausgespukt.

Jetzt habe ich noch evtl. Probleme beim Provider in Verdacht und bin auf
eine etwas unkonventionelle Idee gekommen, weis aber nicht recht ob dieser
Test aussagekräftig ist (ich habe noch keine Resultate). Ich habe dem User
eine Website zum anonymen Surfen gegeben: http://hujiko.com/ [1] und er
sollte schauen ob er über diese Seite quasi als Proxy die Seite erreichen
kann. Ich warte noch auf das Ergebnis aber ich bin mir jetzt nicht sicher
ob und wie weit das Resultat aussagekräftig ist.

Wenn er die Seite dann erreichen kann, verschiebt sich das Problem IMHO
deutlich Richtung Provider aber wenn er es nicht erreichen kann, ist der
Provider dann definitiv entlastet? Ich weis, solche Seiten braucht man
normalerweise nicht aber ich dachte mal ganz naiv, ob ich das nicht auch
zum Debuggen nutzen kann. Wie ist eure Einschätzung? (Den Hinweis, dass zum
Testen keine vertraulichen Daten gesendet werden sollten habe ich
selbstverständlich angebracht)

[1] http://board.protecus.de/t3305.htm (Gesamte Liste)

Es geht zB um die Seite www.cyberport.de oder www.autobild.de

Für euer Ohr dankend :-)

Bye Tom

[Ralph Böhme]

Post by Thomas Wildgruber
ich versuche gerade im HDS-Forum ein Problem mit Snow Leopard zu debuggen,
wo einige Internetseiten nicht angezeigt werden können.

Nicht dass das wirklich mein Metier wäre, aber wenn ich Probleme habe dass
bestimmte Seiten nicht gehe, prüfen ich ob meine herabgesetzte MTU noch
herabgesetzt ist. Alternativ wäre woh MSS clamping am Router eine
Möglichkeit, aber bei meinem altem Cisco war ich jedesmal zu faul die Doku
zu wälzen und bei meinem jetzigen Provider gestellten gibt es die Option
nicht.
Irgendeiner auf der Strecke von der Seite _zu_ dir, vermutlich dein
Provider wenn er die Pakte durchs DSLöhr drücken will und feststellt,
dass das nicht passt, verschickt entweder keine entsprechenden ICMP
Pakete ("fragmentation needed and DF set") oder auf dem Rückweg
zum Hoster werden diese ICMP Pakte nicht durchgelassen (oder beim
Hoster werden die vom TCP Stack nicht entsprechend verarbeitet?).

Liest jemand mit mehr Ahnung von dem Kram mit und kann das ggfls.
korrigieren oder ergänzen?

Post by Thomas Wildgruber
Für euer Ohr dankend :-)

Nix! Mein Ohr behalt ich. ;)

Gruß Ralph

[Thomas Wildgruber]

Post by Ralph Böhme

Post by Thomas Wildgruber
ich versuche gerade im HDS-Forum ein Problem mit Snow Leopard zu debuggen,
wo einige Internetseiten nicht angezeigt werden können.

Nicht dass das wirklich mein Metier wäre, aber wenn ich Probleme habe dass
bestimmte Seiten nicht gehe, prüfen ich ob meine herabgesetzte MTU noch
herabgesetzt ist.

Das gute alte MTU Problem, ich dachte das sei mit Windows 98 und den Einzug
der DSL Router gestorben.

Post by Ralph Böhme
Alternativ wäre woh MSS clamping am Router eine
Möglichkeit, aber bei meinem altem Cisco war ich jedesmal zu faul die Doku
zu wälzen und bei meinem jetzigen Provider gestellten gibt es die Option
nicht.

Was die OPs für Router haben entzieht sich jetzt meiner Kenntniss aber MSS
Clamping ist mir ein völlig neuer Begriff.

Post by Ralph Böhme
Irgendeiner auf der Strecke von der Seite _zu_ dir, vermutlich dein
Provider wenn er die Pakte durchs DSLöhr drücken will und feststellt,
dass das nicht passt, verschickt entweder keine entsprechenden ICMP
Pakete ("fragmentation needed and DF set") oder auf dem Rückweg
zum Hoster werden diese ICMP Pakte nicht durchgelassen (oder beim
Hoster werden die vom TCP Stack nicht entsprechend verarbeitet?).

Hm, das MTU Troubleshooting ist lange her. Was hat man damals gleich wieder
gemacht? Einen Ping mit einer Paketgrösse grösser oder kleiner 1500 Byte
gesendet? Muss ich mal nachdenken, ist noch früh am Morgen,

Fazit: An das MTU Problem dachte ich tatsächlich gestern auch schon mal,
die Symptome waren ganz ähnlich aber ich dachte es waren damals nur Rechner
betroffen, die direkt mit DSL Modem am Internet hingen und die Router haben
dann passend fragmentiert. Naja, schaun ma mal...

Thx & Bye Tom

[Ralph Böhme]

Post by Thomas Wildgruber
Hm, das MTU Troubleshooting ist lange her. Was hat man damals gleich wieder
gemacht?

Ich habe das wie gesagt gemacht indem ich an einem Client die MTU einfach
mal auf bspw. 1400 gesetzt habe. Wenns dann ging evtl. langsam hochtasten.

Gruß Ralph

[Thomas Wildgruber]

Post by Ralph Böhme

Post by Thomas Wildgruber
Hm, das MTU Troubleshooting ist lange her. Was hat man damals gleich wieder
gemacht?

Ich habe das wie gesagt gemacht indem ich an einem Client die MTU einfach
mal auf bspw. 1400 gesetzt habe. Wenns dann ging evtl. langsam hochtasten.

Jupp das weis ich schon noch, 8 Bit musste man damals mindestens für den
DSL Header abziehen. Immer ein Vielfaches von 8 oder so aber ich meinte das
herauszufinden?

Da gabs doch einen Ping Befehl, der das ganze als MTU Problem festgestellt
hat. Sowas wie 'ping -l 1500 -f www.google.de' (sendet ein Paket mit 1500
Byte Länge und darf nicht fragmentiert werden) das ganze dann solang mit
Vielfachen von 8 herabsetzen bis der Ping beantwortet wird; dann hat man
den Wert der geringsten MTU auf der Strecke ermittelt ... oder sowas in der
Art. Sollte es das tatsächlich noch geben?

Thx & Bye Tom

[Ralph Böhme]

Post by Thomas Wildgruber

Post by Ralph Böhme

Post by Thomas Wildgruber
Hm, das MTU Troubleshooting ist lange her. Was hat man damals gleich wieder
gemacht?

Ich habe das wie gesagt gemacht indem ich an einem Client die MTU einfach
mal auf bspw. 1400 gesetzt habe. Wenns dann ging evtl. langsam hochtasten.

Jupp das weis ich schon noch, 8 Bit musste man damals mindestens für den
DSL Header abziehen. Immer ein Vielfaches von 8 oder so aber ich meinte das
herauszufinden?
Da gabs doch einen Ping Befehl, der das ganze als MTU Problem festgestellt
hat. Sowas wie 'ping -l 1500 -f www.google.de' (sendet ein Paket mit 1500
Byte Länge und darf nicht fragmentiert werden) das ganze dann solang mit
Vielfachen von 8 herabsetzen bis der Ping beantwortet wird; dann hat man
den Wert der geringsten MTU auf der Strecke ermittelt ... oder sowas in der
Art.

Ich denke so kommst du nicht weiter, da nicht die Pakete die du schickst das
Problem sind, sondern die die du erhälst, bzw. eben nicht erhälst.

Wenn hier keiner von den Netzwerk-Spezis drauf anspringt, evtl. mal in
einer passenderen Gruppe fragen. Und dann hier berichten.

Gruß Ralph

[Thomas Wildgruber]

Post by Ralph Böhme

Post by Thomas Wildgruber
Da gabs doch einen Ping Befehl, der das ganze als MTU Problem festgestellt
hat. Sowas wie 'ping -l 1500 -f www.google.de' (sendet ein Paket mit 1500
Byte Länge und darf nicht fragmentiert werden) das ganze dann solang mit
Vielfachen von 8 herabsetzen bis der Ping beantwortet wird; dann hat man
den Wert der geringsten MTU auf der Strecke ermittelt ... oder sowas in der
Art.

Ich denke so kommst du nicht weiter, da nicht die Pakete die du schickst das
Problem sind, sondern die die du erhälst, bzw. eben nicht erhälst.

Doch glaub ich schon, so war das damals. Den ermittelten Wert musst du
natürlich noch in die Interfacekonfiguration eintragen. Ich hab da mal im
Internet gegraben und die Sache dämmert mir langsam wieder. Path MTU
Discovery soll über ICMP den Router mit der niedrigsten MTU ermitteln und
an den sendenden Host zurücksenden. Wenn jetzt irgendwo ICMP deaktiviert
wurde, kommen diese Status-Meldungen nicht an.

Das ganze ließe sich auch furchtbar einfach ausprobieren -> 'sudo ifconfig
en0 mtu 1472' nicht mal ein Neustart ist erforderlich und schauen obs
klappt. Wenn Ja, dann müsste man es noch in ein Konfigfile eintragen. Warum
zum Teufel habe ich diese Möglichkeit gestern Abend bereits nach wenigen
Millisekunden wieder verworfen? Danke jedenfalls :-) Aber meine Versuche
das herauszufinden versanden alledrings im HDS Forum derzeit, da herrscht
im Moment Funkstille. Warten wir mal ab, vielleicht tut sich heute Abend
noch mal was, mein Problem ist es ja nicht...

Thx & Bye Tom

[Daniel Krebs]

Post by Thomas Wildgruber
Path MTU
Discovery soll über ICMP den Router mit der niedrigsten MTU ermitteln und
an den sendenden Host zurücksenden. Wenn jetzt irgendwo ICMP deaktiviert
wurde, kommen diese Status-Meldungen nicht an.

Genauer: ICMP Typ 3
Falls es wirklich ein PMTUD Problem ist, würde mich mal interessieren,
welcher Provider das ist.
Es kann sich natürlich auch um einen Konfigurationsfehler auf einem der
lokalen Router handeln, womit wir fast On Topic wären.
Daniel

[Thomas Wildgruber]

Post by Daniel Krebs

Post by Thomas Wildgruber
Path MTU
Discovery soll über ICMP den Router mit der niedrigsten MTU ermitteln und
an den sendenden Host zurücksenden. Wenn jetzt irgendwo ICMP deaktiviert
wurde, kommen diese Status-Meldungen nicht an.

[...]
Es kann sich natürlich auch um einen Konfigurationsfehler auf einem der
lokalen Router handeln,

Oder das aber ich warte noch auf das Resultat einer verringerten MTU bei
diesem Poster. Das geht alles etwas zäh voran. Haufenweise Postings aber
auf meine Rückfragen gibts nur verhalten Antworten aber sie sind noch dran,
wird also noch werden. Der Provider in diesem Fall ist T-Online.

Post by Daniel Krebs
womit wir fast On Topic wären.

Um gänzlich On Topic zu werden, stellt sich das Problem des eigentlichen
OPs als wirklich hartnäckig dar. Der hat selbes Fehlerbild allerdings im
Netzwerk noch eine Windows 7 Maschine, die problemlos funktioniert. Da
scheint ein MTU, Router und Provider Problem unwahrscheinlich. Da liegts
wohl wirklich am Snow Leoparden SP2.

Wo setzt man im SL das Netzwerksubsystem zurück? Ich hab jetzt in meiner
Installation mal die:

cd /Library/Preferences/SystemConfiguration/
NetworkInterfaces.plist
com.apple.network.identification.plist
preferences.plist

...in die Tonne getreten und hatte zumindest mal wieder meine restlichen
Interfaces aktiv, die ich deaktiviert hatte, IPv6 war wieder aktiviert,
Hostname zurückgesetzt etc. Tja, was soll ich sagen, ich kann es jetzt
schlecht abschätzen, ich hatte vorher ja auch kein Problem. Gibts da sowas
wie eine Best Practice Empfehlung um den ganzen Netzwerkzenober zu
resetten?

Bye Tom

[Thomas Kosch]

Post by Thomas Wildgruber
Um gänzlich On Topic zu werden, stellt sich das Problem des eigentlichen
OPs als wirklich hartnäckig dar. Der hat selbes Fehlerbild allerdings im
Netzwerk noch eine Windows 7 Maschine, die problemlos funktioniert. Da
scheint ein MTU, Router und Provider Problem unwahrscheinlich. Da liegts

Nicht zwingend. Bei Windows gibt es eine sogenannte Blackhole Router
Detection.

http://support.microsoft.com/kb/925280

ttyl8er, t.k.

[Daniel K®ebs]

Post by Thomas Kosch
Nicht zwingend. Bei Windows gibt es eine sogenannte Blackhole Router
Detection.
http://support.microsoft.com/kb/925280

Danke!
Sollte man im Hinterkopf behalten.
Daniel

[Thomas (Pronto) Wildgruber]

Post by Daniel K®ebs

Post by Thomas Kosch
Nicht zwingend. Bei Windows gibt es eine sogenannte Blackhole Router
Detection.
http://support.microsoft.com/kb/925280

Danke!
Sollte man im Hinterkopf behalten.

Auf jeden Fall...

Thx & Bye Tom

[Helmut Hullen]

Hallo, Thomas,

Post by Thomas Wildgruber

Post by Thomas Wildgruber
Hm, das MTU Troubleshooting ist lange her. Was hat man damals
gleich wieder gemacht?

[...]

Post by Thomas Wildgruber
Da gabs doch einen Ping Befehl, der das ganze als MTU Problem
festgestellt hat. Sowas wie 'ping -l 1500 -f www.google.de' (sendet
ein Paket mit 1500 Byte Länge und darf nicht fragmentiert werden) das
ganze dann solang mit Vielfachen von 8 herabsetzen bis der Ping
beantwortet wird; dann hat man den Wert der geringsten MTU auf der
Strecke ermittelt ... oder sowas in der Art. Sollte es das
tatsächlich noch geben?

Habe ich eben mal ausprobiert, von meinem Rechner an dessen aktuelle
(weltweite) DynDNS-Adresse (bei KabelDeutschland).

Der Befehl muss anscheinend "Ctrl C" abgebrochen werden, er zeigt sowohl
für 1500 wie auch für 1404 etwa 25% Paketverlust an.

Wenn ich heise.de anpinge: 90% Verluste.

Was lehrt mich das?

Viele Gruesse!
Helmut