Das kann - unter passenden Umständen - tatsächlich funktionieren (insofern revidiere ich mich hinsichtlich des "kann niemals") ... warum genau und wann exakt das schiefgeht, muß ich mir noch mal in aller Ruhe überlegen - hier zehre ich nämlich von meinen (negativen) Erfahrungen, die bei meinen Tests mit schöner Regelmäßigkeit auftreten, wenn ich solche Konstellationen nach einem Zurücksetzen von FRITZ!Boxen unabsichtlich im LAN habe. Hier spielen dann sowohl der zweite (getrennte) IP-Stack für das WAN-Interface bei AVM als auch der PA hinein, der bei eingehenden (Antwort-)Paketen direkt die MAC-Adresse des Ziels im LAN einträgt und das damit gar nicht noch einmal ins Routing für das LAN schickt.
Im Normalfall und wenn man sich nicht penibel an die Reihenfolge beim Herstellen von Verbindungen hält, führt das aber auch bei FRITZ!Boxen zu Loop-Problemen, denn sowohl in der Werkskonfiguration als auch jedesmal in der Start-Phase des FRITZ!OS (auch nach einem erfolgreichen Update gibt es ja einen Restart) sind eben alle Ethernet-Ports noch in einer gemeinsamen Bridge versammelt und das gibt dann bei einer solchen Verkabelung (noch bevor man die Konfiguration passend einstellen kann) Meldungen dieser Art im FRITZ!OS:
Code:
[ 45.810000][0]lan: received packet on eth0 with own address as source address
und in der Folge ist die Box häufig nicht vom LAN her ansprechbar - bis hin zum kompletten Netzversagen auch bei anderen Clients.
Aber das passiert mir hier meist auch für die DSL-Modelle und nicht für Kabel-Boxen ... und wird vielleicht auch noch von den bei mir verwendeten VLANs verschlimmert, weil die Box dann vor dem Laden des "dsld" auch noch kein passendes Tagging macht.
Denn eigentlich läuft das ja darauf hinaus, daß man die erste und die zweite FRITZ!Box auf verschiedenen Interfaces (aber eben erst ab dem Laden des "dsld" sind das verschiedene Interfaces) mit demselben Switch (in der ersten FRITZ!Box) verbindet (und Trunking kann die Box nicht wirklich) - wobei in der zweiten ein Kabel in LAN1 kommt und eines in einen der anderen Ports (wenn kein LAN-Gastnetz konfiguriert ist, was ebenfalls solche Probleme in der Startphase hervorrufen kann und daher von AVM beim Umstellen auf LAN1-Modus auch abgeschaltet wird) und es bei der ersten keine Rolle spielt, wo die Kabel landen in den Ports.
-----------------------------------------------------------------------------
Wobei mich im Moment auch die Frage umtreibt (testen will ich nicht, schon die "Gedankenspiele" sind genug Ablenkung von momentan Wichtigerem und ich habe aus naheliegenden Gründen kein 192.168.178.0/24-Netz in irgendeinem Router), warum man dann das LAN-Interface der zweiten Box überhaupt für das Update umkonfigurieren muß (nur für diese Konstellation wohlgemerkt, wo die zweite Box mit dem Rest des LANs gar nicht verbunden ist, sondern nur mit einem Client für das Anschieben des Updates)`und es nicht einfach beim Standard (inkl. DHCP-Server) belassen kann.
Die Routing-Table in einem ATOM-System der 6490 sieht ja so aus:
Code:
# ip r
default dev dsl metric 2
83.169.184.33 dev dsl metric 2
83.169.184.97 dev dsl metric 2
91.65.84.0/24 dev dsl metric 2
169.254.0.0/16 dev lan src 169.254.1.1
169.254.1.0/30 dev acc0 src 169.254.1.1
172.31.179.0/24 dev guest src 172.31.179.1
192.168.128.0/17 via 192.168.lan.2 dev lan
192.168.lan.0/28 dev lan src 192.168.lan.1
192.168.180.1 dev dsl metric 2
192.168.180.2 dev dsl metric 2
Die Default-Route hat also gar kein "via" (was eine erneute Auswertung auslösen könnte) und da das im FRITZ!OS ja getrennte IP-Stacks sind (für die WAN-Seite verwendet AVM einen eigenen (Ur-)Enkel des MPR von vor 25 Jahren), dürfte es auch nicht stören, wenn das WAN-seitige Gateway dieselbe IP-Adresse hat, wie das LAN bzw. sogar wie die Box selbst. Der einzige Punkt, der das verhindern könnte, wäre ein expliziter Test von AVM, bei dem diese Konfiguration abgelehnt wird - gibt es den wirklich?
-----------------------------------------------------------------------------
Auch den beschriebenen Aufwand, die Box über ihre Notfall-IP anzusprechen, braucht es nach meiner Erfahrung nicht wirklich ... der Passus
Starte deine zweite Box neu (damit sie auch definitiv die Notfall-IP bekommt)
ist - zumindest in der Begründung in Klammern - sogar falsch, denn
jede FRITZ!Box weist ihrem "lan:0"-Interface
immer die 169.254.1.1 als IPv4-Adresse zu:
Code:
11: lan: <BROADCAST,MULTICAST,UP,LOWER_UP200> mtu 1500 qdisc noqueue
link/ether c8:0e:14:da:da:da brd ff:ff:ff:ff:ff:ff
inet 192.168.xxx.1/28 brd 192.168.xxx.15 scope global lan
inet 169.254.1.1/16 brd 169.254.255.255 scope global lan:0
und schert sich dabei nicht im Geringsten darum, ob eine andere Box bereits dieselbe IP-Adresse benutzt. Die wird gar nicht "vergeben" und ist auch immer dieselbe, damit paßt das "bekommt" in der Begründung nicht.
Das (also diese "blinde" Benutzung) gibt dann - bei zwei FRITZ!Boxen im LAN - auch immer das Problem, daß man nicht vorhersagen kann, welche der beiden Boxen nun schneller auf den ARP-Request für 169.254.1.1 antwortet ... der "Gewinner" wird - bis zum ARP-Timeout - dann wieder zuverlässig immer derselbe sein, weil so lange keine erneute ARP-Auflösung erfolgt.
Wenn man in so einer Situation also die falsche Box erwischt, sollte man nicht die FRITZ!Box(en) neu starten, sondern die ARP-Tabellen löschen und wenn man es wg. Timing-Problemen nie hinbekommt, die andere FRITZ!Box zu erreichen, sollte man eher über einen (temporären) statischen ARP-Eintrag für die MAC- und IP-Adresse der gewünschten Box nachdenken, weil das der einzige zuverlässige Weg ist, die gewünschte von zwei (oder mehreren) aktiven FRITZ!Boxen über die Notfall-IP zu erreichen und man damit auf Ein- und Ausschalten von Boxen oder auf Änderungen der Verkabelung verzichten kann.
Jedoch wird die 169.254.1.1 auch erst mit dem Start des "dsld" aktiv, denn die wird über die "ar7.cfg" erst konfiguriert und diese wertet (hinsichtlich der Switch-Konfiguration) auch der "dsld" erst aus. Früher konnte man die IP-Adresse für "lan:0" auch noch gefahrlos ändern oder das Interface ganz entfernen ... inzwischen hängen (nicht nur bei den DOCSIS-Modellen, wo diese Adressen auch der Kommunikation zwischen dem ARM- und dem ATOM-System dienen) da noch AVM-Dienste an diesem Interface und man sollte auf Änderung in der "ar7.cfg" verzichten.
Allerdings kann ich auch (konkret bei einer 143.06.83, eine 07.01 habe ich gerade nicht zu Hand zum Check) das Problem, die 169.254.1.1 über WLAN zu erreichen, nicht nachvollziehen. Gebe ich die vom Tablet aus ein, das mit dem WLAN der FRITZ!Box verbunden ist, erreiche ich problemlos das AVM-GUI und hier sogar mit fast 100% Erfolg (solange die 6490 nicht am Anschlag läuft) auch das richtige, selbst wenn eine weitere FRITZ!Box mit dieser 6490 per LAN-Kabel gekoppelt ist.
-----------------------------------------------------------------------------
Was spricht denn dagegen, der zweiten Box für die Dauer des Updates einfach auf der LAN-Seite ein
anderes Netzwerk zu verpassen, als das auf der WAN-Seite von der ersten Box aufgespannte? Als dauerhafte Lösung ist die beschriebene Konfiguration ja ohnehin nicht geeignet - da sind wir uns einig.
Die zweite Box ist aber (in Werkseinstellungen) zunächst mal problemlos über ihr eigenes WLAN separat zu erreichen und kann damit entsprechend auf ein anderes LAN-Netz konfiguriert werden, anschließend noch auf den Internet-Zugang über LAN1 (den man dann auch herstellen kann, wenn er konfiguriert wurde - vorher sollte man das Kabel nicht in LAN1 (bzw. "eth0") einstecken) und alles ist bestens.
Selbst wenn die zweite Box noch nicht in Werkseinstellungen ist, soll sie ja nach der Beschreibung ohnehin zurückgesetzt werden und der einzige (plausible) Grund, warum man das nicht per WLAN machen sollte (Du schreibst ja explizit, man
müsse das per LAN machen), wäre die Unkenntnis des WPA2-PSK für das aktuell eingestellte WLAN in der zweiten Box. Selbst wenn man das LAN-Segment nicht kennt und kein DHCP-Server aktiv ist, kriegt man die Box normalerweise über die Notfall-IP.
Insofern verstehe ich auch Schritt 2 nicht so richtig ... warum sollte man die erste FRITZ!Box ausschalten, wenn es vollkommen ausreichend ist, eine (LAN-)Verbindung zwischen Client und zweiter FRITZ!Box als einziges Kabel in der zweiten Box stecken zu lassen bzw. das LAN überhaupt nicht zu verbinden per Kabel und einfach mit dem WLAN (der zweiten Box) die zweite Box dann zu konfigurieren.
-----------------------------------------------------------------------------
Wenn man (lt. Beschreibung) die LAN-Adresse der FRITZ!Box ohnehin ändern soll (auf 192.168.178.2/24), kann man aber auch gleich ein anderes Netz dafür nehmen ... dann interessiert es auch nicht (für den zur Bedienung des GUI beim Update angeschlossenen Client), ob der DHCP-Server in der zweiten Box an oder aus ist (für den Zeitraum des Updates). Ggf. muß man den verwendeten Client dann noch einmal mit dem (W)LAN neu verbinden, wenn der die Änderung der IP-Adressen nicht automatisch mitkriegt.
Nach dem Update konfiguriert man dann die LAN-Adresse der zweiten Box so, daß sie im LAN der ersten Box liegt (erster Absatz #2) und dann kann man die Box auch als SIP-Server, NAS, SmartHome-Hub und WLAN-AP benutzen und in dieser Konfiguration (noch einmal mit Werkseinstellungen nach dem erfolgreichen Update und nur LAN-seitig auf eine passende IP eingestellt - auch das geht wieder über WLAN, wenn man keinen Client direkt an die zweite Box (und nur an diese) stecken will) sollte sie sich auch als Mesh-Repeater zu einem bestehenden Mesh-Netz hinzufügen lassen. Das macht man am besten auch in der "Grundkonfiguration", bevor man irgendwelche anderen Sachen (inkl. Router über LAN1) verstellt.
-----------------------------------------------------------------------------
Dann kann/muß/sollte man sich entscheiden, ob die zweite Box nun einen permanenten Internet-Zugriff braucht oder nicht. Braucht sie keinen, kann man einfach beim Router-Modus über das CM bleiben (das Factory-Reset hat den ja wiederbelebt) und hat den Ethernet-Port LAN1 auch noch zur Verfügung - auch dann kann man das CM noch abstellen, das braucht nur unnötig Strom (wie im LAN1-Betrieb m.W. derzeit auch noch immer, denn AVM legt das CM wohl nicht still - auch nicht in der 07.01).
Wie das geht, habe ich letztens irgendwo beschrieben (Stichwort "setstartup") - wer keine Shell hat, baut sich ein passendes JFFS2-Image für "/nvram" und flasht das über den Bootloader. Wer nur "Download-Zertifikate" hat, kann/darf hier kein generisches Image nehmen, denn dem würden diese Zertifikate fehlen - sind die im Bootloader, werden sie ohnehin beim Start ins JFFS2 kopiert. Mit Download-Zertifikat und ohne Shell-Zugang sollte man also KEIN JFFS2-Image flasc
Will man auch für die zweite Box einen Internet-Zugriff haben (ich weiß nicht, wie sie sich als Mesh-Repeater bei Updates ihrer eigenen Firmware verhält - muß sie die selbst suchen oder kriegt sie die vom Mesh-Master, der das ja auch "überwacht"), muß man eben LAN1 konfigurieren und dann unter "Internet / Zugangsdaten / IPv6" auf "native IPv6-Anbindung verwenden" stellen (welcher Kabelbetreiber bietet keine IPv6-Adressen an?). Die IPv4-Anbindung läßt man dann entweder aus (die FRITZ!Box selbst sollte auf alle notwendigen Dienste auch per IPv6 zugreifen können) oder man trägt den AFTR des Providers ein, den der garantiert betreibt, wenn es in seinem Netz auch DS-Lite-Anschlüsse gibt.
Das wäre dann tatsächlich die einfachste Möglichkeit, die zweite FRITZ!Box ins LAN und parallel ins Internet zu bringen ... erst wenn es kein IPv6 gibt, muss man überhaupt weiter über IPv4 nachdenken und dann könnte das tatsächlich sogar im Dauerbetrieb auch mit demselben Netz auf der LAN- und der WAN-Seite der Box funktionieren, solange sie nichts zum Routen kriegt. Wenn sie selbst lokale Verbindungen nutzen will, geht die Auflösung ohnehin über ARP (das "lan"-Interface der zweiten 6490 hat dann auch gar kein Gateway - s. Routing-Table - und das sollte für alle FRITZ!Boxen im Router-Modus so sein).
Alles andere, was nicht lokal ist, geht über die Default-Route und wenn die Box da ein ARP für das Gateway macht, kriegst sie ja auch unter der MAC-Adresse des WAN-Interfaces die Antwort und kann das Paket auf diesem Interface mit der MAC-Adresse des nächsten Hop senden. Der AVM-Stack trägt m.W. auch die ARP-Infos nicht in die Tabellen für den "Linux-Stack" ein. Spannend wird es ggf. nur dann, wenn man von der zweiten Box aus Dienste auf der ersten benutzen will, z.B. den SIP-Server. Das würde theoretisch über die LAN-Seite gehen (die hat die passende Route dafür) und damit (höchstwahrscheinlich) geringeren Sicherheitsanforderungen unterliegen, als wenn die Kommunikation auf der WAN-Seite erfolgen würde.
Aber durch die Konstruktion des FRITZ!OS könnte das tatsächlich funktionieren ... solange AVM da nichts mit zusätzlichen Tests abfängt.