Router startet nicht mehr mit LCOS 10.72

[DirkK]

Hallo,

also langsam wird das wirklich schwierig mit den Lancom-Geräten. Nach jedem Firmware-Upgrade muss man zittern, ob die Kisten noch hoch kommen bzw. befürchten was jetzt wieder nicht mehr funktioniert.

Aktuell versuche ich meinen 1784 mit der LCOS 10.72 zu bestücken, aber nach dem Firmwareupdate meldet LANconfig, dass die Firmware zwar geladen werden konnte der Router sie aber nicht starten kann.

Aus dem Bootlog werde ich nicht schlau. Wo kann ich ansetzen nach dem Fehler zu suchen?

Danke und Grüße
Dirk

[tstimper]

Hallo,

also langsam wird das wirklich schwierig mit den Lancom-Geräten. Nach jedem Firmware-Upgrade muss man zittern, ob die Kisten noch hoch kommen bzw. befürchten was jetzt wieder nicht mehr funktioniert.

Aktuell versuche ich meinen 1784 mit der LCOS 10.72 zu bestücken, aber nach dem Firmwareupdate meldet LANconfig, dass die Firmware zwar geladen werden konnte der Router sie aber nicht starten kann.

Aus dem Bootlog werde ich nicht schlau. Wo kann ich ansetzen nach dem Fehler zu suchen?

Danke und Grüße
Dirk

also mit der 10.70.0268 / 17.11.2022 läuft der Router? Die finde ich nicht, die letze 10.70 die ich finde ist die v10.70.0181-ru2

Also wenn die 10.70.0268 / 17.11.2022, aus die der Router zurückfalle eine Beta war, versuche mal die v10.70.0181-ru2 draufzuspielen und dan die 10.72-rel

Hast du schon einen Case bei Lancom offen? Was sagt der Support?

viele Grüße

ts

[DirkK]

Also wenn die 10.70.0268 / 17.11.2022, aus die der Router zurückfalle eine Beta war, versuche mal die v10.70.0181-ru2 draufzuspielen und dan die 10.72-rel

Ja, die 10.70.0268 ist eine Beta, die ich in der Hoffnung eingespielt, dass der WLC-Tunnel Bug beseitigt ist. Ist er aber nicht, sondern lt. Release Notes eben erst in der 10.72.
Da das ein "quasi produktiver" (mehrere Personen im HomeOffice) Router ist möchte ich da nicht allzu viel Downtime produzieren.
Warum meinst du, dass ein Upgrade von der 10.70.0181-ru2 hier ein Unterschied machen sollte? So wie ich es verstehe versucht er ja die 10.72 zu laden panict und zieht dann das alte Image aber für den Start hat doch das 10.70'er Image nichts mit dem neuen 10.72 zu tun ??

Hast du schon einen Case bei Lancom offen? Was sagt der Support?

Ja, bis auf die Case-ID noch nichts, habe ihn aber auch erst vor 10h aufgemacht...

Danke und Grüße
Dirk

[tstimper]

Also wenn die 10.70.0268 / 17.11.2022, aus die der Router zurückfalle eine Beta war, versuche mal die v10.70.0181-ru2 draufzuspielen und dan die 10.72-rel

Ja, die 10.70.0268 ist eine Beta, die ich in der Hoffnung eingespielt, dass der WLC-Tunnel Bug beseitigt ist. Ist er aber nicht, sondern lt. Release Notes eben erst in der 10.72.

Oh ......., der WLC Tunnel Bug ist in 10.70 reingebaut worden? Also in der 10.50RU9 noch nicht drin oder?
Lief denn die 10.50RU9bei Dir mit WLC-Tunnel problemlos? Ich frage, weil ich unsere produktiven WLCs mit WLC-Tunnel nach vielen Schmerzen stabil auf 10.42-ru7 fahre.

Warum meinst du, dass ein Upgrade von der 10.70.0181-ru2 hier ein Unterschied machen sollte? So wie ich es verstehe versucht er ja die 10.72 zu laden panict und zieht dann das alte Image aber für den Start hat doch das 10.70'er Image nichts mit dem neuen 10.72 zu tun ??

Betas sind eigentlich schon recht stabil, dennoch machen die manchmal kaputt was sie fixen wollten.
Ich hatte das mal, da war die einzige Rettung zurück auf die vorhergehende stable Firmware, Reset des Routers, Config zurück spielen und dann auf die nächst höhere Stable updaten.

Ist schon ne Weile her, aber einen versuch wert.

GANZ WICHTIG! Wenn Du den Router resettest, MUSST Du vorher die Zertifikate sichern und ggf Public Spot HTML Files. Die sind in der gesicherten LCF / LCS nicht drin.

Dann Flash auf eine bekannte funktionierende Version, Config und Zertifikate und ggf HTML Files zurückspielen,
testen, Update auf die 10.72, testen

Viele Grüße

ts

[DirkK]

Oh ......., der WLC Tunnel Bug ist in 10.70 reingebaut worden? Also in der 10.50RU9 noch nicht drin oder?
Lief denn die 10.50RU9bei Dir mit WLC-Tunnel problemlos? Ich frage, weil ich unsere produktiven WLCs mit WLC-Tunnel nach vielen Schmerzen stabil auf 10.42-ru7 fahre.

Ja, der war gleich in der 10.70RC1 drin. Siehe hier.
Gibt aber einen relativ einfachen Workaround: den WLC-Tunnel in eine Bridge-Gruppe packen und das Gast-Netz dazu (als die beiden einzigen Member der BRG-Gruppe), dann funktioniert das wieder.

Betas sind eigentlich schon recht stabil, dennoch machen die manchmal kaputt was sie fixen wollten.
Ich hatte das mal, da war die einzige Rettung zurück auf die vorhergehende stable Firmware, Reset des Routers, Config zurück spielen und dann auf die nächst höhere Stable updaten.

Mit Betas habe ich eben eigentlich auch gute Erfahrungen gemacht.
Aber das Vorgehen, welches du beschreibst ist ja mega aufwändig... und nix für "so mal schnell ausprobieren".
Wenn, dann muss ich das vorbereiten und planen...

Sonst jemand eine Idee, was man noch vorher checken sollte???

Danke und Grüße
Dirk

[backslash]

Hi DirkK,

Sonst jemand eine Idee, was man noch vorher checken sollte???

laut Bootlog kommt der DNS-Forwarder in eine Endlosschleife, weshalb der (Thread-) Watchdog zuschlägt...
Stellt sich also die Frage, was du im DNS konfiguriert hast?
Hier wären sowohl die Weiterleitungen unter DNS -> Allgemein als auch Nameserver-Adressen unter IPv4 -> Adressen von Bedeutung...
Hast du da zufällig das LANCOM selbst als Ziel eingetragen?

Gruß
Backslash

[tstimper]

Aber das Vorgehen, welches du beschreibst ist ja mega aufwändig... und nix für "so mal schnell ausprobieren".
Wenn, dann muss ich das vorbereiten und planen...

Ja das ist schon aufwändig, das geht alles mit LANCOM Bordmitteln.

Wir haben uns dazu Software geschrieben.

Configs sichern incl Zertifikate, Firmware flashen, Scripte (im Testmode) ausführen, WLC's und APs managen, Public Spot Voucher, erstellen, VPNs "umbauen" usw...

Das machts zumindest einfacher.

Und alles auditiert gespeichert.

Aber interressant was backslash schreibt:

Hi DirkK,

Sonst jemand eine Idee, was man noch vorher checken sollte???

laut Bootlog kommt der DNS-Forwarder in eine Endlosschleife, weshalb der (Thread-) Watchdog zuschlägt...
Stellt sich also die Frage, was du im DNS konfiguriert hast?
Hier wären sowohl die Weiterleitungen unter DNS -> Allgemein als auch Nameserver-Adressen unter IPv4 -> Adressen von Bedeutung...
Hast du da zufällig das LANCOM selbst als Ziel eingetragen?

Gruß
Backslash

Was konkret wurde beim DNS Verhalten in der 10.72 geändert?
Also im Vergleich zur 10.70-ru2, 10.50-ru9, 10.42-ru7?

Viele Grüße

ts

[backslash]

Hi tstimper

Was konkret wurde beim DNS Verhalten in der 10.72 geändert?

aufgrund von fragen-zur-lancom-systems-routern-und-g ... 19615.html wurden bei Weiterleitungen an Adressen ggf. die nächste Adresse ausgewählt, wenn eine nicht erreichbar ist - das sollte aber maximal zwei Stufen haben und somit nicht in eine Endlosschleife münden, so daß der Watchdog zuschlägt...

Gruß
Backslash

[tstimper]

Hi tstimper

Was konkret wurde beim DNS Verhalten in der 10.72 geändert?

aufgrund von fragen-zur-lancom-systems-routern-und-g ... 19615.html wurden bei Weiterleitungen an Adressen ggf. die nächste Adresse ausgewählt, wenn eine nicht erreichbar ist - das sollte aber maximal zwei Stufen haben und somit nicht in eine Endlosschleife münden, so daß der Watchdog zuschlägt...

Gruß
Backslash

Hi Backslash,

Oh, das heist, das der Bug nicht vollständig gefixt ist. Bei dem einen 1900EF, den ich auf 10.72-rel geflasht habe, sind im Router AD DNS server eingetragen, also nicht der Router selbst.

Bei DirkK ist das möglicherweise so, deshalb der Watchdog...

Hat das schon jemand nachgestellt?

Viele Grüße

ts

[backslash]

Hi tstimper

Oh, das heist, das der Bug nicht vollständig gefixt ist.

Das würde ich so nicht sehen, denn genau das Szenario aus fragen-zur-lancom-systems-routern-und-g ... 19615.html funktioniert definitiv (das wurde ja beim Fix berücksichtigt).

Bei dem einen 1900EF, den ich auf 10.72-rel geflasht habe, sind im Router AD DNS server eingetragen, also nicht der Router selbst.

Bei DirkK ist das möglicherweise so, deshalb der Watchdog...

das sollte kein Problem sein - denn das war auch in obigem Szenario so und ist letztendlich der Grund, weshalb daß die Server weitergeschaltet werden, wenn sie die eigene Adresse haben oder nicht erreichbar sind (sonst wäre gar keine DNS-Auflösung möglich gewesen, solange die Backup-Route aktiv ist)

Hat das schon jemand nachgestellt?

ich hab's versucht und nicht hinbekommen... Egal, was ich eintrage - es werden maximal zwei Anläufe versucht, bevor die Anfrage verworfen wird. Daher wollte ich ja wissen, was genau im DNS konfiguriert ist. Und die zwei Runden sollen nicht zu einem Thread-Watchdog führen, denn der schlägt - wie dem Bootlog zu entnehmen ist - nach 500ms zu, was eine absolute Ewigkeit ist...

Gruß
Backslash

[DirkK]

Hallo Backslash,

laut Bootlog kommt der DNS-Forwarder in eine Endlosschleife, weshalb der (Thread-) Watchdog zuschlägt...
Stellt sich also die Frage, was du im DNS konfiguriert hast?

Ahhh, das ist doch mal ein guter Hinweis, Danke! Anbei meine Konfiguration in den Screenshots. Bei den Weiterleitungen sind eigentlich nur die Tags 0 und 7 relevant. Tag 0 ist der Loadbalancer und verweist auf AdGuard DNS-Server die Malware und Werbung wegfiltern. Tag 7 kommt aus dem Gast-WLAN und der nimmt OpenDNS/Cisco Umbrella als DNS, weil ich das weiter eingeschränkt habe. Die Tags 10 20 und 30 sind "Merker", die eigentlich nie angezogen werden, weil es die Tags nur hier gibt und der Tag 20 verweist z.B. auf eine interne AdGuard Docker Instanz, die ich testweise mal betrieben habe.

Hast du da zufällig das LANCOM selbst als Ziel eingetragen?

Entsprechend meiner Konfiguration würde ich sagen: Nein

Also für meine Begriffe sollte das doch alles soweit ok sein.

Viele Grüße
Dirk

[backslash]

Hi DirkK,

ich muß da nochmal nachfragen...

Du sagst Tag 0 ist der Loadbalancer - du hast also einen Loadbalancer erstellt, der sowohl IPv4 als auch IPv6 Leitungen bündelt, d.h. sowohl die IPv4- als auch die IPv6-Defaultroute zeigen auf den Loadbalancer?
Das bedingt dann auch gleich eine NPTv6-Konfiguration für die IPv6-Leitungen (unter Firewall/QoS -> IPv6-Regeln -> NPTv6) - oder wird der Loadbalancer nur von IPv4 genutzt, während IPv6 nur eine der Leitungen dediziert nutzt?
Wie viele Leitungen sind insgesamt im Loadbalancer?
Hast du ggf. Loopback-Adressen für die Weiterleitungen definiert (DNS -> Allgemein -> Loopback-Adressen), wenn ja, wie?

Also:

• wie sehen die IPv4- und IPv6-Routing-Tabellen aus?
• wie sieht die Load-Balancer-Konfig aus?
• ggf. wie sieht die NPTv6-Konfig aus?
• ggf. wie sieht die DNS-Loopback-Adressen-Konfig aus?

Gruß
Backslash

[DirkK]

Du sagst Tag 0 ist der Loadbalancer - du hast also einen Loadbalancer erstellt, der sowohl IPv4 als auch IPv6 Leitungen bündelt,

Hi Backslash,

ja, seit etwa einer Woche wieder. Hatte das vor Jahren auch schon mal, damals (meiner Erinnerung nach) ausschließlich unter IPv4 mit zwei DSL-Anschlüssen. Mittlerweile hatte ich IPv6 aktiviert und die zweite Leitung nun als SpeedBox sogar über Mobilfunk. Mittlerweile habe ich aber den Eindruck, dass das nicht ganz so funktioniert, wie gedacht/erhofft. Und deine Frage bestärkt mich, dass evtl. da die Wurzel des Übels liegen könnte.

Bin aber gerade auf Dienstreise, schicke die Infos dann morgen, spätestens am Donnerstag.

Danke und viele Grüße
Dirk

[DirkK]

Das bedingt dann auch gleich eine NPTv6-Konfiguration für die IPv6-Leitungen (unter Firewall/QoS -> IPv6-Regeln -> NPTv6) - oder wird der Loadbalancer nur von IPv4 genutzt, während IPv6 nur eine der Leitungen dediziert nutzt?
Wie viele Leitungen sind insgesamt im Loadbalancer?

Hi Backslash,

ich habe die zweite Leitung über den Wizzard inklusive LB konfiguriert. Von NPTv6 war da nichts zu lesen und dort ist auch nichts eingetragen.
Anbei mal die entsprechenden Screenshots.
Insgesamt habe ich zwei Leitungen im LB.

Grüße
Dirk

[DirkK]

Scheinbar gehen nur immer 3 Anhänge pro Post