1781VA mit Paketverlust an xDSL-Anschlüssen der Telekom

[fildercom]

Danke @cpuprofi für deine Hilfe!

Haben sie auch Angaben gemacht, mit welcher Version bzw. in welchem Versionszweig das Fehlverhalten behoben wird?

[cpuprofi]

Hallo Fildercom,

Haben sie auch Angaben gemacht, mit welcher Version bzw. in welchem Versionszweig das Fehlverhalten behoben wird?

der Lancom-Support hat dazu folgendes geschrieben:

Sollte das Verhalten behoben sein, wird die Fehlerbehebung in einem nächsten Release oder Release Update enthalten sein. Einen konkreten Erscheinungstermin können wir Ihnen zum jetzigen Zeitpunkt leider noch nicht nennen.

Es ist wohl so, dass ab LCOS 10.40.0332 dieser Fehler behoben ist.

Grüße
Cpuprofi

[cpuprofi]

Hallo Jirka,

Das ist aber ganz schön allgemein ausgedrückt dafür, dass ja eben nur einige oder mitunter Echo-Requests nicht beantwortet wurden. Ebenfalls wurden keine Angaben gemacht, seit wann und in welcher Situation dieses Fehlverhalten auftritt.

auf meine weitere Nachfrage zu dem genauen Grund des Fehlverhalten und ob dieses sich vielleicht auch auf andere Pakete auswirken könnte (SIP, VPN, usw.) und warum das Fehlverhalten bei einem vorgeschalteten Modem (Kabel-Modem, Bridge-Mode) nicht auftrat bzw. im Thinkbroadband-Monitor (www.thinkbroadband.com) nicht so ersichtlich war, erhielt ich folgende Antwort vom Lancom-Support:

Hier könnte es auch sein, dass das Modem auf diese öffentliche Adresse Antwortet, je nach dem, was dies für ein Modem ist. Somit kommt das Packet nicht im LANCOM an und dieser agiert nicht falsch. Da das Problem nun gelöst ist, würde ich Sie bitten bei weiteren Problemen oder Fragen ein neues Ticket zu erstellen.

Dieses wird nun mit diesem Kommentar geschlossen.

...

Grüße
Cpuprofi

[backslash]

Hi Jirka,

Das ist aber ganz schön allgemein ausgedrückt dafür, dass ja eben nur einige oder mitunter Echo-Requests nicht beantwortet wurden. Ebenfalls wurden keine Angaben gemacht, seit wann und in welcher Situation dieses Fehlverhalten auftritt.

Damit der Fehler zutage tritt muß schon einiges zusammenkommen. Zum einen muß es ein ICMP-Paket sein, das keine "Nutzdaten" hat - wie bei den Pings des Montitors. Dann muß in dem Speicherbereich hinter dem ICMP-Header etwas stehen, daß als "embedded IP Header" einer ICMP-Fehlermeldung interpertiert wird - wegen der fehlenden Längenprüfung. Eine Möglichkeit wäre, daß in dem Speicher, in den das ping geschrieben wurde, vorher tatsächlich eine ICMP-Fehlermeldung lag. Und dann muß noch ein Maskierungseintrag existiert, der zum Quellport des UDP/TCP-Headers hinter dem embedded IP Header paßt, so daß die Maskierung sich genötigt fühlt, die Adresse zu überschreiben...

Und wenn nun jemand sagt, daß wäre dann ggf. eine Sicherheitslücke, dem sei gesagt, daß eine Maskierung kein Security-Feature darstellt und mann immer zusätzlich eine Firewall mit "Deny-All" Regel verwenden sollte - denn die Maskierung öffnte z.B. für UDP-Pakete den Quellport für *alle* entfernen Adressen und Ports - sonst würde STUN nicht funktionieren...

Gruß
Backslash

[Jirka]

Hallo Backslash,

wenn wir Dich nicht hätten - vielen herzlichen Dank für die detaillierten Infos. Beim Support hätte cpuprofi für eine Nachfrage zu diesem Problem offensichtlich ein weiteres Ticket erstellen müssen, was ja irgendwie etwas hirnrissig ist. (Zitat: "Da das Problem nun gelöst ist, würde ich Sie bitten bei weiteren Problemen oder Fragen ein neues Ticket zu erstellen.")

Damit der Fehler zutage tritt muß schon einiges zusammenkommen.

Das macht die Sache ja interessant und spannend...

Zum einen muß es ein ICMP-Paket sein, das keine "Nutzdaten" hat - wie bei den Pings des Montitors.

Oha, das ist schon mal heftig, da braucht man ja zum Problem nachstellen schon mal entsprechende Voraussetzungen, wie z. B. diesen Monitor. PRTG sendet z. B. glaube ich Pings mit Nutzdaten soweit ich mich erinnern kann (ich monitore ja nur im Ausnahmefall mal mit einem primitiven Ping, einen LANCOM eigentlich nie, der kann ja SNMP).
Das heißt aber unterm Strich auch (was ja eigentlich schon klar war, aber ich will es hier noch mal konkret schreiben), dass es eben keinen allgemeinen Paketverlust gab, sondern eben nur einige Pings nicht beantwortet/verschluckt wurden. Das ist zwar nicht schön, klar, aber im praktischen Betrieb ohne Auswirkungen, es sei denn man nutzt eben diesen Monitor und will mit den Ergebnissen was anfangen.

Dann muß in dem Speicherbereich hinter dem ICMP-Header etwas stehen, daß als "embedded IP Header" einer ICMP-Fehlermeldung interpertiert wird - wegen der fehlenden Längenprüfung.

Möglicherweise ist der Speicherbereich beim 1900EF größer und damit die Wahrscheinlichkeit geringer, dass es dort auftritt. Möglicherweise ist es aber auch so, dass es anfangs (nach Neustart) keinen Speicherbereich gab, wo schon etwas stand, denn später ist fildercom ja mit der Aussage, dass der 1900EF nicht betroffen sei, auch wieder zurückgerudert und meinte es sei dort dann auch aufgetreten.
Heißt also jeder LCOS-LANCOM ist betroffen und das schon seit unbestimmter Zeit.

Und dann muß noch ein Maskierungseintrag existieren, der zum Quellport des UDP/TCP-Headers hinter dem embedded IP Header paßt, so daß die Maskierung sich genötigt fühlt, die Adresse zu überschreiben...

Das wiederum kann auch erklären, warum der 1900EF bei fildercom weniger betroffen war, denn nach seinen Angaben wurde dieser Anschluss kaum genutzt. Und keine oder geringe Nutzung heißt weniger Maskierungseinträge.

Und wenn nun jemand sagt, daß wäre dann ggf. eine Sicherheitslücke

Na ja, das hat ja noch keiner gesagt. Und der Rest ist natürlich bekannt, wenn auch nicht immer umgesetzt...

Vielen Dank und viele Grüße,
Jirka

[fildercom]

Vielen Dank @ backslash und @ Jirka für eure Einschätzungen.

Die Sache mit 1781VA vs. 1900EF sieht momentan (LCOS 10.34 Rel, ohne Bugfix) so aus:

tbb.PNG

Der 1781VA hat den Paketverlust ständig. Der 1900EF ist zwar auch betroffen, man sieht den Paketverlust bei genauem Hinsehen ebenfalls, allerdings viel weniger stark ausgeprägt und nicht permanent, sondern nur zeitweise.

Dass nur leere ICMP-Pakete betroffen sein sollen muss ich jetzt erst mal so akzeptieren. Allerdings stelle ich momentan auch beim SIP bzw. genauer gesagt beim RTP seltsame Effekte fest: Bei eingehenden und ausgehenden Anrufen über den 1781VA beginnt das Gespräch laut Endgerät bereits, während ich das Gegenüber noch nicht höre und er mich auch nicht hört. Erst nach einem kurzen Moment ("Hallo") werden die Audio-Daten (also RTP) übertragen. Der 1900EF hat dieses Phänomen nicht. Beide Router sind auf derselben Telekom-Plattform und der VCM ist identisch konfiguriert. Die Ursache für dieses (Fehl-)Verhalten ist mir weiterhin unklar...

[cpuprofi]

Hallo Fildercom,

Der 1781VA hat den Paketverlust ständig. Der 1900EF ist zwar auch betroffen, man sieht den Paketverlust bei genauem Hinsehen ebenfalls, allerdings viel weniger stark ausgeprägt und nicht permanent, sondern nur zeitweise.

vielleicht solltest Du mal im 1781VA die fehlerbereinigte Firmware einspielen und es dann nochmal vergleichen.

Grüße
Cpuprofi

[fildercom]

Ja, das wäre sinnvoll. Ich warte dann mal auf die 10.40 RU1 und hoffe, dass der Fix darin enthalten sein wird. Momentan läuft auf beiden Geräten die 10.34.

[Jirka]

Die Sache mit 1781VA vs. 1900EF sieht momentan so aus:

Das "momentan" ist hier irreführend. Dann wenigstens die Firmware-Version angeben oder schreiben, dass auf den Geräten noch keine korrigierte Version läuft, sonst kann das hier keiner mehr nachvollziehen und die Bilder sind wertlos. Auch zeigen die Bilder ja offensichtlich keine neuen Erkenntnisse.

Der 1781VA hat den Paketverlust ständig. Der 1900EF ist zwar auch betroffen, man sieht den Paketverlust bei genauem Hinsehen ebenfalls, allerdings viel weniger stark ausgeprägt und nicht permanent, sondern nur zeitweise.

Die möglichen Gründe hat Backslash ja aufgeführt und ich hatte es auf Deine Situation hin ja auch noch mal kommentiert, sprich das sollten die Erklärungen dafür sein.

Dass nur leere ICMP-Pakete betroffen sein sollen muss ich jetzt erst mal so akzeptieren.

Genau. Alles andere kann man ja weiterhin unter die Lupe nehmen.

Bei eingehenden und ausgehenden Anrufen über den 1781VA beginnt das Gespräch laut Endgerät bereits, während ich das Gegenüber noch nicht höre und er mich auch nicht hört. Erst nach einem kurzen Moment ("Hallo") werden die Audio-Daten (also RTP) übertragen. Der 1900EF hat dieses Phänomen nicht. Beide Router sind auf derselben Telekom-Plattform und der VCM ist identisch konfiguriert. Die Ursache für dieses (Fehl-)Verhalten ist mir weiterhin unklar...

Hast Du schon mal das "Endgerät" im Rahmen eines Troubleshootings ausgetauscht und geschaut, ob das Problem mit dem IP-Telefon mitgeht?
Dass im LANCOM mal zwei drei Pakete anfangs verloren gehen können, kann schon mal sein, bevor die Firewall öffnet, aber das wären dann ca. 50 ms, die da fehlen, das merkt man glaube ich noch nicht.

Viele Grüße,
Jirka

[fildercom]

Hallo Jirka,

danke für deine kritischen Anmerkungen.

Das "momentan" ist hier irreführend. Dann wenigstens die Firmware-Version angeben oder schreiben, dass auf den Geräten noch keine korrigierte Version läuft, sonst kann das hier keiner mehr nachvollziehen und die Bilder sind wertlos. Auch zeigen die Bilder ja offensichtlich keine neuen Erkenntnisse.

Ich habe die aktuelle Firmware-Version im Posting ergänzt, vielen Dank. Neue Erkenntnisse zeigen die Bilder nicht, allerdings wollte ich nochmal verdeutlichen, dass der 1900EF sehr viel weniger betroffen ist als der 1781VA.

Hast Du schon mal das "Endgerät" im Rahmen eines Troubleshootings ausgetauscht und geschaut, ob das Problem mit dem IP-Telefon mitgeht?

Wenn ich mit demselben Endgerät über den 1900EF telefoniere, besteht das Problem nicht. Ich muss aber noch mehr testen. Wenn ich mehr herausgefunden habe, werde ich dazu vermutlich ein eigenes Thema erstellen. Mir ging die Sache nur beim Schreiben des obigen Postings durch den Kopf, aber scheinbar gehört sie hier ja gar nicht dazu.

Gruß
fildercom.

[fildercom]

So, ich habe Neuigkeiten:
Von cpuprofi habe ich freundlicherweise die fehlerbereinigte Version LCOS 10.40.0332 [Stand 02.07.2020] bekommen. Ich habe sie gestern Abend auf dem 1781VA installiert und kann im Monitoring seitdem diesen permanenten Paketverlust nicht mehr feststellen. Interessant ist auch die Gegenüberstellung zum 1900EF, der hin und wieder weiterhin minimale kurze Paketverluste zeigt. Das sollte dann hoffentlich mit einer fehlerbereinigten Version auch auf dem Gerät ganz verschwinden:

tbb.PNG

Im LANmonitor sehe ich auf dem 1781VA jedoch noch einige Firewall-Ereignisse mit Ursprung IP "0.0.0.0", welche ein Broadcast senden wollen:

fw.PNG

Ich kann jedoch keinen Zusammenhang mit der vorherigen nun behobenen Fehlerursache erkennen.

Gruß
fildercom.

[cpuprofi]

Hallo Fildercom,

Im LANmonitor sehe ich auf dem 1781VA jedoch noch einige Firewall-Ereignisse mit Ursprung IP "0.0.0.0", welche ein Broadcast senden wollen:
fw.PNG

dazu müsstest Du dann mal einen Trace erstellen, dann kann man der Ursache auf den Grund gehen.

Grüße
Cpuprofi

[GrandDixence]

Das VDSL-Modem sendet die Broadcasts an UDP Port 4944:
https://www.boc.de/watchguard-info-port ... port-4944/

[fildercom]

Hallo Fildercom,

dazu müsstest Du dann mal einen Trace erstellen, dann kann man der Ursache auf den Grund gehen.

Danke, das wollte ich gerade tun, aber ich habe freundlicherweise bereits die Antwort bekommen:

Das VDSL-Modem sendet die Broadcasts an UDP Port 4944:
https://www.boc.de/watchguard-info-port ... port-4944/

Das habe ich soeben in beiden DrayTek-Modems abgestellt. Jetzt bin ich mal gespannt, ob die ominösen IP 0.0.0.0-Meldungen in der Firewall endlich weg sein.

Könnte man dem LANCOM-Router eigentlich irgendwie beibringen, diese Log-Meldungen des Modems intelligent zu verwenden?

[GrandDixence]

Ein Modem ist eine Bridge.
https://de.wikipedia.org/wiki/Bridge_(Netzwerk)

Und eine Bridge hat keine IP-Adresse. Also verwendet das Modem zum Versenden von IP-Datenpakete die "omniöse" Absenderadresse 0.0.0.0:
https://de.wikipedia.org/wiki/0.0.0.0