wieso der Lease nach einer Woche abzulaufen scheint
Ich wage die Behauptung (nach dem, was ansonsten noch so zu lesen war hier an Beschreibung), daß das eine Fehlinterpretation der Symptome ist - eher hat Dein Kabel-Modem (aka Router FAST5460) eine Macke - das kann bis zum thermischen Problem gehen, was nur bei höheren Außentemperaturen im (nicht wärmeisolierten) Betriebsraum im Keller auftritt. Meinetwegen kann das auch das Kabel sein ... wobei 30m für Ethernet kein Problem sind und dann ein direkt am Modem angeschlossenes Gerät ja auch im Fehlerfall funktionieren müßte.
Wenn der Router das nächste Mal keine IP-Adresse mehr kriegt vom Modem, solltest Du entweder über die 7390 das Modem auf der eigenen IP-Adresse überprüfen - die 192.168.100.1 (nicht zu verwechseln mit der 192.168.0.1, die ein FAST5460 als Standard im Router-Modus nutzt) sollte jedes Modem "bedienen" lt. Spezifikation, auch wenn der eRouter ausgeschaltet ist (also der "Bridge Mode" aktiv ist). Da muß nicht zwangsweise ein HTTP-Interface vorhanden sein (ist es beim FAST5460 aber meines Wissens trotzdem), aber ein SNMP-Stack und den kann/darf man auch abfragen. Das kann man (z.B. mit "
snmpwalk") auch schon machen/testen, wenn es noch kein Problem gibt ... man bereitet sich also besser vor, dann weiß man im Fehlerfall gleich, wie es geht.
Wenn in dem berichteten "Fehlerzustand" das Modem (ich nenne das FAST5460 jetzt konsequent so, solange es im Bridge-Modus ist - die Unterscheidung habe ich bisher oft genug getroffen) auch einem - anstelle der 7390 angeschlossenen - PC keine IP-Adresse per DHCP zukommen läßt, kann man davon ausgehen, daß die Verbindung CM<->CMTS unterbrochen ist, egal aus welchem Grund. Hier wäre es dann natürlich nützlich, VOR dem Neustart des Modems mal zu erkunden, ob das in diesem Zustand noch IRGENDEINE Diagnose-Info herausrückt - damit kann man auch "Tauschgelüste" (bis hin zu Ultimaten diesbezüglich) besser begründen ggü. dem Provider. Da meines Wissens das HTTP-Interface an 192.168.100.1 im Bridge-Mode auch in der Firmware-Version 6.1.2.26-IMS-KDG noch vorhanden sein soll (welche Firmware hat eigentlich Dein "F@ST 5460", um mal die Bezeichnung der Franzosen zu übernehmen?), müßte man dem Modem/Router da auch noch etwas entlocken können.
Wobei der KNB auch wissen sollte (sonst muß er seine Protokollierung hochdrehen), wann sich ein CM anmeldet und wann das CMTS die Verbindung mit diesem CM wieder verloren hat - da gehen Lebenszeichen zwischen CM und CMTS hin und her, auch wenn der Kunde nichts zu übertragen hat. Wenn dieser Zeitpunkt des Verbindungsverlusts VOR dem liegt, an dem Deine 7390 ihre Fehlermeldungen produziert, dann ist die Frage nach Ursache und Wirkung ja praktisch schon geklärt.
Die Lösung mit dem Zurücksetzen des Modems durch "power off/power on" ist zwar als temporärer Workaround vielleicht hilfreich, aber wenn es - dank der fehlenden Integration - keine belastbare Info seitens des FAST5460 gibt, ob und wann es die Verbindung zum CMTS hergestellt hat und jetzt auf L2 transparent arbeitet, wirst Du mit etwas Pech immer wieder auch mal eine nicht-öffentliche IP-Adresse vom Router kriegen.
Wobei ich hier tatsächlich auf ein Firmware-Problem tippen würde, wenn der im Bridge-Mode (der schon bei der letzten erfolgreichen Verbindung eingestellt wurde, wenn das Modem nicht zwischenzeitlich zurückgesetzt wurde) den eRouter auch nur zeitweise aktiviert (und da gehört nach meinem Verständnis der DHCP-Server für die LAN-Seite dazu).
Eigentlich müßte das Gerät die letzte eRouter-Konfiguration (also "disabled") speichern und erst wieder ändern, wenn es andere Instruktionen vom KNB erhält. Zumal es hier auch noch einen "echten Reset-Knopf" am Gerät gibt ... die Argumentation (bei anderen Geräten), daß man dann gar nicht mehr an das GUI des Gerätes herankäme, wenn es erst einmal im Bridge-Mode ist und später an einem ganz anderen Anschluß oder gar ohne Benutzung des DOCSIS-Modems weiterarbeiten soll, greift ja auch nicht, wenn so ein Taster vorhanden ist.
Aber auch das kann man ja (in einer kleinen Internet-Pause für die Familie und vermutlich sind deshalb "echte Admins" auch eher nachtaktiv) einfach mal testen ... ein Linux-Host am Modem (als einziger wohlgemerkt), der alle drei Sekunden einen DHCP-Request losläßt, während das Modem gerade neu startet, zeigt ja ziemlich genau an (mit sehr, sehr geringem Aufwand), wann genau da ein DHCP-Server mit einer Antwort reagiert. Die MAC-Adressen sollte das (e)CM auch bei jedem Einschalten neu lernen (und der Provider sollte sie im Bridge-Mode ignorieren, weil für ihn nur die Anzahl wichtig ist), damit sollte nach einem weiteren Neustart auch die FRITZ!Box wieder als Router funktionieren können - auch wenn man zwischenzeitlich einen anderen (DHCP-)Client an den "customer-facing interfaces" des Sagemcom betrieben hat.
Wenn sich dabei dann herausstellt, daß das FAST5460 korrekt arbeitet, stellt sich wieder die Frage, wieso es zwischenzeitlich mal eine 192.168.0.0/24-Adresse ausgegeben hatte (in #4) ... aber das ist nun mal das Standardnetz, was ein FAST5460 verwendet und man könnte zumindest noch spekulieren, daß das dann direkt nach einem Zurücksetzen des FAST5460 war (was das Handbuch auch noch als "Fehlerlösungsversuch" empfiehlt:
https://kabel.vodafone.de/static/media/sagemcom_WLANRouter_FAST5460.pdf - Seite 45, Punkt 4) und dann arbeitet natürlich der eRouter auch erst mal wieder (wenn auch eher als "autonomes Gerät", denn als eRouter, weil es ja noch keine WAN-Seite gibt, wohin man Daten senden könnte) in der Werkskonfiguration und dieses Gerät ist als 192.168.0.1 zu erreichen, während sein DHCP-Server fleißig Adressen aus 192.168.0.0/24 an die Clients herausgibt.
Erst das Config-File vom Provider schaltet dann das ganze Gerät wieder um und den eRouter ab ...
das wäre auch noch eine plausible (und aus dem Leben gegriffene) Annahme, warum da zwischendrin mal eine 192.168.0.4 in der 7390 aktiv war als WAN-Adresse - wenn es sich nicht um ein generelles Problem der Firmware handelt. Nun ist der Betrieb in diesem Modus aber auch eine eher seltene Erscheinung und da erscheint mir ein "durchgerutschtes" (bzw. gleich ignoriertes) Problem in der Firmware auch nicht sooo unwahrscheinlich.
Arbeitet das FAST5460 einwandfrei und bleibt die LAN-Seite inaktiv, bis das eCM fertig ist mit der Initialisierung (am besten inkl. Ethernet-Ports, weil ansonsten die FRITZ!Box halt schon mit DHCP-Requests beginnt, die noch ins Leere laufen, weil das eCM sie nicht weiterreicht), dann bringt auch die schaltbare Stromversorgung für das FAST5460 etwas - ansonsten bleibt das Risiko, daß die 7390 für die Dauer von T2 bei der Lease für die 192.168.0.0/24-Adresse nicht erreichbar ist und wie lange das genau wäre, hängt von der Lease-Time des DHCP-Servers im FAST5460 ab.
Erst nach dem T2-Ablauf würde die 7390-Box die Abschaltung des eRouters im FAST5460 feststellen (mal unter der Annahme, daß keine boxinternen Prozesse das schon vorher forcieren) und einen neuen DHCP-Request auf der WAN-Seite starten ... die ausbleibende Antwort nach Ablauf von T1 ist nichts, was sofort zur Panik beim DHCP-Client und zu einem neuen Request führt.
Beim DHCP-Server einer FRITZ!Box ist die Standard-Lease-Time im LAN auf 10 Tage eingestellt (iirc auch bei der 6490) ... da würde erst nach 7/8 * 240h = 210h = 8d 18h - also nach knapp 9 Tagen - ein neuer DHCP-Request eines Clients erfolgen (wenn der so lange läuft, ansonsten natürlich beim Reboot/Stecker ziehen/usw).
Eine Lösung mit der Stromversorgung wird also nur dann sicherer, wenn das FAST5460 einwandfrei arbeitet ... und das kann man eben auch testen, ohne daß das Problem direkt aufgetaucht sein muß. Beim Tausch von Geräten und Kabeln würde ich auch nicht "wild" tauschen, sondern dem Problem zunächst an der Quelle (und das ist nun mal das Modem, vor allem nach den Feststellungen in #12) zuleibe rücken (und auch erst mal sauber diagnostizieren, bevor ich
irgendetwas tausche - das erinnert mich an den alten EDV-Witz mit dem platten Autoreifen, der auch erst mal getauscht wird gegen einen der drei anderen, damit man beobachten kann, ob der Fehler dabei mitwandert).
