Unvertraeglichkeit mit Kabelmodem mit 10.20 RU5

[Koppelfeld]

Moin !

Release-Update auf einem guten Dutzend 7100+ von 10.20 RU4 auf 10.20 RU5 durchgeführt.

Klappt überall, bloß nicht auf unserem eigenen Gerät:

IPoE - Verbindung zu einem cbn - Kabelmodem (KD/Vodafone) im BRIDGE - mode, läuft seit Jahren stabil mit 7100+ -- bis 10.20 RU4.

Nach Installation von RU5 bricht die Verbindung nach etwa 5 Minuten ab, Meldung: "<LINE> disconnected". Baut sich immer mal wieder für ein paar Minuten auf. Arbeiten ist unmöglich.

Irgendetwas bekannt ?

[GrandDixence]

Bei Ethernet-relevanten Fehlermeldungen im SYSLOG:

Ethernet-Fehlersuche gemäss:
viewtopic.php?f=41&t=17246&p=97830#p97830
durchführen.

[lordmike1503]

Hier auf zwei 1781EF+ ein ähnliches Fehlerbild mit Glasfaser-Standleitungen (DeutschlandLAN Connect IP) der Deutschen Telekom.

Wir haben mit der Hotline telefoniert und müssen zurück auf das RU4, zum Glück brauchen wir bei diesen Anschlüssen den VCM nicht. Mit dem RU4 gehts sofort wieder einwandfrei.

Bei einem anderen 1781EF+ mit einer Glasfaser-Standleitung von Colt gibt es aber komischerweise bei gleichen Einstellungen wiederum keine Probleme.

Bei unserem 7100+ hinter einer Kabel-Fritzbox und einer DSL-Fritzbox (jeweils Doppel-NAT, der 7100+ hat keine öffentlichen IPs) gibt es auch keine Probleme.

Bei einem 1781VA zickte heute plötzlich kurze Zeit der DNS im LANCOM und beantwortete keine Anfragen, weder welche die an den Telekom-DNS weitergegeben werden sollten, noch welche die an den Google-DNS weitergegeben werden sollten, Ping zum Google-DNS war kein Problem, VCM hat sich daher auch nicht registriert, kein Telefon ging, ich dachte schon bei PPPoE gehts jetzt ähnlich wie bei IPoE auch los, dann ging der DNS im LANCOM aber ohne Änderung von selber wieder (Neustarten vorab half aber nichts).

Übrigens: bei dem oben genannten Problem laufen Pings von innen z.B. auf 8.8.8.8 problemlos weiter aber Pings von aussen auf die öffentliche IP des jew. Geräts gehen nicht und dann gehen sie plötzlich wieder und auch VPN (IKEv2) geht dann gleichzeitig nicht mehr und plötzlich gehts dann wieder und so weiter...

Bitte bitte bitte LANCOM findet so schnell wie möglich wieder zu eurer alten Qualität zurück!

RU3 IKEv1 hinter NAT kaputt, Telefonie kaputt
RU4 Telefonie noch mehr kaputt, IKEv1 hinter NAT immer noch kaputt
RU5 Telefonie geht, dafür IPoE so sehr kaputt, dass alles zu spät ist

Warum macht ihr das mit uns?

Lasst doch den Mist meinetwegen auf immer und ewig im Beta-Stadium und bringt wirklich nur dann Releases raus wenn man diese auch gefahrlos einsetzen kann!

[lordmike1503]

Der 1781VA ist auch betroffen, es sind also nicht wie ursprünglich von mir vermutet nur IPoE-Umgebungen sondern auch Umgebungen mit PPPoE und in diesem Fall VDSL betroffen.

Nach wie vor kann ich kein Muster erkennen.

[lordmike1503]

@Koppelfeld Habt ihr beim betroffenen 7100+ VPN im Einsatz wo irgendwo NAT-T zum Einsatz kommen muss oder wo auf einer Seite ein Hostname und keine öffentliche IPv4 eingetragen ist?

[Koppelfeld]

Haben wir, leider. Jede Menge.

[backslash]

Hi Koppelfeld,

Nach Installation von RU5 bricht die Verbindung nach etwa 5 Minuten ab, Meldung: "<LINE> disconnected". Baut sich immer mal wieder für ein paar Minuten auf. Arbeiten ist unmöglich.

Da muß ich erstmal sagen: Diese Meldung gibt es so erstmal nicht... daher werden ein paar genauere Informationen benötig, um das Problem einzukreisen

• Was genau wird wo gemeldet? Im Syslog, im einem Trace (welcher)?
• Geht es hier um die Internetverbindung oder um eine VPN-Verbindung?
• was sagt ein "display"- (Error + Status) bzw. ein VPN-Status-Trace (je nachdem welche Art Verbinundg abreißt)
• Hast du ein ICMP-Polling auf der Verbindung konfiguriert?

Gruß
Backslash

[Koppelfeld]

Moin,
hätte die Untersuchung erledigt, doch wir "dürfen" über Ostern ein komplettes Netz umbauen und sind seit gestern auf der Baustelle.

Von der Ferne geht es nicht, pünktlich zum Problem hat die Telekom unsere Backup-Leitung zersägt. Mir blieb nur Rücksturz auf RU4.

Kann die Angelegenheit erst am kommenden Mittwoch untersuchen.


Frohe Ostern!

[Koppelfeld]

Moin!
Erst gerade konnte ich ein wenig herumtesten:

10.20 RU5: Unbenutzbar, ich fliege alle paar Minuten aus meinen VPNs. Selbst Internet-Surfen klappt nicht, zu oft klappt die DNS-Auflösung nicht.

Dann bin ich 'mal in die Rolle des "cpuprofi" geschlüpft und habe die Beta 10.30.064 installiert.

Sofortige deutliche Verbesserung und auch keine Störungen beim VPN.

Jedoch immer wieder bei UDP-Verbindungen Ausfälle.

Was genau wird wo gemeldet? Im Syslog, im einem Trace (welcher)?

Im Syslog:

Code: Alles auswählen

47	2019-04-29 01:01:21	AUTH	Info	Disconnected from peer INET-KD: ICMP-conn.-Error
48	2019-04-29 01:01:21	AUTH	Info	User LPPTKVPN logged out
49	2019-04-29 01:01:21	LOCAL0	Fehler	error for peer INET-KD: ICMP-conn.-Error
50	2019-04-29 01:01:21	LOCAL0	Fehler	VPN: Disconnect info for peer LPPTKVPN: physical-disconnected
51	2019-04-29 01:01:21	LOCAL0	Fehler	VPN: Disconnect info for peer LPPTKVPN: physical-disconnected
52	2019-04-29 01:01:21	LOCAL0	Fehler	line polling to peer INET-KD failed

Bei Gelegenheit könnte jemand 'mal das adverbial gebrauchte 'physical' in 'physically' abändern.

Geht es hier um die Internetverbindung oder um eine VPN-Verbindung?

Die stotternde Internetverbindung reißt das VPN mit ...

Hast du ein ICMP-Polling auf der Verbindung konfiguriert?

Ja, wg. Backup-Umschaltung habe ich ICMP auf Default-GW konfiguriert.

Wie gesagt:
Bei der Beta ist das zu vernachlässigen, die RU5 ist unbenutzbar mit IPoE über KabelD.

[lordmike1503]

Hallo Koppelfeld,

kannst du dich bitte mit dem Support in Verbindung setzen und denen Traces mit dem RU5 nach Wunsch bzw. Vorgabe erstellen und denen dann auch im Rahmen der Traces die Konfig übermitteln (im Rahmen der Traces wird die anonymisiert)?

Die Ticket-Nummer die im Rahmen meiner Anfrage erstellt wurde ist die 35513.

Ich schaffe es leider zeitlich nicht... ich habe zwei Tage dadurch verloren... wir sind bei den drei Problemkindern dann schlussendlich auf das RU4 zurück und haben einen Workaround für das 15 Minuten-VoIP-Problem gebastelt...

Vielen vielen Dank!

Viele Grüße!

[cpuprofi]

Hallo lordmike1503,

Hallo Koppelfeld,

kannst du dich bitte mit dem Support in Verbindung setzen und denen Traces mit dem RU5 nach Wunsch bzw. Vorgabe erstellen und denen dann auch im Rahmen der Traces die Konfig übermitteln (im Rahmen der Traces wird die anonymisiert)?

Du glaubst doch wirklich nicht, dass Koppelfeld Trace erstellen und sich mit dem Support herumschlagen wird...?

So wie ich Ihn kenne, wird das nichts werden, denn mehr als den Support hier durchs Forum wird sich Koppelfeld nicht zumuten wollen und zum Trace erstellen hat er auch Null Ambitionen... aber das ist ja seine Entscheidung.

Grüße
Cpuprofi

[elliot2extreme]

Mein LANCOM zeigt die gleichen Probleme und ich habe auch schon ein Ticket dazu. Inzwischen auch ein angepasste Firmware zum Test durch, welche das Problem nicht mehr zeigt.

[LoUiS]

HI,

ich denke das Problem ist erkannt und behoben. Es wird dazu nun in Kuerze eine 10.20 RU6 geben, in der ausschliesslich der Fix fuer das betreffende Verhalten enthalten ist.


Ciao
LoUiS

[Koppelfeld]

So wie ich Ihn kenne, wird das nichts werden, denn mehr als den Support hier durchs Forum wird sich Koppelfeld nicht zumuten wollen und zum Trace erstellen hat er auch Null Ambitionen... aber das ist ja seine Entscheidung.

Wenn ich hier einen Thread aufmache und damit die wichtigste Ressource intelligenter Leute verbrauche, nämlich deren Lebenszeit, dann halte ich es für eine Frage des Anstands und des Respektes, nach besten Kräften zu kooperieren.

Freilich: Wer mißt, mißt Mist.
Es hat noch nie einen tcpdump gegeben, der fehlende Pakete aufzeichnen hätte können. Von so einem "LCOS - Trace" hätte ich mir mehr versprochen.
Trotzdem hätte ich etwas versucht, bin aber froh, von Louis gehört zu haben, daß das Problem bald behoben sein wird.
Wäre interessant zu wissen, woran es lag, igendwas, das im Dreieck liegt, das VPN, DNS und UDP aufspannt.


Schön, wenn ein Fehler nicht abgestritten, sondern behoben wird!

[elliot2extreme]

Nach allem was ich bisher bezgl. dem Problem bei mir in Erfahrung gebracht habe, hat es zumindest bei mir etwas mit DynDNS zu tun. Sobald ich von einem internen System / Client auf meine DynDNS Adresse zugreife kommt es zu den besagten Abbrüchen beim Ping vom LANCOM nach extern als auch von extern gegen die WAN IP.