Wer steckt jede Nacht um vier einen USB Stick in meine Fritzbox?

Steckt denn ein realer Stick an der Box ?

Standby vom Drucker mal ausschalten ???

Und, kommt die Meldung auch wenn der Drucker abgesteckt ist?

O.T.: Vermutlich treibt da ein Pumuckl innnerhalb der Familie zu Nachtschlafener Stunde sein Unwesen, oder ein Nachbar nascht da still u. heimlich im ungesicherten W-LAN System mit?

Welcher Vorgang findet um 4:20 statt ?
Erneuerung der IP ?

... "Zwangstrennung durch den Anbieter ..." ? und anschließender Neueinbindung eines USB-Gerätes.

Moin

Zwangstrennung
:gruebel: Möglicherweise versucht die Fritz!Box eine "Ersatzverbindung" über "USB Tethering" aufzubauen

Den Hinweis von koyaanisqatsi gelesen ?

Setz sonst mal die FB zurück und richte diese neu ein. Wohl irgendwas durcheinander in Konfig.

Ist das Menü "Internet" > "Mobilfunk" sichtbar?

Hier für meine 3490:
"Die Mobilfunkverbindung wird bei Ausfall der DSL-Synchronisation aktiviert.
Sobald die DSL-Verbindung wieder für 30 Minuten stabil verfügbar ist, trennt die FRITZ!Box die Mobilfunkverbindung und stellt die DSL-Internetverbindung wieder her."

Warum soll das bei anderen auch auffallen, wenn dort nie so ein Fehler auftritt.
Aber es gibt Leute, die geben immer den Anderen die Schuld, bevor die mal bei sich bzw. in dem Fall bei einer Fritte, selber nachsuchen.

Lies bitte mal den Dunning-Kruger Effekt, genau durch.

Ich tippe auf typisches KKK

Er hat Vodafone Kabelanschluss mit 6490, da gibts kein DSL.

Wenn da nichts an der Box steckt, kann da aber auch kein Tethering stattfinden ... über welches Modell und welche FRITZ!OS-Version reden wir denn hier überhaupt? Über die 6490 aus der Signatur?

Ansonsten werden diese Nachrichten in der Datei "/etc/hotplug/create_handle.sh" erzeugt ... die Frage wäre also vermutlich weniger, wer da ein physikalisches Gerät in die Box steckt als vielmehr, warum da dieses Skript ausgeführt wird.

Eventuell gerät aber auch eine der internen Komponenten (die "Host Controller") aus dem Tritt (z.B. durch irgendeine Stromschwankung, die aus der Nachbarschaft kommen kann (größere Industriegebiete sind da immer einen zusätzlichen Blick wert) oder heutzutage eben auch von irgendwelchen "intelligenten" Haussteuerungen oder -geräten bis hin zur Waschmaschine, die mit (billigerem) Nachtstrom arbeiten soll) und sendet kurzzeitig eine verfälschte Device-ID (aber das kann nicht nur ein einzelner Störimpuls auf der USB-Datenleitung sein, das muß sich schon an ein Protokoll halten) oder macht gar nur ein einfaches Reset und landet dann in der "hotplug"-Verarbeitung. Wobei dann die Frage wäre, warum das nach 11-12 Sekunden wieder verschwindet - wenn das nicht nur ein Timeout ist, weil das Gerät nicht wirklich eingebunden werden kann. Die zugehörige Nachricht stammt dann aber wieder aus der "/etc/hotplug/remove_handle.sh" ... es ist also für alle drei Nachrichten keinesfalls erforderlich, daß da wirklich ein physikalisches Gerät angesteckt oder abgezogen wird.

Das beantwortet zwar die Frage noch nicht, woher diese Aufrufe nun stammen mögen ... will man es genau wissen, müßte man (das FRITZ!OS speichert leider - iirc - keine Angaben dazu, was das für ein Gerät gewesen sein soll) die Protokollierung in diesen beiden Skript-Dateien etwas aufbohren und am besten die komplette Ausgabe von "lsusb" (oder den Inhalt von "/proc/bus/usb/devices" im Falle des x86-Kerns bei der 6490) für das betreffende Gerät ebenfalls speichern - z.B. in einem eigenen Ringpuffer (wenn man es ständig betreiben will) oder in "nummerierten" Dateien im tmpfs ... die Möglichkeiten sind vielfältig.

Die Frage nach der 6490 kam deshalb auf, weil dort diese beiden Skript-Dateien auf dem ATOM-Core ausgeführt werden (und auf dem ARM-Core schon bei den bisherigen Versionen nicht existieren) ... da käme dann ggf. noch ein "Isolationsmangel" bei der CM-Hardware in den Bereich des Möglichen, wo über das BK-Netz ein Störimpuls hereinkommt, der einen der "host controller" zu einem Reset veranlaßt.

Dem ersten Augenschein nach gibt es jedenfalls keine "Sonderbehandlung" für die Host-Controller in den beiden Skript-Dateien ... und auch in den Steuerdateien für den "udevd" (konkret in der "40-usb.rules") gibt es ein paar Abschnitte, die ich überhaupt nicht verstehe ... z.B. diesen:
Das ist für mich (vielleicht verstehe ich es ja auch nur nicht, dann nehme ich entsprechende Erklärungen gerne und dankend zur Kenntnis) mit Verlaub gesagt "bullshit" ... da wird für Drucker, Speichergeräte und Hubs etwas "übersprungen" (nit den GOTOs), was gar nicht vorhanden ist - denn das angesprungene Label ist das, was ohnehin direkt hinter dem letzten Eintrag dort steht - dazwischen gibt es keine einzige andere Anweisung, die an der Behandlung von USB-Geräten irgendetwas ändern würde. Dafür kommt dann gleich danach der Aufruf von "create_handle.sh":
und der erfolgt dann eben auch für die Geräte mit "interface class" == "09" - was nun einmal diese "host controller" sind:
Daher stammt also die Annahme, daß es sich hier auch um einen der USB-Controller-Hubs handeln könnte (die 6490 hat derer auch drei, bei nur zwei nach außen geführten Port und ich habe keine Ahnung, ob am dritten irgendetwas intern hängt oder ob der "dead end" ist), der aus irgendeinem Grund (am ehesten käme da für mich ein elektrischer in Betracht) zurückgesetzt wird und damit "neu startet". Da dort auch eine Art Locking-Mechanismus von AVM benutzt wird und sich diese internen Hubs nur durch die Busnummer unterscheiden, könnte es auch gut sein (so genau bin ich in das Locking da nicht eingestiegen), daß tatsächlich alle drei Hubs neu starten und nur einer davon aber bis zum "create_handle.sh" und damit bis zur Protokollierung kommt, weil die anderen beiden durch das Locking abgewürgt werden.

Wenn ich die AVM-Nummerierung richtig interpretiere, sind jedenfalls 1002, 1003 und 1004 alles Geräte am ersten Bus (001) ... die werden halt hochgezählt, während der Host-Controller eigentlich die 1001 sein sollte. Wenn der nach wie vor vorhanden ist (steht in den Support-Daten), dann fiele allerdings diese "Reset-Idee" aus - insofern kann auch im Nachhinein (quasi bei der Forensik) die Ausgabe von "/proc/bus/usb/devices" (da mountet das FRITZ!OS seinerseits das "usbfs") noch ein paar Anhaltspunkte liefern. Da sollte ja dann irgendwann zwischen 1002 und 1004 auch noch das Gerät 1003 aufgetaucht sein ... auch das müßte eigentlich im Event-Log der Box verzeichnet sein.