Fritzbox Fon 7050 dropped Pakete - Bestimme Server nicht erreichbar

[neuntoeter]

Hallo,
sorry für das lange Posting aber das Problem ist sehr verzwickt.
ich habe ein kurioses Problem mit der Fritzbox 7050 (14.04.03-3452 Problem tritt auch mit anderen Versionen auf).
Bestimmte Webserver im Internet z.B.:
84.16.238.146
84.16.238.147 (neuntoeter.homelinux.org)
84.16.238.148

schicken Antwort Pakete (z.B. Http-Redirects), die von der Fritzbox 7050 einfach gedropped werden und nie an meinem Rechner ankommen. Ich habe den Netzwerkverkehr mitgeschnitten (mit: http://fritz.box/cgi-bin/webcm?getpage=../html/capture.html ). Dabei sieht man, dass die Pakete beim "Paketmitschnitt auf DSL-Ebene" noch ankommen, bei "Paketmitschnitt ohne DSL-Rahmen" und mit tcpdump auf meinem Linux Rechner sieht man diese Pakete allerdings nicht (keine Firewall aktiv). Es werden nicht alle Pakete gedropped, die Server sind z.B. anpingbar - Es werden allerdings entscheidende Pakete für den Aufbau von SSH oder HTTP Verbindungen gedropped.

Der Witz dabei ist, dass die oben genannten Webserver unterschiedliche Pakete zurückschicken, je nachdem ob ich Windows verwende oder Linux. Als Folge dessen kann ich über Windows auf meinen Webserver mit SSH und Browser zugreifen, mit Linux allerdings nicht. Getestet mit unterschiedlichen Rechner (daheim, im Geschäft) und Suse 10 / Knoppix 3.2.

Ich habe mir die Paket Mitschnitte der Fritz-Box genauer angesehen.
Folgende Pakete gehen bei einem HTTP Request zu den o.g. Webservern über die Fritzbox rein und raus:
FRITZ = von / zur Fritzbox
REMOTE = von / zu Remote Host

FRITZ->REMOTE (Syn Paket)
REMOTE->FRITZ (Syn, Ack Paket)
FRITZ->REMOTE (Ack Packet)
FRITZ->REMOTE (Http Get)
REMOTE->FRITZ (Ack)
(soweit sind die Pakete bei windows und linux mehr oder wenig identisch.
Das
nächste Paket ist entscheidend
REMOTE->FRITZ (HTTP/1.1 302 Found)

Dieses Paket unterscheidet sich je nachdem ob ich Linux oder Windows
verwende.
Ethereal sagt das dieses Paket unbekannte TCP Options enthält:
Options: (12 bytes): Unknown (0x58) (Option length = 213 bytes says option
goes past end of options)

Dies ist allerdings nur der Fall wenn ich Linux verwende (die Pakete des
Remote Hosts unterscheiden sich also je nachdem welches OS ich verwende).
Ich vermute, dass die Fritz-Box dieses Paket dann aufgrund dieser
TCP-Options dropped, da es nie an dem angeschlossenen rechner ankommt. Dies ist ziemlich ärgerlich.

Könnt Ihr vielleicht versuchen, dass Problem nachzustellen, falls Ihr auch eine Fritzbox 7050 habt (oder evtl. auch eine andere)??

Kommt ihr mit einem Linux Rechner auf http://neuntoeter.homelinux.org, könnt ihr eine ssh Verbindung starten? Verhält es sich mit Windows genauso?

Der Support von AVM konnte mir bisher nicht wirklich helfen ("Versuchen, sie doch einen anderen Browser").

Grüße,

Volker

 

[frank_m24]

Hallo,

ja, ich kann das Problem voll bestätigen.

Unter Windows XP kann ich die Seite mit Firefox 1.5.0.2 aufrufen und auch eine SSH Verbindung (cygwin) aufbauen.

Unter Gentoo Linux (Kernel 2.6.16-gentoo-r4), ebenfalls Firefox 1.5.0.2, wird weder die Internetseite angezeigt noch die SSH Verbidnug aufgebaut.

Sehr merkwürdig.

Viele Grüße

Frank

 

[neuntoeter]

Hallo,

vielen Dank für die prompte Antwort!
Ich habe schon vermutet, dass andere das Problem nachstellen können - Ich habe es ja auch an verschiedenen Systemen testen können.

Achso, hatte ich im ersten Posting vergessen: Der Webserver neuntoeter.homelinux.org ist ein virtueller (vServer) mit Debian.

Ich werde einen Link auf diesen Thread in den nächsten Tagen sowohl zum AVM-Support als auch zum Support meines Web-Hosters schicken. Vielleicht nehmen sie dann das Problem etwas ernster.

Hat jemand ähnliche Probleme schon einmal mit anderen Seiten beobachten können?

Grüße,

Volker Maibaum

 

[Matze_bhv]

Habt ihr die korrekte MTU-Size? Kann bei Linux hinter nem DSL-Router schon mal in die Hose gehen, dann kommen genau solche Effekte zustande.

http://www.tecchannel.de/netzwerk/management/429773/index2.html

Matze

 

[frank_m24]

Hallo,

Habt ihr die korrekte MTU-Size?

Also bei mir ist es sowohl unter Windows als auch unter Linux 1492 Byte, überprüft unter www.speedguide.net.

Viele Grüße

Frank

 

[gandalf94305]

Der Tip mit der MTU-Size war vielleicht schon der richtige, denn wenn Linux und Windows verschiedene TCP-Options schicken (z.B. der eine Don't Fragment, der andere nicht), jedoch eine Fragmentierung notwendig ist, dann kommen die Antwortpakete des einen an, des anderen nicht. Es kann auch sein, daß Windows MTU-Discovery aktiviert hat (default) und Linux nicht.

Ich würde also auch mal empfehlen, die MTU-Size von 1492 auf 1440 zu setzen und zu schauen, was passiert.

--gandalf.

 

[neuntoeter]

Hallo,

Danke für den Tipp mit der MTU size, aber daran liegt es nicht.
Ich habe es mit verschiedenen MTU sizes probiert:
1500, 1492, 1440 und noch kleiner...

Übrigens wenn ich Windows auf VMware unter Linux laufen lasse, habe ich das Problem auch nicht...

Volker

 

[drping]

Hallo,
sorry für das lange Posting aber das Problem ist sehr verzwickt.
ich habe ein kurioses Problem mit der Fritzbox 7050 (14.04.03-3452 Problem tritt auch mit anderen Versionen auf).
Bestimmte Webserver im Internet z.B.:
84.16.238.146
84.16.238.147 (neuntoeter.homelinux.org)
84.16.238.148

schicken Antwort Pakete (z.B. Http-Redirects), die von der Fritzbox 7050 einfach gedropped werden und nie an meinem Rechner ankommen.

Kann das Problem nicht bestätigen.Alle obigen Adressen sind erreichbar mit meinem Windows XP sowohl mit IE als auch mit Firefox.

 

[gandalf94305]

Ähem...

Kann das Problem nicht bestätigen.Alle obigen Adressen sind erreichbar mit meinem Windows XP sowohl mit IE als auch mit Firefox.

und hier noch

Dies ist allerdings nur der Fall wenn ich Linux verwende

Guten Morgen! ;-)

 

[drping]

Guten Morgen! ;-)

Dir auch-hatte noch keinen Kaffee-doch was ist das??

Kommt ihr mit einem Linux Rechner auf http://neuntoeter.homelinux.org, könnt ihr eine ssh Verbindung starten? Verhält es sich mit Windows genauso?

wollte nur helfen-aber ich lege mich wieder hin.

 

[gandalf94305]

wollte nur helfen-aber ich lege mich wieder hin.

Mein Frühstück ist gerade vorbei ;-) Sorry, so war das nicht gemeint...

--gandalf.

 

[neuntoeter]

support

Hallo,

ich habe einen Link auf diesen Thread nun an den Support meines Hosters und den Support von AVM weitergeleitet.

Bin mal gespannt, ob und was zurückkommt.

Volker

 

[buckyballplayer]

Danke für den Tipp mit der MTU size, aber daran liegt es nicht.
Ich habe es mit verschiedenen MTU sizes probiert:
1500, 1492, 1440 und noch kleiner...

Übrigens wenn ich Windows auf VMware unter Linux laufen lasse, habe ich das Problem auch nicht...

Also beim MTU Wert nicht kleckern sondern klotzen mit 500 testen, wenns da geht kann man sich ja wieder hochtasten.

Ob Windows da wieder mal auf Kundenfreundlich eingestellt ist und evtl. die umgepackten Pakete als gültig zulässt, wogegen Linux sich an die nicht mehr orginalen "Sicheren Pakete" stört?

 

[neuntoeter]

MTU size

Hallo,
habs gerade mit MTU 500 probiert - geht trotzdem nicht.
Kann sich evtl. jemand einen Netzwerkmitschnitt etwas genauer anschauen, der sich gut damit auskennt?
Ich bin wirklich kein Fachmann was Netzwerk-Protokolle angeht.

Ich hab nur mal mit ethereal die Fritz-Box Mitschnitte angesehen und da ist mir halt aufgefallen, dass ethereal die TCP-Option bei bestimmten Paketen anmosert.
Vielleicht ist das aber auch eine ganz normale Meldung? - Hab leider bisher viel zu wenig mit ethereal & Co. gemacht.

Ich kann die Mitschnitte auch gerne zumailen.

Volker

 

[neuntoeter]

Ob Windows da wieder mal auf Kundenfreundlich eingestellt ist und evtl. die umgepackten Pakete als gültig zulässt, wogegen Linux sich an die nicht mehr orginalen "Sicheren Pakete" stört?

Also das Problem ist ja, dass die Pakete erst gar nicht am Linux ankommen.
Bei einem TCP-Dump sehe ich das entscheidende Paket erst gar nicht (auch keine dropped Pakete). Und bei einem Paket-Mitschnitt auf der Fritzbox zeigt sich, dass das Paket zwar auf der Fritzbox ankommt (Paketmitschnitt auf DSL-Ebene) von der Fritzbox aber gar nicht an meinen Rechner geschickt wird (Paketmitschnitt ohne DSL-Rahmen).

Volker

 

[buglwock]

Ich habe das gerade auch mal ausprobiert, per HTTP an neuntoeter.homelinux.org. Das Problem mit der Antwort ist, das im TCP-Optionsfeld keine Optionen stehen, sondern (in meinem Fall) der Text "ko/20060502", der zufällig aus der Zeile "User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20060205 Debian/1.7.12-1.1" des HTTP-Requests zu stammen scheint. Eventuell bemerkt die Fritzbox ja bei Port-Umsetzung (NAT) diesen Quatsch und verwirft das Paket. Die Frage ist, wo der Quatsch herkommt. Er muss ja vom Kernel Deines Servers erzeugt worden sein.

Da das bei Windows-Clients anscheinend nicht passiert, wo die Options beim SYN evtl. anders sind, habe ich mal versucht, die Options einzeln abzuschalten. Und siehe da, ohne timestamping-Option funktioniert es (abzuschalten durch "echo 0 >/proc/sys/net/ipv4/tcp_timestamps" auf dem Client). Also scheint Dein Kernel wohl einen Bug beim Zeitstempeln zu haben.

Ich habe kurz gesucht, ob es da einen bekannten Bug im Linux-Kern gibt, habe aber auf Anhieb nichts gefunden. Du könntest ja mal versuchen, ob es mit einem 2.6er Kernel auf dem Server anders ist (falls xprobe2 richtig erraten hat, dass dort ein 2.4er läuft). Oder ob es was hilft, tcp_timestamps auf dem Server auszuschalten. Der ultimative (wenn auch vielleicht ultimativ zeitaufwändige) Weg wäre ein Blick in den Quellcode ... Welche Kernel-Version läuft denn genau auf neuntoeter?

 

[neuntoeter]

Kernel Version

Hallo,

Danke für Deine ausführliche Untersuchung des Problems.
Der Tipp mit dem Ausschalten der Timestamps (echo 0 >/proc/sys/net/ipv4/tcp_timestamps) ist Gold wert. Ich komme wieder drauf. Jetzt muss ich nur noch allen potentiellen Besuchern meiner Seite eine Email schreiben und sie darauf hinweisen (ist natürlich nur ein Witz).

Ich habe leider auf dem vServer eingeschränkte root-Rechte:
vs8622:/proc/sys/net/ipv4# echo 0 > tcp_timestamps
-bash: tcp_timestamps: Permission denied

Der Kernel ist: Linux vs8622 2.4.24-vs1.26 #11 Sat Mar 5 12:14:30 CET 2005 i686 GNU/Linux

Ich könnte den Hoster mal fragen, ob er die tcp_timestamps auschalten kann.

Weißt du, welche Auswirkungen dies hat? Könnten dadurch andere Probleme auftreten?

Vielen Dank nochmal!

Grüße,

Volker

 

[neuntoeter]

2.6er Kernel

zur Ergänzung noch:

Du könntest ja mal versuchen, ob es mit einem 2.6er Kernel auf dem Server anders ist (falls xprobe2 richtig erraten hat, dass dort ein 2.4er läuft).

Leider kann ich nicht einfach einen anderen Kernel installieren/booten. Ich nehme an, dass alle Gast Linux-Systeme auf dem vServer den gleichen Kernel fahren müssen und wegen meinem System wird da wohl kaum ein update durchgeführt.

Grüße,

Volker

 

[buglwock]

Ich denke, es wird nicht schaden, das Timestamping auszuschalten. Es handelt sich um eine Optimierung, auf die man auch verzichten kann. Wie sich das Ausschalten genau auswirkt, kommt sicher auch auf die Anwendung an; vermutlich stört es eher bei umfangreichen Datenübertragungen als bei den meist kurzen Zugriffen auf einen Web-Server. Jedenfalls scheint Windows ja standardmäßig kein Timestamping zu machen. Und wenn das Verhalten der Servers in der Praxis tatsächlich so buggy ist, wie es aussieht (Nutzdatenfragmente im TCP-Optionsfeld) dann ist das Abschalten das einzig Richtige (am besten gleich auf allen Servern mit diesem Kernel).

Sicherheitshalber würde ich aber vor der Beschwerde beim Hoster nochmal auf dem Server einen Paketmitschnitt machen und nachsehen, ob die falschen Optionen auch wirklich dort erzeugt werden.

 

[neuntoeter]

tcp-timestamps testweise abgeschaltet

Hallo,

einen Paketmitschnitt kann ich leider wegen eingeschränkten Rechten nicht durchführen.

Mein Webhoster hat aber dankenswerterweise testweise das TCP-timestamping abgeschaltet.
Ich werde es heute abend oder morgen früh testen.

Grüße,

Volker