FBF 7170 - Paket Verlust auf LAN Seite ab 974 Bytes Paketgröße

viper6666

Neuer User
Mitglied seit
26 Jun 2007
Beiträge
21
Punkte für Reaktionen
0
Punkte
1
Hallo @all!

Irgendwie habe ich mit meiner neuen FB mehr Probleme als mir lieb ist. :mad:

Ich benutze u.a. eine VPN Lösung von NCP um mich in meine Firma einzuloggen.
Seid dem ich die FB habe geht dies jedoch nicht mehr.
Das login bleibt bei der Zertifikatsprüfung hängen und bricht die Einwahl ab.
Nachdem ich bei NCP nachgefragt habe, hat man mir folgendes mitgeteilt:
Hallo Herr ....,
der Client schickt sein Zertifikat zum Server welches da aber nie ankommt und deshalb auch nicht antworten kann.
Mögliche Ursache: Das Zertifikat ist > 1500 Bytes und muss fragmentiert werden. Wahrscheinlich liegt ein Router dazwischen der fragmentierte Pakete verwirft.
Mit dem gleichen Rechner und einem anderen Router funktioniert es auch tadellos. Also scheint das was NCP sagt möglicherweise zu stimmen.

Um es nach zu vollziehen habe ich versucht herauszufinden ab wann meine FBF die Pakete verwirft.
Also folgender Ping vom Client abgesetzt: (LAN Verbindung auf Switchport 1)
-l 1000 = Aktuelle Paketgröße in bytes die der Ping an das Ziel sendet.

C:\Windows>ping -l 1000 192.168.178.1

Ping wird ausgeführt für 192.168.178.1 mit 1000 Bytes Daten:

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

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

Ups... OK, hab mich eben rangetastet bis ich eine Ping antwort bekommen aben. Dies lag dann bei 973 bytes.

Was mich jedoch sehr irritiert...
Das LAN Interface der FB zeigt mir bei einem ifconfig das die MTU auf 1500 ist.
Also dürfte hier nix fragmentiert werden bei 974 bytes.
Der Befehl "ping -f -l 1000 192.168.178.1" bestätigte dies auch, da keine Meldung kam das die Pakete fragmentiert werden müssen (Parameter -f)

Ich habe den Rechner nun noch an das WLAN angeschlossen und die gleichen Tests nochmal durchgeführt.

C:\Windows>ping -l 1000 192.168.178.1

Ping wird ausgeführt für 192.168.178.1 mit 973 Bytes Daten:

Antwort von 192.168.178.1: Bytes=1000 Zeit=1ms TTL=64
Antwort von 192.168.178.1: Bytes=1000 Zeit=1ms TTL=64
Antwort von 192.168.178.1: Bytes=1000 Zeit=1ms TTL=64
Antwort von 192.168.178.1: Bytes=1000 Zeit=1ms TTL=64

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

Uuuuui! Das funktioniert ja!
Auch der Test mit meiner VPN Applikation war erfolgreich.

Scheint also irgend etwas mit dem Switch nicht so ganz zu stimmen.

Hier muss ich mich auch nochmal an meine zwei Probleme die ich vor kurzem hier gepostet habe (Recovery Probleme und Videoserver funzt nicht) erinnern. Das hängt wohl alles unmittelbar zusammen.
Denn wenn ich beide Dinge über einen extern angeschlossenen Switch an der FB durchführe habe ich die geposteten Probleme nicht.

Meine Frage nun an Euch...

Wer kann das bei seiner FB ebenso nachvollziehen oder hat die gleichen Probleme mit solchen Paketverlusten ab einer gewissen Bytezahl auf der LAN Schnittstelle?
Vieleicht testet ihr es einfach mal. Denn beim Surfen bemerkt man dies gar nicht. Und evt hat Eure Box ja auch nen "Knax".

Oder wenn jemand eine Lösung zu diesem Problem kennt habe ich natürlich ein ganz großes offenes Ohr.

P.S. Problem besteht unabhängig vom Einsatz einer ds-mod Firmware!

Gruß
viper6666
 
Die Box bietet eine Trace-Funktion ( http://fritz.box/html/capture.html ) wo man alle Schnittstellen separat tracen kann. Was kommt denn wie von den ICMP Pakten an und ist im Trace ggf. zusehen das die Box auf diese reagiert.

Mit Paketgrössen grösser 1500 zu arbeiten, ist aber auch recht merkwürdig ?!
 
@viper6666:
ich konnte hier bei mir ohne irgendwelche probleme meine box 7170 anpingen, mit größen bis 1472 bytes
Code:
C:\>ping 192.168.178.1 -l 1472 -f

Ping wird ausgeführt für 192.168.178.1 mit 1472 Bytes Daten:

Antwort von 192.168.178.1: Bytes=1472 Zeit=1ms TTL=64
Antwort von 192.168.178.1: Bytes=1472 Zeit=1ms TTL=64
Antwort von 192.168.178.1: Bytes=1472 Zeit=1ms TTL=64
Antwort von 192.168.178.1: Bytes=1472 Zeit=1ms TTL=64

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

ab 1743 ging dann aber nix mehr.

Code:
C:\>ping 192.168.178.1 -l 1473 -f

Ping wird ausgeführt für 192.168.178.1 mit 1473 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 192.168.178.1:
    Pakete: Gesendet = 4, Empfangen = 0, Verloren = 4 (100% Verlust),
Ca. Zeitangaben in Millisek.:
    Minimum = 0ms, Maximum =  0ms, Mittelwert =  0ms

falls dir das weiterhilft.

mfg
hans
 
Hans Mayer schrieb:
@viper6666:
ich konnte hier bei mir ohne irgendwelche probleme meine box 7170 anpingen, mit größen bis 1472 bytes
....

falls dir das weiterhilft.

mfg
hans

Jo, Danke!
Hilft bestimmt. Denn spätestens wenn ich bei AVM bzgl des Problems anfrage und die mich wieder mit nem Standard Antwort Template Mail abspeisen wollen und mir erklären, das ich den Fehler an meinen PC suchen soll.

Wäre toll wenn ich noch so einige Feedbacks in dieser Richtung bekäme.

Gruß
viper6666
 
@Hans Mayer

Noch ne Frage....
War Dein Rechner an der LAN Schnittstelle angeschlossen oder WLAN?
WLAN geht bei mir nähmlich auch.
 
Verpeiler schrieb:
Die Box bietet eine Trace-Funktion ( http://fritz.box/html/capture.html ) wo man alle Schnittstellen separat tracen kann. Was kommt denn wie von den ICMP Pakten an und ist im Trace ggf. zusehen das die Box auf diese reagiert.

OK, hab ich gemacht...
Ergebnis:
Bei einem Ping unter 974 bytes erhalte ich im Trace wunderbar die requests und die replays der ICMP Pakete.

Bei einem Ping ab 974 bytes zeigt er mir weder einen request und demnach auch kein replay. Noch nicht einmal was mit dem Paket passiert (drop, etc)

Ich habe danach mit Wireshark auch mal meinen PC mit geloggt.
Auf der PC Seite geht das Paket definitiv raus. An der FB kommt es aber nicht an - ODER - der eingebaute trace Mechanissmus verheimlich auch ganz einfach verworfene Pakete.

Was mir noch aufgefallen ist, das beim Reboot der FB ca. 4 - 5 Pings plötzlich beantwortet werden. Offensichtlich scheint also nicht ganz die Hardware, sondern irgend ein Programm auf der FB Schuld zu sein.
Hmmmmmmmm.... :noidea:
 
Hi viper6666,

entferne mal den Siemens Router aus dem LAN und führe ein Recover der Firmware durch, dann alle Daten per Hand eingeben. Eventuell liegt der Fehler im DS-Mod.

Gruß
fbfuser
 
@viper6666:
natürlich vom LAN aus, sonst hätte ich es ja eigentlich nicht posten müssen, weil das mit WLAN bei dir ja auch ging.
WLAN hab ich nicht getestet, mangels eines solchen.

mfg
hans
 
Wäre noch die Frage (wenn ich es nicht überlesen habe) wie sich der Switch verhält, wenn sich andere Geräte im LAN mit großen Paketen anpingen wollen, also geht ein Ping von PC1 an PC2 über den Switch hinweg?
Denn ich sähe zwei Möglichkeiten: Der Switch ist "verkonfiguriert" oder der Pufferspeicher für die Ethernetframes hat 'ne Macke, dann würde vermutlich auch der Ping "durch den Switch" nicht gehen...

Jörg
 
fbfuser schrieb:
Hi viper6666,

entferne mal den Siemens Router aus dem LAN und führe ein Recover der Firmware durch, dann alle Daten per Hand eingeben. Eventuell liegt der Fehler im DS-Mod.

Gruß
fbfuser

Ohne den Siemend Router kann ich kein Recovery machen -> Grund

Aber selbst nach erfolgreichem Recovery und OHNE irgendwelche Daten einzugeben (Also Auslieferungszustand) ist das gleiche Ergebnis mit dem Paketverlust da.
 
MaxMuster schrieb:
Wäre noch die Frage (wenn ich es nicht überlesen habe) wie sich der Switch verhält, wenn sich andere Geräte im LAN mit großen Paketen anpingen wollen, also geht ein Ping von PC1 an PC2 über den Switch hinweg?
Denn ich sähe zwei Möglichkeiten: Der Switch ist "verkonfiguriert" oder der Pufferspeicher für die Ethernetframes hat 'ne Macke, dann würde vermutlich auch der Ping "durch den Switch" nicht gehen...

Jörg

OK, folgende Systeme sind an der FB direkt angeschlossen.

LAN1 = PC mit Windows Vista (192.168.178.10)
LAN2 = Convision Viderserver V600 (192.168.178.5)
LAN3 = HP Laserdrucken mit einer JetDirect Karte (192.168.178.2)
LAN4 = PC mit Windows XP SP2 (192.168.178.70)
WLAN = Als Repeater ein Siemens Gigaset SE505 (192.168.178.200)

Und so sieht es mit den Pings aus... (Jeweils von 192.168.178.10 abgesendet)

LAN1 <-> FBF : Max Paketgröße = 973
LAN1 <-> LAN2 : Max Paketgröße = 1224
LAN1 <-> LAN3 : Max Paketgröße = 1472
LAN1 <-> LAN4 : Max Paketgröße = über 2048
LAN1 <-> Repeater : Max Paketgröße = 973

UND

LAN1 <-> www.gmx.de : Max Paketgröße = 973
LAN1 <-> www.web.de : Max Paketgröße = 973
LAN1 <-> www.goggle.de : Max Paketgröße = 973

Gruß
viper6666
 
Tja, dann scheint es ja tatsächlich nur alles zu sein, was "in" die Box geht. Da würde ich tatsächlich mal an AVM herantreten.

Jörg
 
So, nun hab ich die Box im Auslieferungsstand und werd dann wohl mal einen Call bei AVM eröffnen.

Hoffe dann bald ein Ergebnis hier posten zu können.

Danke dennoch für die reichliche Unterstützung! :lol:

Gruß
viper6666
 
Kurzer Zwichenstatus:

Nach sehr langer e-mail Kommunikation mit AVM hat der Support sich nun endlich entschieden mir ein Austauschgerät zukommen zu lassen.

Ich bin mal gespannt!!! :gruebel:
Werd mich dann nochmal melden.

Gruß
viper6666
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.