20-35 Reconnects pro Nacht nach Analogabschaltung / Kanalumbelegung

[SIGSEGV2]

Hallo Community,

seit der Analogabschaltung bzw. Kanalumbelegung am 05.12.2018 (Netz Schweinfurt) macht meine FRITZ!Box 6490 jede Nacht zwischen ca. 2:45 und 3:45 über den Zeitraum von einer ziemlich genau einer Stunde ständige Reconnects im Abstand von 2-3 min., also ca. 20-35 Reconnects pro Nacht.

Normalerweise brauch ich die Box da nicht... da ich aber die Push-Mail für neue Verbindung/Internet-Adresse aktiviert habe, sind mir die 20-35 Mails jeden Morgen in meiner Mailbox aufgefallen. Teilweise ändert sich die Adresse (nur IPv4... hab ich wegen VPN) dabei auch... vorher war sie über 5 Wochen fast immer gleich.

Der Anschluss wurde erst am 02.11.2018 neu installiert und lief bis zum 04.12.2018 eigentlich problemlos.

Ein Support-Ticket bei AVM hat nichts weiter gebracht, d.h.  aus den Supportdaten der Box konnte seitens AVM kein Fehler erkannt werden und ich wurde auf VF KD verwiesen ==> also Störungsticket bei VF.

Heute war jetzt ein Techniker vor Ort, hat alles nochmal durchgemessen usw., konnte aber auch kein echtes Problem finden. Am Modemkabel war einer der F-Stecker bei der Erstinstallation nicht wirklich sauber verpresst, den hat er sicherheitshalber erneuert. Daran liegt sowas aber zu 99% nicht, da der Anschluss ja die restlichen 23 Stunden pro Tag problemlos läuft und vorher 5 Wochen keine solchen "Aussetzer" hatte.

"Möglich" wäre noch, dass der Netzumbau nach der Analogabschaltung noch nicht ganz abgeschlossen ist, und deshalb nachts "Nacharbeiten" stattfinden, die diese Disconnects/Reconnects auslösen.

Hat jemand im Rahmen bzw. kurz nach einer Analogabschaltung/Kanalumbelegung ähnliche Problenme gehabt?
Falls ja, was war die Lösung? Oder hat sich das nach einer Zeit X (wenn ja X = ???) von selbst erledigt?

Viele Grüße,

SIGSEGV2

[Tobias]

Hey,

ich kann mir gern mal den Anschluss anschauen 🙂 Schickst Du mir mal Deine Kundendaten (Kundennummer, Name, Adresse und Geburtsdatum vom Vertragsinhaber) via privater Nachricht?

Sag mir dann bitte im Beitrag Bescheid, wenn Du mir die Daten geschickt hast.

LG

Tobias

[SIGSEGV2]

Hallo Tobias,

PN mit den Daten ist raus.

Grüße,

SIGSEGV2

[SIGSEGV2]

Hallo Tobias,

wie in der PN schon kurz erwähnt hatte ich gestern nochmal einen Rückruf von der "Techniker-Front", dass ich zu dem Thema auf jeden Fall nochmal ein neues Störungsticket bei VF eröffnen soll, weil "lokal" am Hausanschluss etc. kein Problem gefunden wurde... also diese nächtlichen Abbrüche sind offensichtlich "netzseitig", Grund bisher unklar.

Wenn DU da nix anderes sehen kannst, würd ich das sicherheitshalber noch machen... nicht dass ich dann irgendwann auf den Kosten sitzenbleibe, obwohl "ich nix dafür kann"...

Grüße,

SIGSEGV2

[SIGSEGV2]

Hi Tobias,

hab heute "sicherheitshalber" ein neues Ticket bei VF aufgemacht...
... "vermeintliche Lösung": NOCH EIN TODESSTERN: https://www.youtube.com/watch?v=kNKb-kxHn0c

Neuer (meiner Meinung nach aber zu 100% VÖLLIG SINNLOSER) Techniker-Termin ist jetzt  am 27.12.2018 geplant....
... der erste Techniker-Termin hat aber ja AUCH schon bestätigt, dass das Problem NICHT "auf meiner Seite" liegt 😕

Ich HOFFE, dass da vorher mal "netzseitig" jemand draufschauen kann (DAS kann die "Hotline-Kollegin" wohl NICHT...) die hat nur "neuer Techniker-Termin" als EINZIGE Auswahl???)...

Wenn nicht, kann ich ja "wöchentlich" solche sinnlosen Techniker-Termine einplanen? 😕

Danke & schöne Weihnachtsfeiertage,

SIGSEGV2

[Jens]

Hallo SIGSEGV2,

der Termin ist heute, mal schauen, was dabei heraus kommt.

Sollte danach das immer noch bestehen, warte mit einem Anruf und melde Dich erst einmal hier. 🙂

Gruß

Jens

[SIGSEGV2]

Hallo Jens,

kurz vor 10:00 Uhr kam ein Anruf, dass der Termin heute nicht klappt und auf den 29.12. verschoben werden muss

Falls du diese Reconnects an meinem Anschluss "sehen" kannst... kannst du sehen, ob dasselbe auch an anderen Anschlüssen am gleichen Verteiler (z.B. Hausnr. 32 in derselben Straße) auftreten?

Ich bin mir weiter ziemlich sicher, dass es nicht auf meiner Seite liegt. Das hatte der erste Technikertermin ja soweit auch bestätigt.

Danke & Grüße,

SIGSEGV2

[SIGSEGV2]

Hallo Jens,

der zweite Termin war "so erfolgreich wie der erste"... an meiner Hausinstallation oder der FRITZ!Box liegt es nicht.

Das Modem Monitoring zeigt auch keine Reboots an (weder bei mir noch auf Hausnr. 32), also die Box macht keinen vollständigen Reset, sondern nur diese mehrfachen Reconnects.

Der Techniker meinte, dass es neuerdings so eine Art "24h-Zwangstrennung" gäbe, also so ähnlich wie früher bei DSL-Anschlüssen. Aber dafür würde ja ein Reconnect ausreichend und man bräuchte keine 20-35 über einen Zeitraum von einer Stunde.

Neue Vermutung: Probleme bzw. Konfigurationsfehler auf Seite der CMTS...

Dazu ist mir dann noch was eingefallen: In den Kabel-Einstellungen der FRITZ!Box gibt es u.a. einen Parameter für die "Startfrequenz" bei der Kanalsuche.

Ich weiß nicht, was hier vor der Kanalumbelegung stand (hatte ich nie nachgeschaut), aber nachdem die Probleme angefangen haben, habe ich dort den Wert 306 MHz gefunden, was bei der DOCSIS-Kanalbelegung im Netz Schweinfurt wenig Sinn macht.

Allerdings scheint die Box diesen Parameter zu ignorieren, weil trotz der dort angegebenen 306 MHz die weiter unten liegenden DS-Kanäle ab 138 MHz genutzt werden. Daran liegt es also vermutlich auch nicht.

Eine Veränderung des Parameters (mehrere Werte an verschiedenen Tagen ausprobiert) hat auch keine Veränderung gebracht, aktuell hab ich dort jetzt die 138 MHz eingetragen, wo der erste DS-Kanal liegt.

An meinem anderen Anschluss (Raum Nürnberg) steht hier schon immer der Wert 0, der sich aber manuell gar nicht eintragen lässt.

Könnt ihr euch bitte mal die CMTS-Seite anschauen, ob dort eine fehlerhafte Konfiguration vorliegt bzw. ob man evtl. aus den Logs auf dieser Seite erkennen kann, wodurch die Abbrüche ausgelöst werden?

Danke & Grüße,

SIGSEGV2

[pRo-Marco]

Hallo SIGSEGV2,
 
ich kann es sehen, dass beim Anschluss die nächtliche Unterbrechung vorkommt.
Der Techniker konnte jedoch nichts an der Leitung feststellen. Also wäre mal ein Werksreset der Box notwendig, wo Du nur die nötigsten Einstellungen ( z.B. W-LAN Passwort und Rufnummereinstellungen) vornimmst aber nichts für das Netzwerk.
 
Gruß
Marco

[SIGSEGV2]

Hallo Marco,

der Werksreset hat leider auch nichts gebracht.

Nach dem Reset hat die Box ca. 10 min. gebraucht, bis ein erster Sync zustande kam (Anzeige "Übertragung der Betriebsparameter und Registrierung an der CMTS" in den Kabel-Informationen).

Ca. 20 min. danach hab ich die Box sicherheitshalber nochmal kurz vom Strom getrennt und neu gestartet.

Leider kamen nachts gegen 2:45 Uhr wieder die 35 Reconnects

Ich hab jetzt mal die Support-Daten von dieser FB 6490 mit denen von meinem anderen Anschluss verglichen und nach Unterschieden gesucht. Folgendes hab ich gefunden:

1. Am Anschluss mit dem Fehler wird eine CMTS vom "Arris" verwendet, am anderen eine von "Casa Systems".

2. Das Interface mta0 ist anders konfiguriert. Im Gegensatz zum zweiten Anschluss sind zusätzlich die Flags DEBUG, NOTRAILERS, NOARP, PROMISC, ALLMULTI gesetzt:

PACM MTA iface
--------------
mta0      Link encap:Ethernet  HWaddr xx:xx:xx:xx:xx:xx  Media:unknown(auto)
          UP BROADCAST DEBUG NOTRAILERS RUNNING NOARP PROMISC ALLMULTI MULTICAST  MTU:1500  Metric:1
          RX packets:1337805 errors:0 dropped:0 overruns:0 frame:0
          TX packets:796 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 

3. Im DOCSIS CM Eventlog sehe ich beim Anschluss mit den nächtlichen Reconnects folgende DHCP-Fehlermeldungen:

##### BEGIN SECTION cmlog Cablemodem eventlog

DOCSIS CM Eventlog:
  124: 2019-01-03 03:35:33 68000301 critical  DHCP FAILED - Critical field invalid in response
  125: 2019-01-03 03:35:33 68010700 error     Primary lease failed, IPv4 fallback initiated
  126: 2019-01-03 03:35:37 90000000 warning   MIMO Event MIMO: Stored MIMO=-1 post cfg file MIMO=-1
  127: 2019-01-03 03:35:37 82000200 critical  No Ranging Response received - T3 time-out
  128: 2019-01-03 03:37:11 68000301 critical  DHCP FAILED - Critical field invalid in response
  129: 2019-01-03 03:37:11 68010700 error     Primary lease failed, IPv4 fallback initiated
  130: 2019-01-03 03:37:14 90000000 warning   MIMO Event MIMO: Stored MIMO=-1 post cfg file MIMO=-1
  131: 2019-01-03 03:38:52 68000301 critical  DHCP FAILED - Critical field invalid in response
  132: 2019-01-03 03:38:52 68010700 error     Primary lease failed, IPv4 fallback initiated
  133: 2019-01-03 03:38:56 90000000 warning   MIMO Event MIMO: Stored MIMO=-1 post cfg file MIMO=-1
  134: 2019-01-03 03:40:32 68000301 critical  DHCP FAILED - Critical field invalid in response
  135: 2019-01-03 03:40:32 68010700 error     Primary lease failed, IPv4 fallback initiated
  136: 2019-01-03 03:40:36 90000000 warning   MIMO Event MIMO: Stored MIMO=-1 post cfg file MIMO=-1
  137: 2019-01-03 03:42:13 68000301 critical  DHCP FAILED - Critical field invalid in response
  138: 2019-01-03 03:42:13 68010700 error     Primary lease failed, IPv4 fallback initiated
  139: 2019-01-03 03:42:18 90000000 warning   MIMO Event MIMO: Stored MIMO=-1 post cfg file MIMO=-1
  140: 2019-01-03 03:43:55 68000301 critical  DHCP FAILED - Critical field invalid in response
  141: 2019-01-03 03:43:55 68010700 error     Primary lease failed, IPv4 fallback initiated
  142: 2019-01-03 03:43:58 90000000 warning   MIMO Event MIMO: Stored MIMO=-1 post cfg file MIMO=-1
  143: 2019-01-03 03:43:58 82000200 critical  No Ranging Response received - T3 time-out
##### END SECTION cmlog

Ich bin mir ziemlich sicher, dass diese DHCP-Fehler die Ursache für die Abbrüche sind, da zu dem Zeitpunkt (bzw. nach Ablauf der nicht erneuerten DHCP Lease) dann die IP-Adresse der Box "verloren" geht.

Vermutlich wird hier ein DHCP RENEW versucht, um das DHCP Lease (rechtzeitig vor Ablauf) zu verlängern, was aber für ca. eine Stunde konsequent immer wieder fehlschlägt.

Welches field hier in der DHCP response genau invalid ist, kann ich nur raten (das "Packet capturing" in der FB 6490 hat vodafone ja leider deaktiviert... sonst könnte man darüber einen Paketmitschnitt erzeugen ).

In anderen Foren hab ich Beispiele gefunden, wo in der DHCP response von der CMTS das "tid"-Field (DHCP Transaction ID) auf 0 gesetzt ist, wodurch die DHCP response von der CMTS nicht dem DHCP request der Box zugeordnet werden kann. Ob das hier auch zutrifft, kann ich nur raten... es könnte auch ein anderes Feld falsch gesetzt sein.

Da die ungültige DHCP response aber von der CMTS kommt, liegt der Fehler zu 100% auf Seite der CMTS.

Warum ein DHCP server 23 Stunden lang korrekte DHCP responses sendet und genau eine Stunde lang solche mit "invalid fields", ist mir aber unklar... evtl. macht der DHCP server auf der CMTS-Seite dann seinerseits gegen 3:45 Uhr einen Reset, und ab dann funktioniert's wieder

Könnt ihr bitte prüfen, wie die DHCP responses der CMTS hier konkret aussehen, also

- im fraglichen Zeitraum zwischen jeweils 2:45-3:45 Uhr, wo sie fehlerhaft sind

- außerhalb dieses Zeitraums, wo ja keine solchen Fehler zu sehen sind

Ich kann ggf. auch nochmal ein zweites Ticket bei AVM eröffnen, falls ihr das für sinnvoll haltet.

Das hatte ich aber ja schon ganz am Anfang, als das Problem angefangen hatte... und der AVM-Support konnte kein Problem in der FB 6490 erkennen.

Danke & Grüße,

 SIGSEGV2