RBK20: LAN-Probleme nach Update auf 2.1.4.10

[Oceanwaves]

Hallo,

ich habe ein RBK20 und bislang mit FW 2.1.2.18 keine Probleme. Vor einigen Tagen wurde automatisch ein Update auf 2.1.4.10 installiert.

Die gute Nachricht: es geschah einen Tag, nachdem ich aus dem Urlaub zurück kam.

Die schlechte Nachricht: mein gesamtes LAN funktionierte nicht mehr. Der PC konnte nicht mehr mit dem NAS oder dem Internet kommunizieren, die UPS nicht mehr mit dem NAS, das NAS nicht mehr mit dem Backup-NAS, ... Wäre das Update ein paar Tage früher gekommen, wäre ich im Urlaub von meinem Mailserver und meiner Home Automation abgeschnitten gewesen  . Ein Ping zeigte, dass ständig Paketverluste auftraten. Neustart des Routers (FB 6490), NAS, Switch brachten keine Verbesserung. Erst nachdem ich die Netzwerkkabel vom RBR20 abzog, funktionierte alles wieder wie erwartet.

Eine Überprüfung ergab, dass ein FW-Update auf RBR20 und RBS20 auf 2.1.4.10 eingespielt worden war. Kurze Recherche in der amerikanischen Orbi-Community ergab, dass ich nicht allein war. Auch ein Factory Reset ergab keine Verbesserung, wie im US-Forum bereits festgestellt worden war. Für mich ist es ein Unding, dass ein Hersteller Zwangsupdates ausrollt, die zum einen bekannte Probleme haben (2 oder mehr Satelliten), zum anderen zwingend einen Factory Reset erfordern. Einerseits weiß der Anwender nichts davon, da er durch das automatische Update ja gar nicht in den Update-Prozess involviert ist, andererseits habe ich es noch nie erlebt, dass ein FW-Update bei einem Gerät eine Neukonfiguration erfordert.

Meine Konfiguration: ich habe einen Kabelanschluss von Vodafone (400 MBit/s), als Router eine Fritzbox 6490. Daher kann ich den RBR20 auch nicht als Router nutzen, er läuft als AP. Der Satellit (RBS20) ist über zwei Switches per Ethernet Backhaul angeschlossen.

Ethernet Backhaul ist zwingend erforderlich. Er steht zwar nur eine Etage tiefer und praktisch direkt unter dem RBR20, dazwischen ist aber eine Stahlbetondecke, die jegliche WiFi-Verbindung erfolgreich unterbindet. Ich hatte anfangs 20 Verbindungsversuche per WLAN gemacht. Davon endete 1 Versuch mit einer guten Verbindung, 2 mit einer schlechten Verbindung, bei den übrigen Versuchen kam überhaupt keine Verbindung zustande.

Workaround: ich habe RBR20 und RBS20 wieder auf 2.1.2.18 zurückgesetzt und das automatische Update deaktiviert. Alles funktioniert wieder einwandfrei und wie erwartet.

Was mir noch aufgefallen ist: Während der LAN-Probleme fand ich im Log des PCs (Linux) folgende Fehlermeldungen:

May  2 06:23:46 frodo kernel: IPv6: enp6s0: IPv6 duplicate address xxxx::xxxx:xxxx:xxxx:a2c2 detected!
May  2 06:23:46 frodo kernel: IPv6: enp6s0: IPv6 duplicate address xxxx::xxxx:xxxx:xxxx:a2c2 detected!
May  2 06:23:46 frodo kernel: IPv6: enp6s0: IPv6 duplicate address xxxx::xxxx:xxxx:xxxx:a2c2 detected!
May  2 06:23:46 frodo kernel: IPv6: enp6s0: IPv6 duplicate address xxxx::xxxx:xxxx:xxxx:a2c2 detected!
May  2 06:23:46 frodo kernel: IPv6: enp6s0: IPv6 duplicate address xxxx::xxxx:xxxx:xxxx:a2c2 detected!
May  2 06:23:46 frodo kernel: IPv6: enp6s0: IPv6 duplicate address xxxx::xxxx:xxxx:xxxx:a2c2 detected!
May  2 06:23:46 frodo kernel: IPv6: enp6s0: IPv6 duplicate address xxxx::xxxx:xxxx:xxxx:a2c2 detected!
May  2 06:23:46 frodo kernel: IPv6: enp6s0: IPv6 duplicate address xxxx::xxxx:xxxx:xxxx:a2c2 detected!
May  2 06:23:49 frodo kernel: r8169 0000:06:00.0 enp6s0: link down
May  2 06:23:54 frodo kernel: net_ratelimit: 93 callbacks suppressed
May  2 06:23:54 frodo kernel: r8169 0000:06:00.0 enp6s0: link up
May  2 06:24:05 frodo kernel: nfs: server diskstation not responding, still trying
May  2 06:24:31 frodo kernel: nfs: server diskstation OK
May  2 06:26:20 frodo kernel: nfs: server diskstation not responding, still trying
May  2 06:28:05 frodo kernel: nfs: server diskstation not responding, still trying
May  2 06:28:36 frodo kernel: nfs: server diskstation OK
May  2 06:28:36 frodo kernel: nfs: server diskstation OK
May  2 06:20:38 frodo upsmon[5619]: Poll UPS [ups@nas] failed - Server disconnected
May  2 06:20:38 frodo upsmon[5619]: Communications with UPS ups@nas lost
May  2 06:20:43 frodo upsmon[5619]: Communications with UPS ups@nas established
May  2 06:21:18 frodo upsmon[5619]: Poll UPS [ups@nas] failed - Server disconnected
May  2 06:21:18 frodo upsmon[5619]: Communications with UPS ups@nas lost
May  2 06:23:01 frodo ntpd[5286]: xxxx:xxxx:xxxx:9464::3 local addr xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:fea7:a2c2 -> <null>
May  2 06:23:34 frodo upsmon[5619]: UPS [ups@nas]: connect failed: Connection failure: Connection timed out
May  2 06:23:51 frodo ntpd[5286]: Deleting interface #3 enp6s0, 192.168.178.10#123, interface stats: received=5, sent=23, dropped=0, active_time=673 secs
May  2 06:23:51 frodo ntpd[5286]: 78.47.94.77 local addr 192.168.xx.10 -> <null>
May  2 06:23:51 frodo ntpd[5286]: 212.18.3.19 local addr 192.168.xx.10 -> <null>
May  2 06:23:51 frodo ntpd[5286]: 148.251.247.211 local addr 192.168.xx.10 -> <null>
May  2 06:23:51 frodo ntpd[5286]: Deleting interface #5 enp6s0, xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:fea7:a2c2#123, interface stats: received=3, sent=6, dropped=1, active_time=673 secs
May  2 06:23:51 frodo ntpd[5286]: Deleting interface #6 enp6s0, xxxx:xxxx:xxxx:fea7:a2c2%2#123, interface stats: received=0, sent=0, dropped=0, active_time=673 secs
May  2 06:23:55 frodo ntpd[5286]: Listen normally on 7 enp6s0 192.168.xx.10:123
May  2 06:23:55 frodo ntpd[5286]: Listen normally on 8 enp6s0 [xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:a2c2]:123
May  2 06:23:55 frodo ntpd[5286]: Listen normally on 9 enp6s0 [xxxx:xxxx:xxxx:xxxx:a2c2%2]:123
May  2 06:24:44 frodo upsmon[5619]: Communications with UPS ups@nas established
May  2 06:24:54 frodo upsmon[5619]: Poll UPS [ups@nas] failed - Server disconnected
May  2 06:24:54 frodo upsmon[5619]: Communications with UPS ups@nas lost
May  2 06:27:09 frodo upsmon[5619]: UPS [ups@nas]: connect failed: Connection failure: Connection timed out
May  2 06:29:25 frodo upsmon[5619]: UPS [ups@nas]: connect failed: Connection failure: Connection timed out

Ich hoffe, dass es bald ein funktionierendes FW-Update gibt.

Gruß,

Oliver

[Oceanwaves · Accepted solution]

Da ja gestern Feiertag war, habe ich doch noch mal etwas Zeit in das Thema Update auf FW 2.1.4.10 investiert...

Überraschung: es hat jetzt funktioniert. Man muss sich nur strikt an eine bestimmte Vorgehensweise halten. Und Zeit mitbringen.

Die Lösung fand ich mal wieder im amerikanischen Orbi-Forum bei Netgear:

---

@wziemer wrote:

I had the same issue. Below is what resolved it for me (basically what OP said, but i tried to simplify the instructions a bit). This got me stable after the auto-update recently to the new firmware. 

I have an RBK50 (RBR50+RBS50) and an RBS40. My network was basically dead with the orbi after the 2.1.4.10 update. All devices auto-upgraded. A power-cycle as suggested by the known issues did not help. But powering them up in this order seems to have gotten things working great again!

• Power off all orbi gear
• Power on only the RBR50 (Orbi Router). Wait 2-5 minutes.
• Unplug backhaul ethernet cable from RBS40/RBS50 (Orbi Satallite)
• Power on RBS50 or RBS40 (only 1 at a time, just to make sure to be able to keep an eye on each device and make sure network remains stable).
• Login to RBR50, once you see that the RBS40/50 is connected with 5G, wait 2-5 minutes and plug the backhaul cable back in. Wait 2-5 minutes again and you should see the interface switch to wired for the backhaul connection. Monitor network for another 2-5 minutes to ensure things remain working as-expected.
• Repeat steps 4/5 for any additional satellites.

---

Wichtig dabei ist, dass man jedes "wait" wirklich beachtet. Ich habe nach jedem Schritt Minimum 5 Minuten gewartet, bevor ich weiter gemacht habe. Damit hat es tatsächlich funktioniert. Auch ohne "Daisy Chain". Das lokale Netz hat die Nacht ohne Ausfälle überstanden, insofern gehe ich davon aus, dass das Problem behoben ist.

Was bleibt: Auto-Update bleibt weiterhin aus, bis der Erweis erbracht ist, dass Netgear eine FW hat, mit der die Orbis auch mit Ethernet Backhaul sauber wieder hoch kommen und nicht das gesamte LAN in den Abgrund reißen. Traurig genug, dass sowas bei Tests nicht auffiel oder gar ignoriert wurde.

Und ein Grund mehr gegen das Auto-Update. Besser fände ich es, wenn mir Netgear oder der Orbi eine Mail schickt, wenn eine neue FW vorliegt. Am besten mit Link zu den Release Notes und Beschreibung der Besonderheiten, die man bei der Installation beachten muss. Wie z.B. die o.g. Vorgehensweise. Oder dass man nach dem Update auf 2.1.4.10 unbedingt einen Factory Reset machen soll. Halte ich zwar weiterhin für ein Unding, aber bekommt Otto Normalverbraucher bei einem automatischen Update natürlich überhaupt nicht mit.

[Slas]

Hallo @Oceanwaves,

vielen Dank für deinen Beitrag.

Die Idee zur Auswahl von automatischen Updates wurde weitergegeben.

Grüße
Slas
NETGEAR Community Team

[Oceanwaves]

Hallo @Slas,

vielen Dank! Schöner wäre es allerdings, eine funktionierende FW zu haben. Wie ich Auto-Updates (die dann ggfs. mein gesamtes Netz lahmlegen) deaktiviere, weiß ich ja jetzt. Sicher, die 2.1.2.18 tut ihren Dienst. Aber wenn eine V2.1.4.10 freigegeben wird, dann sollte die auch so gut funktionieren, dass beworbene Features weiterhin funktionieren.

[Oceanwaves]

Und neuer Frust: Genau eine Woche, nachdem ich RBR20 und RBS20 auf FW 2.1.2.18 zurückgesetzt und das Auto-Update deaktiviert hatte, war heute morgen wieder das gesamte Netz down . Keine Backups gelaufen, kein Zugriff auf meinen Mail-Server, ...

Ursache: AP und Satellit waren wieder auf 2.1.4.10. Und das, obwohl Auto-Update eigentlich deaktiviert ist:

root@RBR20:/# nvram show | grep -E "orbi_auto_upgrade|auto_check_for_upgrade|auto_update"
orbi_auto_upgrade=13064382
auto_update=0
auto_check_for_upgrade=0

Habe jetzt beide wieder auf 2.1.2.18 zurückgesetzt und LAN ist wieder  in Ordnung. Aber wenn das jetzt jede Woche passiert, dann fliegt Netgear hier wieder raus. Ich habe keine Lust, jede Woche eine Stunde damit zu verbringen, das LAN wieder zum Laufen zu bekommen.

[Oceanwaves]

---

@Oceanwaves  schrieb:

Habe jetzt beide wieder auf 2.1.2.18 zurückgesetzt und LAN ist wieder  in Ordnung. Aber wenn das jetzt jede Woche passiert, dann fliegt Netgear hier wieder raus. Ich habe keine Lust, jede Woche eine Stunde damit zu verbringen, das LAN wieder zum Laufen zu bekommen.

---

Hat diesmal sogar nur 1 Stunde gehalten, dann waren beide wieder auf 2.1.4.10 :-(((. Habe aber noch einen Tipp bekommen. Die Option

orbi_auto_upg=0

hatte ich übersehen, evtl. gibt's die auch nur beim RBR20. Die ist jetzt auch auf 0 und beide Teile wieder zurück auf 2.1.2.18. Mal schauen, ob das jetzt hält bis eine für mich funktionierende neue FW raus kommt.

[Oceanwaves · Accepted solution]

Da ja gestern Feiertag war, habe ich doch noch mal etwas Zeit in das Thema Update auf FW 2.1.4.10 investiert...

Überraschung: es hat jetzt funktioniert. Man muss sich nur strikt an eine bestimmte Vorgehensweise halten. Und Zeit mitbringen.

Die Lösung fand ich mal wieder im amerikanischen Orbi-Forum bei Netgear:

---

@wziemer wrote:

I had the same issue. Below is what resolved it for me (basically what OP said, but i tried to simplify the instructions a bit). This got me stable after the auto-update recently to the new firmware. 

I have an RBK50 (RBR50+RBS50) and an RBS40. My network was basically dead with the orbi after the 2.1.4.10 update. All devices auto-upgraded. A power-cycle as suggested by the known issues did not help. But powering them up in this order seems to have gotten things working great again!

• Power off all orbi gear
• Power on only the RBR50 (Orbi Router). Wait 2-5 minutes.
• Unplug backhaul ethernet cable from RBS40/RBS50 (Orbi Satallite)
• Power on RBS50 or RBS40 (only 1 at a time, just to make sure to be able to keep an eye on each device and make sure network remains stable).
• Login to RBR50, once you see that the RBS40/50 is connected with 5G, wait 2-5 minutes and plug the backhaul cable back in. Wait 2-5 minutes again and you should see the interface switch to wired for the backhaul connection. Monitor network for another 2-5 minutes to ensure things remain working as-expected.
• Repeat steps 4/5 for any additional satellites.

---

Wichtig dabei ist, dass man jedes "wait" wirklich beachtet. Ich habe nach jedem Schritt Minimum 5 Minuten gewartet, bevor ich weiter gemacht habe. Damit hat es tatsächlich funktioniert. Auch ohne "Daisy Chain". Das lokale Netz hat die Nacht ohne Ausfälle überstanden, insofern gehe ich davon aus, dass das Problem behoben ist.

Was bleibt: Auto-Update bleibt weiterhin aus, bis der Erweis erbracht ist, dass Netgear eine FW hat, mit der die Orbis auch mit Ethernet Backhaul sauber wieder hoch kommen und nicht das gesamte LAN in den Abgrund reißen. Traurig genug, dass sowas bei Tests nicht auffiel oder gar ignoriert wurde.

Und ein Grund mehr gegen das Auto-Update. Besser fände ich es, wenn mir Netgear oder der Orbi eine Mail schickt, wenn eine neue FW vorliegt. Am besten mit Link zu den Release Notes und Beschreibung der Besonderheiten, die man bei der Installation beachten muss. Wie z.B. die o.g. Vorgehensweise. Oder dass man nach dem Update auf 2.1.4.10 unbedingt einen Factory Reset machen soll. Halte ich zwar weiterhin für ein Unding, aber bekommt Otto Normalverbraucher bei einem automatischen Update natürlich überhaupt nicht mit.