Vodafone Täglich zwei Verbindungsabbrüche

[sxe]

Hallo zusammen,

da ich mir nicht sicher bin ob es sich hierbei um einen Fehler oder ein Feature handelt frag ich erstmal hier nach und nicht im Störungsforum.
Ich habe seit Monaten oder ggf. sogar schon Jahren das Problem, dass zweimal Täglich zur exact gleichen Zeit die Verbindung zum Router abbricht. Dieser jedoch nicht neu started. Die Verbindung ist etwa 15 Sekunden gestört, danach funktioniert wieder alles normal.
Da mein PC meist dauerhaft läuft kann ich dies schön mit einem log demonstrieren, der ensteht wenn mein Netzwerkinterface die Verbindung zum Router verliert.
Dies passiert auf allen verbundenen Geräten, zur gleichen Zeit, sowohl über LAN als auch WLAN.
Die Logs im Router selber zeigen nichts verdächtiges.

Mein Router:

Firmware-Version: 01.04.046.17.EURO.SIP
Produkt name: Vodafone Docsis 3.1

Beispiel LOG der letzen tage. Dies geht Monate zurück:

Jul 07 09:09:18 main kernel: e1000e 0000:00:1f.6 eno1: NIC Link is Down
Jul 07 15:09:18 main kernel: e1000e 0000:00:1f.6 eno1: NIC Link is Down
Jul 08 08:58:46 main kernel: e1000e 0000:00:1f.6 eno1: NIC Link is Down
Jul 08 09:09:18 main kernel: e1000e 0000:00:1f.6 eno1: NIC Link is Down
Jul 08 15:09:19 main kernel: e1000e 0000:00:1f.6 eno1: NIC Link is Down
Jul 08 15:09:30 main kernel: e1000e 0000:00:1f.6 eno1: NIC Link is Down
Jul 09 09:09:18 main kernel: e1000e 0000:00:1f.6 eno1: NIC Link is Down
Jul 09 09:09:29 main kernel: e1000e 0000:00:1f.6 eno1: NIC Link is Down
Jul 09 15:09:15 main kernel: e1000e 0000:00:1f.6 eno1: NIC Link is Down
Jul 10 09:09:17 main kernel: e1000e 0000:00:1f.6 eno1: NIC Link is Down
Jul 10 15:09:16 main kernel: e1000e 0000:00:1f.6 eno1: NIC Link is Down
Jul 11 09:09:15 main kernel: e1000e 0000:00:1f.6 eno1: NIC Link is Down
Jul 11 15:09:12 main kernel: e1000e 0000:00:1f.6 eno1: NIC Link is Down
Jul 12 09:09:14 main kernel: e1000e 0000:00:1f.6 eno1: NIC Link is Down
Jul 12 15:09:11 main kernel: e1000e 0000:00:1f.6 eno1: NIC Link is Down
Jul 13 09:09:11 main kernel: e1000e 0000:00:1f.6 eno1: NIC Link is Down
Jul 13 11:06:37 main kernel: e1000e 0000:00:1f.6 eno1: NIC Link is Down
Jul 13 11:07:55 main kernel: e1000e 0000:00:1f.6 eno1: NIC Link is Down
Jul 13 11:09:40 main kernel: e1000e 0000:00:1f.6 eno1: NIC Link is Down
Jul 13 17:09:37 main kernel: e1000e 0000:00:1f.6 eno1: NIC Link is Down
Jul 13 17:09:48 main kernel: e1000e 0000:00:1f.6 eno1: NIC Link is Down
Jul 14 11:09:34 main kernel: e1000e 0000:00:1f.6 eno1: NIC Link is Down
Jul 14 11:09:45 main kernel: e1000e 0000:00:1f.6 eno1: NIC Link is Down
Jul 14 17:09:36 main kernel: e1000e 0000:00:1f.6 eno1: NIC Link is Down
Jul 15 11:09:33 main kernel: e1000e 0000:00:1f.6 eno1: NIC Link is Down
Jul 15 11:09:45 main kernel: e1000e 0000:00:1f.6 eno1: NIC Link is Down
Jul 15 17:09:33 main kernel: e1000e 0000:00:1f.6 eno1: NIC Link is Down
Jul 16 11:09:32 main kernel: e1000e 0000:00:1f.6 eno1: NIC Link is Down
Jul 16 11:09:43 main kernel: e1000e 0000:00:1f.6 eno1: NIC Link is Down
Jul 17 11:09:32 main kernel: e1000e 0000:00:1f.6 eno1: NIC Link is Down
Jul 17 11:09:42 main kernel: e1000e 0000:00:1f.6 eno1: NIC Link is Down
Jul 17 17:09:32 main kernel: e1000e 0000:00:1f.6 eno1: NIC Link is Down
Jul 18 11:09:30 main kernel: e1000e 0000:00:1f.6 eno1: NIC Link is Down
Jul 18 17:09:31 main kernel: e1000e 0000:00:1f.6 eno1: NIC Link is Down
Jul 19 11:09:28 main kernel: e1000e 0000:00:1f.6 eno1: NIC Link is Down
Jul 19 17:09:29 main kernel: e1000e 0000:00:1f.6 eno1: NIC Link is Down
Jul 20 11:09:27 main kernel: e1000e 0000:00:1f.6 eno1: NIC Link is Down
Jul 20 11:09:39 main kernel: e1000e 0000:00:1f.6 eno1: NIC Link is Down
Jul 20 17:09:28 main kernel: e1000e 0000:00:1f.6 eno1: NIC Link is Down
Jul 21 11:09:26 main kernel: e1000e 0000:00:1f.6 eno1: NIC Link is Down
Jul 21 17:09:25 main kernel: e1000e 0000:00:1f.6 eno1: NIC Link is Down
Jul 22 11:09:26 main kernel: e1000e 0000:00:1f.6 eno1: NIC Link is Down
Jul 22 11:09:37 main kernel: e1000e 0000:00:1f.6 eno1: NIC Link is Down
Jul 22 17:09:26 main kernel: e1000e 0000:00:1f.6 eno1: NIC Link is Down
Jul 23 11:09:24 main kernel: e1000e 0000:00:1f.6 eno1: NIC Link is Down
Jul 23 11:09:35 main kernel: e1000e 0000:00:1f.6 eno1: NIC Link is Down
Jul 23 17:09:24 main kernel: e1000e 0000:00:1f.6 eno1: NIC Link is Down
Jul 24 11:09:22 main kernel: e1000e 0000:00:1f.6 eno1: NIC Link is Down
Jul 24 11:09:33 main kernel: e1000e 0000:00:1f.6 eno1: NIC Link is Down
Jul 24 17:09:22 main kernel: e1000e 0000:00:1f.6 eno1: NIC Link is Down
Jul 24 17:09:33 main kernel: e1000e 0000:00:1f.6 eno1: NIC Link is Down
Jul 25 11:09:22 main kernel: e1000e 0000:00:1f.6 eno1: NIC Link is Down
Jul 25 11:09:33 main kernel: e1000e 0000:00:1f.6 eno1: NIC Link is Down
Jul 25 17:09:21 main kernel: e1000e 0000:00:1f.6 eno1: NIC Link is Down
Jul 26 09:04:13 main kernel: e1000e 0000:00:1f.6 eno1: NIC Link is Down
Jul 26 11:09:20 main kernel: e1000e 0000:00:1f.6 eno1: NIC Link is Down
Jul 26 17:09:20 main kernel: e1000e 0000:00:1f.6 eno1: NIC Link is Down
Jul 27 11:09:19 main kernel: e1000e 0000:00:1f.6 eno1: NIC Link is Down
Jul 27 17:09:19 main kernel: e1000e 0000:00:1f.6 eno1: NIC Link is Down
Jul 27 17:09:29 main kernel: e1000e 0000:00:1f.6 eno1: NIC Link is Down
Jul 28 11:09:19 main kernel: e1000e 0000:00:1f.6 eno1: NIC Link is Down
Jul 28 17:09:20 main kernel: e1000e 0000:00:1f.6 eno1: NIC Link is Down
Jul 28 17:09:32 main kernel: e1000e 0000:00:1f.6 eno1: NIC Link is Down
Jul 29 10:57:26 main kernel: e1000e 0000:00:1f.6 eno1: NIC Link is Down
Jul 29 11:09:19 main kernel: e1000e 0000:00:1f.6 eno1: NIC Link is Down
Jul 29 11:09:30 main kernel: e1000e 0000:00:1f.6 eno1: NIC Link is Down
Jul 29 17:09:23 main kernel: e1000e 0000:00:1f.6 eno1: NIC Link is Down
Jul 30 11:09:24 main kernel: e1000e 0000:00:1f.6 eno1: NIC Link is Down
Jul 30 11:09:35 main kernel: e1000e 0000:00:1f.6 eno1: NIC Link is Down
Jul 30 17:09:23 main kernel: e1000e 0000:00:1f.6 eno1: NIC Link is Down
Jul 31 11:09:24 main kernel: e1000e 0000:00:1f.6 eno1: NIC Link is Down
Jul 31 17:09:19 main kernel: e1000e 0000:00:1f.6 eno1: NIC Link is Down
Aug 01 11:09:18 main kernel: e1000e 0000:00:1f.6 eno1: NIC Link is Down
Aug 01 17:09:17 main kernel: e1000e 0000:00:1f.6 eno1: NIC Link is Down
Aug 01 17:09:29 main kernel: e1000e 0000:00:1f.6 eno1: NIC Link is Down
Aug 02 06:51:42 main kernel: e1000e 0000:00:1f.6 eno1: NIC Link is Down
Aug 02 07:30:11 main kernel: e1000e 0000:00:1f.6 eno1: NIC Link is Down
Aug 02 07:31:38 main kernel: e1000e 0000:00:1f.6 eno1: NIC Link is Down
Aug 02 07:33:19 main kernel: e1000e 0000:00:1f.6 eno1: NIC Link is Down
Aug 02 07:35:08 main kernel: e1000e 0000:00:1f.6 eno1: NIC Link is Down
Aug 02 07:39:40 main kernel: e1000e 0000:00:1f.6 eno1: NIC Link is Down
Aug 02 07:40:57 main kernel: e1000e 0000:00:1f.6 eno1: NIC Link is Down
Aug 02 13:42:37 main kernel: e1000e 0000:00:1f.6 eno1: NIC Link is Down
Aug 02 19:42:42 main kernel: e1000e 0000:00:1f.6 eno1: NIC Link is Down
Aug 02 19:42:53 main kernel: e1000e 0000:00:1f.6 eno1: NIC Link is Down
Aug 03 08:57:11 main kernel: e1000e 0000:00:1f.6 eno1: NIC Link is Down
Aug 03 14:57:08 main kernel: e1000e 0000:00:1f.6 eno1: NIC Link is Down
Aug 03 14:57:21 main kernel: e1000e 0000:00:1f.6 eno1: NIC Link is Down
Aug 03 20:57:13 main kernel: e1000e 0000:00:1f.6 eno1: NIC Link is Down
Aug 04 06:09:32 main kernel: e1000e 0000:00:1f.6 eno1: NIC Link is Down
Aug 04 08:57:07 main kernel: e1000e 0000:00:1f.6 eno1: NIC Link is Down
Aug 04 08:57:19 main kernel: e1000e 0000:00:1f.6 eno1: NIC Link is Down
Aug 04 14:57:07 main kernel: e1000e 0000:00:1f.6 eno1: NIC Link is Down
Aug 04 14:57:18 main kernel: e1000e 0000:00:1f.6 eno1: NIC Link is Down
Aug 04 20:57:06 main kernel: e1000e 0000:00:1f.6 eno1: NIC Link is Down
Aug 05 08:57:09 main kernel: e1000e 0000:00:1f.6 eno1: NIC Link is Down
Aug 05 14:57:11 main kernel: e1000e 0000:00:1f.6 eno1: NIC Link is Down
Aug 05 20:57:06 main kernel: e1000e 0000:00:1f.6 eno1: NIC Link is Down
Aug 05 20:57:17 main kernel: e1000e 0000:00:1f.6 eno1: NIC Link is Down
Aug 06 08:57:06 main kernel: e1000e 0000:00:1f.6 eno1: NIC Link is Down
Aug 06 08:57:18 main kernel: e1000e 0000:00:1f.6 eno1: NIC Link is Down
Aug 06 14:57:06 main kernel: e1000e 0000:00:1f.6 eno1: NIC Link is Down
Aug 06 20:57:06 main kernel: e1000e 0000:00:1f.6 eno1: NIC Link is Down
Aug 07 08:57:06 main kernel: e1000e 0000:00:1f.6 eno1: NIC Link is Down
Aug 07 08:57:16 main kernel: e1000e 0000:00:1f.6 eno1: NIC Link is Down
Aug 07 14:57:05 main kernel: e1000e 0000:00:1f.6 eno1: NIC Link is Down
Aug 07 14:57:15 main kernel: e1000e 0000:00:1f.6 eno1: NIC Link is Down
Aug 07 20:57:04 main kernel: e1000e 0000:00:1f.6 eno1: NIC Link is Down
Aug 08 08:57:03 main kernel: e1000e 0000:00:1f.6 eno1: NIC Link is Down
Aug 08 08:57:15 main kernel: e1000e 0000:00:1f.6 eno1: NIC Link is Down
Aug 08 14:57:03 main kernel: e1000e 0000:00:1f.6 eno1: NIC Link is Down
Aug 08 20:57:03 main kernel: e1000e 0000:00:1f.6 eno1: NIC Link is Down
Aug 09 08:57:02 main kernel: e1000e 0000:00:1f.6 eno1: NIC Link is Down
Aug 09 14:57:03 main kernel: e1000e 0000:00:1f.6 eno1: NIC Link is Down
Aug 09 14:57:13 main kernel: e1000e 0000:00:1f.6 eno1: NIC Link is Down
Aug 10 08:57:08 main kernel: e1000e 0000:00:1f.6 eno1: NIC Link is Down

Kann mir hier jemand helfen? Ist die ein bekanntes Problem, gibt es Hilfe?

Vielen Dank im Vorraus.

Grüße

 

[tq1199]

Da mein PC meist dauerhaft läuft kann ich dies schön mit einem log demonstrieren, der ensteht wenn mein Netzwerkinterface die Verbindung zum Router verliert.
Dies passiert auf allen verbundenen Geräten, zur gleichen Zeit, sowohl über LAN als auch WLAN.

Starte mal 10 Minuten vor bis 10 Minuten nach der Unterbrechung, auf einem per WLAN verbundenen Gerät:

sudo tcpdump -c 100 -vvveni wlan0 ether proto 0x888e

(wlan0 evtl. anpassen).
... und poste von einem per Kabel verbundenen Gerät, genau und sofort während der Unterbrechung, die Ausgaben von:

arp -a
ip link show
sudo arping -c 3 -I eno1 <IPv4-Adresse-Router>

 

[sxe]

Hey,
danke für die Rückmeldung. Hab dies erst zu spät gesehen, das mein Spam filter die Benachrichtigung gefressen hat.

sudo tcpdump -c 100 -vvveni wlp3s0 ether proto 0x888e

Keine Ausgabe. Gibt allerdings auch nichts aus wenn ich des Interface manuell verbinde. Über networkmanager zum Beispiel.
Ich sehe allerdings das die Verbindung im Networkmanager abbricht und dann neu verbindet. Zudem eine ähnliche Ausgabe im system log, wie im ersten Post angegeben.

arp -a

Keine Ausgabe wärend die Verbindung down ist. Was zu erwarten war, da dies aus meinem initialen log ablesbar ist. Zur Kontroll kanns aber nicht schaden.

ip link show

Wechselt von:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
link/ether f0:2f:74:f7:dc:ff brd ff:ff:ff:ff:ff:ff
altname enp0s31f6

zu:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eno1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN mode DEFAULT group default qlen 1000
link/ether f0:2f:74:f7:dc:ff brd ff:ff:ff:ff:ff:ff
altname enp0s31f6

Was zu erwarten war, da dies aus meinem initialen log ablesbar ist. Zur Kontroll kanns aber nicht schaden.

sudo arping -c 3 -I eno1 192.168.0.1

Keine Ausgabe wärend die Verbindung unterbrochen ist. Steht die Verbindung kommt die normale response.

Also alles in allem sieht man, dass das Interface down geht, da sich vermutlich der Router aus klinkt?

Grüße und schönen Sonntag

 

[tq1199]

..., dass das Interface down geht, da sich vermutlich der Router aus klinkt?

Eigentlich sollte das Interface nicht down gehen, wenn sich der Router ausklinkt.
Warum sage ich das? Z. B. das LAN-Interface einiger meiner Geräte hat zwei IP-Adressen, eine IP aus dem Subnetz vom Router und eine IP aus einem anderen Subnetz. Wenn ich den Router runterfahre, das Netzkabel beim Router ziehe und es mit einem anderen geeigneten Gerät (z. B. Laptop) verbinde, kann ich einen direkte Kabel-Verbindung (z. B. ssh oder telnet oder ...) zwischen dem Laptop und dem Gerät das vorher am Router war, via die 2. IP-Adresse herstellen.
Welchen Router hast Du?

EDIT:

Wenn Du meinst, dass der Router sich ausgeklinkt hat, kannst Du deinen Router dann noch aus dem Internet (z. B. via Mobilfunk oder von einem anderen fremden Internetanschluss oder gleichwertig), je nach Tarif mit nativem IPv4 oder mit nativem IPv6, per Ping oder per TCP-Portscan an einem ins Internet lauschenden TCP-Port am Router, erreichen?
Z. B. ich kann meine FB auch von einem fremden Internetanschluss, mit canyouseeme.org auf einem (evtl. nur temporär) _lauschenden_ TCP-Port (mit nativem IPv4) scannen:

Success: I can see your service on 1##.###.###.### on port 5****)
Your ISP is not blocking port 5****

 

[sxe]

Hi,
es ist im Grunde das gleiche Verhalten als ob ich das Netzwerkkabel aus dem Router ziehe. Dann wechselt das Interface ebenfalls auf DOWN, was meiner Erfahrung nach auch der Normalfall ist. Für mich sieht es so aus als würde die Docsis (genaue Bezeichnung siehe oben) aus irgend einem Grund die Verbindung für 30 Sekunden abbrechen.

Ich hatte zunächst ja auch einen Service oder etwas ähnliches auf meinem PC im Verdacht aber nachdem das gleiche Verhalten auch über das wlan auf meinem Notebook und ebenfalls meinem Android Smartphone und Tablet auftritt muss das aus meiner Sicht entweder die Docsis oder ein aus dem externen Netz getriggerter Event sein. Deswegen hatte ich hier nachgefragt ob so etwas ggf bekannt ist. Spätestens seit COVID ist das vodafone netz ja alles andere als zuverlässig. Zumindest bei mir.

Ich kann die Docsis auch im normalen Betrieb über canyouseeme.org nicht erreichen, da dort selber kein nach außen öffentlicher Service läuft. Ich wüsste auch nicht wie ich dort einen Port öffne um das zu testen.

Grüße und danke für deine Zeit.

 

[MartinP_Do]

Kann das ggfs. wirklich eine kurzzeitige Unterbrechung in der Spannungsversorgung des Kabel-Routers sein?
Was sagen denn die LEDs am Router während der Störung?
Ich kenne die Vodafone Station nicht aus eigener Erfahrung. Gibt es da irgendwelche Loggings oder einen "Uptime" Status in der Web-Oberfläche?

 

[sxe]

Kann das ggfs. wirklich eine kurzzeitige Unterbrechung in der Spannungsversorgung des Kabel-Routers sein?
Was sagen denn die LEDs am Router während der Störung?
Ich kenne die Vodafone Station nicht aus eigener Erfahrung. Gibt es da irgendwelche Loggings oder einen "Uptime" Status in der Web-Oberfläche?

Nein. Der Router leuchtet genauso wie im Normalbetrieb und ich habe auch schon die Steckdose getauscht.

Uptime zeigt die Docsis so an: Zeit seit dem letztem Neustart: Tage, 12 Stunden und 12 Minuten
Die Uptime ist also nicht davon beeinflußt da der letze Disconnect Heute um 8:57 war. Wie jeden Tag.

 

[tq1199]

Ich kann die Docsis auch im normalen Betrieb über canyouseeme.org nicht erreichen, da dort selber kein nach außen öffentlicher Service läuft. Ich wüsste auch nicht wie ich dort einen Port öffne um das zu testen.

OK, es muss ja nicht der TCP-Portscan sein. Kannst Du von einem anderen/fremden Internetanschluss (IPv4 und/oder IPv6) die externe IPv4/6-Adresse deines Routers per Ping (icmp/6) erreichen?

 

[boba]

Es kommt meines Wissens auf die Routerhardware an, wie die sich bei einem Reboot des Routers verhält.
In diesem Fall geht der Link verloren, also etwas was der Port selbst bzw. der Switch bereitstellt, an dem der Port hängt. Reine SoHo Switches (ohne Router) sind üblicherweise als Hardware festverdrahtet ausgelegt und können nicht rebootet werden - sie verlieren ihre Verbindungsfähigkeit nur bei Strom aus.

Wenn ich mich recht erinnere, dann war z.B. bei der Fritzbox 6490 der link (und damit auch die LAN Verbindungen innerhalb des LANs) weg, sobald die Fritzbox rebootet hat. Dort war also im Gegensatz zu einem reinen Switch ein relevanter Teil des Switches von der Software der Fritzbox abhängig.

Bei meiner aktuellen Fritzbox 6591 kann ich mich nicht daran erinnern, dass der Link weg ist, wenn die Fritzbox rebootet. Ist allerdings schon lange her, dass ich sie rebootet habe und gleichzeitig auf den Link geachtet habe. Falls der Link bleibt, wäre der interne Switch wiederum mehr in Hardware. Andererseits sieht man über die Support-Daten, dass die 4 Switch-Ports als einzelne Devices (eth0 bis eth3) im Kernel bekannt sind, d.h. die werden wie 4 einzelne Netzwerkkarten in einem Motherboard gesehen. Der Kernel kennt sie als bridge, sieht also wie ein Software-Switch aus. Inwieweit da Hardware (üblicherweise die MAC Table eines Switches) und Software (individuelle Ansprache von Switch-Ports, auch ggf. unterschiedliche IP Adressen) zusammenspielen, keine Ahnung.

Nach dem letzten Post: hier ist es anders herum - die VF läuft äußerlich weiter, der Switch wird intern resettet.

Das würde meiner Auffassung nur gehen, wenn intern der Switch in Software realisiert wird, also z.B. über das Bridge-Feature des Linux Kernel. Dann kann man das resetten ohne den Kernel neu zu starten. Allerdings gibts hier den Ausfall immer exakt alle 6 Stunden bzw. exakt 6 Stunden nach einem manuellen Neustart. Das ist zu genau als dass es Zufall sein könnte. Ich weiß nicht, was in der Vodafone Station alle 6 Stunden läuft. Da bisher niemand anders von so einem Problem berichtet hat, würde ich einen Defekt der Station in Erwägung ziehen, also irgendein Watchdog, der alle 6 Stunden was nachschaut, erkennt (fälschlich) dass ein Problem mit dem Switch vorliegt und resettet ihn.
Die einzige Möglichkeit, die ich außerhalb der VF sehe, ist dass es problematische angeschlossene Geräte gibt, an denen sich so ein Watchdog stören könnte. Doppelt vergebene MAC Adressen vielleicht, oder irgendwas, was ständig mit neuer MAC Adresse ankommt, und ein Watchdog will präventiv verhindern, dass die MAC Adressen Tabelle des Kernels überläuft (wobei das eigentlich vom korrekt funktionierenden aging automatisch besorgt werden dürfte).

Ist denn auch das WLAN betroffen? Wenn nein, ist es ein reines LAN bzw. Switch Problem, wenn ja, dann ist es was größeres innerhalb der Box.

Mit Ping und tcp/ucp/icmp Connectivity und Portscans würde ich mich hier nicht befassen - soweit ich das sehe, ist das etwas auf Layer 2 (Hardware-Ebene), und nichts, was ab Layer 3 (Verbindungsebene) zum tragen kommen würde. Sehen kann man das Problem anhand des verlorenen Links. Im Moment des Link Verlusts gibts die Möglichkeit der Untersuchung, sonst nicht.

Edit:
Link Detection ist eine Hardware-Sache, siehe hier: https://networkengineering.stackexc...hernet-driver-know-if-the-cable-is-plugged-in
Wenn also das angeschlossene Gerät einen Link-Verlust meldet, dann hat die Hardware vom Switch aufgehört, die link bursts zu senden. Das ist nichts, was man mit Portscans untersuchen könnte, das ist in der Port-Hardware und dem auto-negotiation Protokoll festverdrahtet.
Apropos auto-negotiation: wenn du LAN-Geräte nicht auf auto-negotiation stehen hast, könne das noch als abnormal erkannt werden bzw. Störungen verursachen: stelle alles auf auto-negotiation zurück, falls du es irgendwo mal anders umgestellt hast).

 

[MartinP_Do]

Interessant finde ich, dass es Abstände von 6 Stunden gibt, aber auch Vielfache davon. Manchmal fällt das Ereignis also (teils mehrfach hintereinander) aus ...

 

[sxe]

OK, es muss ja nicht der TCP-Portscan sein. Kannst Du von einem anderen/fremden Internetanschluss (IPv4 und/oder IPv6) die externe IPv4/6-Adresse deines Routers per Ping (icmp/6) erreichen?

Kann ich leider nicht testen da ich aktuell keinen Zugang zu einem anderen System habe. Über die mobilfunk Verbindung meines Smartphone kann ich die Kiste garnicht an pingen. Nur wenn ich per wlan verbunden bin aber dann ist das routing vermutlich intern was mir ja nicht hilft.

Ist denn auch das WLAN betroffen? Wenn nein, ist es ein reines LAN bzw. Switch Problem, wenn ja, dann ist es was größeres innerhalb der Box.

Mit Ping und tcp/ucp/icmp Connectivity und Portscans würde ich mich hier nicht befassen - soweit ich das sehe, ist das etwas auf Layer 2 (Hardware-Ebene), und nichts, was ab Layer 3 (Verbindungsebene) zum tragen kommen würde. Sehen kann man das Problem anhand des verlorenen Links. Im Moment des Link Verlusts gibts die Möglichkeit der Untersuchung, sonst nicht.

Hey boba danke für den ausführlichen Beitrag. Ich sehe das im Grunde wie du. Da es ja scheinbar nur bei mir auftritt ist ein Hardwarefehler oder ein Problem mit dem Anschluss vermutlich das naheligenste. Und ja, wie erwähnt, ist das wlan von der ganzen Sach genauso betroffen wie das LAN.

 

[sxe]

Interessant finde ich, dass es Abstände von 6 Stunden gibt, aber auch Vielfache davon. Manchmal fällt das Ereignis also (teils mehrfach hintereinander) aus ...

Ja, deswegen hatte ich auch Anfangs einen Service auf meinem Gerät im Verdacht. Aber das kann man ja quasi ausschließen wenn mehr als nur ein Gerät betroffen ist.
Die Zeiten haben sich überigen auch schonmal verändert. Ganz am Anfang zum Beispiel lagen die Zeiten so das es mich kaum gestört hat. Deswegen hatte ich das Problem auch lange einfach ignoeriert.

 

[boba]

Man muss mit dem WLAN aufpassen, das wird ja aus Energiespargründen immer unterbrochen, wenn gerade keine IP Verbindung aktiv läuft. Von daher muss eine laufende Datenübertragung genau zu dem 6h-Zeitpunkt hart abbrechen, damit man das als mit dem Ethernet zusammengehörige Unterbrechung deklarieren kann.

Ein Problem mit dem Anschluss, also auf TV-Kabel Seite, würde ich nicht annehmen. Da gibts keine 6h-Pulse. Das einzige, was alle paar Stunden kommt, ist ein dhcp-renew für ipv4. Das Intervall dafür ist tatsächlich recht kurz, aber meiner Erinnerung nach war das bei mir 4h, nicht 6h. Aber selbst wenn, darf das keinen Switch-Reset auslösen. Das ist nirgendwo sonst der Fall. Wie gesagt: niemand sonst berichtet von so einem Problem, so dass ich annehme dass das was spezifisches bei dir ist, und wenn du jetzt kein kaputt konfiguriertes oder fehlerhaftes Ethernet-Gerät am LAN hängen hast, dann würde ich das auf die VF eingrenzen, wo dann am Ende nur ein Tausch in Frage kommt. Wurde die denn schonmal getauscht? Nur wenn das Tauschgerät dasselbe Verhalten zeigt, dann liegts zu 99% nicht an der VF, sondern doch an was VF-externem.

Was das 6h Intervall angeht: ich hatte aufgrund deiner Logs den Eindruck, dass das 6h Intervall startet, nachdem du die VF neu gestartet hattest, möglicherweise auch nachdem sich die VF selbst via docsis neu verbunden hat, und dann eben konstant immer alle 6h. Die Lücken hatte ich so interpretiert, dass da dein Rechner gerade aus ist.

 

[tq1199]

Wenn also das angeschlossene Gerät einen Link-Verlust meldet, dann hat die Hardware vom Switch aufgehört, die link bursts zu senden. Das ist nichts, was man mit Portscans untersuchen könnte, ...

BTW: Niemand hat Portscans aus dem LAN gefordert bzw. vorgeschlagen. Es ging um Ping auf die externe IP-Adresse vom Router bzw. Portscan auf einem evtl. lauschenden TCP-Port des Routers (und nicht um einen weitergeleiteten Port), aus dem Internet, um evtl. von der "anderen Seite" zu sehen bzgl. dem was der TE meint bzw. geschrieben hat (siehe seine Beiträge oben):

... down geht, da sich vermutlich der Router aus klinkt?

... oder ein Problem mit dem Anschluss vermutlich das naheligenste.

 

[sxe]

Es ist eine neue Box ja, da meine "sehr" alte Box defekt war. Die aktuelle Box habe ich am 10.12.21 erhalten, leider reichen meine Logs aber nicht so weit zurück. Ich kann also nicht 100% sagen ob das Problem schon davor bestand. Die ältesten Logs mit Abbrüchen die ich habe sind aus dem März.

Ich hatte mein Notebook auch schon über LAN an der Docsis hängen was zum gleichen Problem führte. Ansonsten ist nurnoch ein Drucker per LAN verbunden der aber aus ist.

Es ist aber kein "normaler" Neustert der Docsis. Ein Neustart dauert ein vielfaches der Zeit. Der Verbindungsabbruch ist ziemlich schnell. Maximal 15 - 30 Sekunden..

 

[sxe]

Was das 6h Intervall angeht: ich hatte aufgrund deiner Logs den Eindruck, dass das 6h Intervall startet, nachdem du die VF neu gestartet hattest, möglicherweise auch nachdem sich die VF selbst via docsis neu verbunden hat, und dann eben konstant immer alle 6h. Die Lücken hatte ich so interpretiert, dass da dein Rechner gerade aus ist.

Ich starte die Docsis nicht manuell neu. Da ich die Logs nur bekomme wenn der Rechner an ist, würde deine Schlussfolgerung Sinn machen, der 6 Stunden intervall stimmt dann aber nicht da ich um 21 Uhr ja einen dritten Disconnect bekommen müsste und der Rechner läuft dann meist noch. Hab gerade gesehen das ich einen Disconnect um 20:57 bekomme. Du hast also recht das die Lücke vermutlich nur dadurch entsteht das der ERchner aus ist.


Ich denke ich schreib einfach mal den Support an. Welche Freude. Ich weiss jetzt schon das die im First Level Support wieder die dämlichsten Fragen stellen werden. Hat jemand ne mail für einen Techniker?

 

[boba]

Ich kenne jetzt nicht direkt deinen Willen zum tüfteln und deine Fähigkeit Dinge einzugrenzen, aber wenn das mein Netz zuhause wäre, und das würde bei mir auftreten, dann würde ich persönlich wie folgt vorgehen, bevor ich eine Störung melde:

- sicherstellen, dass alle LAN Geräte direkt am Router angesteckt sind und keinen externen Switch verwenden
- WLAN auf dem Router ausschalten und schauen, ob das Problem auch bei ausgeschalteten WLAN auftritt
wenn weiterhin auftritt, dann:
- alle LAN Gerät abstöpseln und schauen, ob auf WLAN Geräten das Problem auch dann auftritt
ansonsten auch testen:
- WLAN ausschalten und nur 1 einziges LAN Gerät direkt an Router anschließen.
wenn mit diesem Gerät auch auftritt:
- WLAN ausschalten und nur 1 anderes einziges LAN Gerät direkt an Router anschließen

damit sollte man genug Informationen gesammelt haben, um zu sagen, ob oder dass ein LAN oder ein WLAN Gerät das Problem auslöst, oder ob das Problem tatsächlich komplett unabhängig von angeschlossenen Geräten ist.
Ist es unabhängig: Störung melden, damit du eine andere VF bekommst.

 

[sxe]

Ja gute Idee. Ich teste Morgen mal was passiert wenn ich das wlan auf der Docsis ausschalte und nur mein PC per LAN verbunden ist.

 

[boba]

Du könntest auch noch was anderes probieren: du könntest das TV Kabel abziehen und schauen, ob das Problem dann noch auftritt. Natürlich hast du während der Wartezeit nirgendwo Internet.

 

[sxe]

Ja das mache ich vielleicht sogar als erstes. Doof das ich immer 6 Stunden warten muss.

 

[tq1199]

Ja das mache ich vielleicht sogar als erstes.

BTW: Das würde z. B. bei meinen Geräten nicht funktionieren, weil die sofort merken/"meckern", dass keine funktionierende default route möglich ist bzw. nicht mehr vorhanden ist.
Ich kenne die VF-Station nicht, aber was auf/an der FritzBox funktioniert und Du an der VF-Station evtl. testen könntest, ist, zwei geeignete Geräte per Kabel via VF-Station und mit manuell, statisch zugewiesenen privaten IPv4-Adressen, die _nicht_ aus dem Subnetz der VF-Station sind bzw. _ohne_ konfigurierte default route (weil Internetzugang ja nicht gewollt/erforderlich ist), miteinander zu verbinden. Die Geräte haben nur eine einzige definierte Route, für das Subnetz aus dem die statischen IPv4-Adressen gewählt worden sind.

 

[sxe]

ok, danke für den Hinweis. Ich werde Morgen schauen was passiert wenn ich die Box vom Netz trenne. Ich hoffe einfach mal das die LAN ports dann weiterhin normal funktionieren.

 

[boba]

Ich verstehe nicht, was ihr immer mit IP-Connectivity testen wollt. Das ist ein Link Problem. Hardware-Ebene. Das ist, wie wenn das Kabel abgezogen wird oder der Port ausgeschaltet wird. Mit ipv4 oder default routes hat das überhaupt nichts zu tun. Das wäre wie Wasserqualität prüfen zu wollen aus einer Leitung, in der zum Testzeitpunkt gar kein Wasser fließt.
Den Linkstatus überwacht/meldet der Linux Kernel im kernel log (siehe OP) oder auch auf der Kommandozeile mit ethtool <devicename>.



Unter Windows sieht das z.B. so aus, wenn der link weggeht bzw. wieder kommt:

 

[tq1199]

Ich verstehe nicht, was ihr immer mit IP-Connectivity testen wollt.

Das musst Du auch nicht verstehen.

Das ist ein Link Problem. Hardware-Ebene. Das ist, wie wenn das Kabel abgezogen wird oder der Port ausgeschaltet wird. Mit ipv4 oder default routes hat das überhaupt nichts zu tun. ...
Den Linkstatus überwacht/meldet der Linux Kernel im kernel log (siehe OP) oder auch auf der Kommandozeile mit ethtool <devicename>.

Das wissen wir doch seit dem Beitrag #1:

Aug 09 14:57:13 main kernel: e1000e 0000:00:1f.6 eno1: NIC Link is Down
Aug 10 08:57:08 main kernel: e1000e 0000:00:1f.6 eno1: NIC Link is Down

Da wird auch ethtool nichts anderes anzeigen.

Mit den oben geschilderten Verbindungs-Szenarien (IP-Connectivity), geht es lediglich darum, festzustellen ob bzw. unter welchen Bedingungen dieses Link-Problem (auf Hardware-Ebene) sich ereignet (... oder nicht ereignet). Der Test ist nur eine Ergänzung (die evtl. nicht mehr erforderlich ist), zu dem was Du in deinem Beitrag #17 geschrieben hast.

 

[sxe]

Erster Test um 14:47.

Vorbereitung:

1. Drucker vom Netzwerk getrennt
2. wlan in der Docsis deaktiviert
3. Nur main PC ist mit der Docsis verbunden
4. TV Kabel ist von der Docsis abgezogen, es besteht also keine Internet Verbindung.

Beobachtungen:

1. Nachdem ich das TV Kabel abziehe bleibt die Internet LED der Docsis noch 1-2 Minuten aktiv (weiß leuchtend)
2. Die Internet LED wechselt danach auf rot blinken und das Netzwerkinterface des Rechners geht down. Gleiches Verhalten wie bei den 6 Stunden "disconnects".
3. Zur erwarteten Zeit, 14:47 ist das Netzwerkinterface nicht down gegangen.
4. TV Kabel wieder angesteckt. Die rot blinkende LED wechselt nach ~ 3 - 4 Minuten auf weiss leuchtend.
5. PC hat wieder Internet.
6. Ca 1 Minute DANACH geht das Netzwerk Interface wieder kurzzeitig down (Die Internet LED leuchtet jedoch durchgehen weiss).

Dies hat mich stutzig gemacht und ich habe das nochmal getestet.

Zweite Beobachtung (Spoiler: gleiches Verhalten):

1. Nachdem ich das TV Kabel abziehe bleibt die Internet LED der Docsis noch 1-2 Minuten aktiv
2. Die Internet LED wechselt danach auf rot blinken und das Netzwerkinterface des Rechners geht down. Gleiches Verhalten wie bei den 6 Stunden "disconnects".
3. TV Kabel wieder angesteckt. Die rot blinkende LED wechselt nach ~ 3 - 4 Minuten auf weiss leuchtend.
4. PC hat wieder Internet.
5. Ca 1 Minute danach geht das Netzwerk Interface wieder kurzzeitig down (Die Internet LED leuchtet jedoch durchgehen weiss).

Also ein reproduzierbares Verhalten.

Es sieht also so aus also würde das Fehlverhalten (auch) auftreten, sobald die Docsis die Verbindung zum externen Netz verliert, sobald ich das Kabel ziehe. Mein initiales Problem könnte also durchaus dadurch ausgelöst werden, dass die Docsis in den 6 Stunden Intervallen die Verbindung zum Netz verliert.

Ich werde das wlan Heute mal deaktiviert lassen und sehen was um 20:47 passiert ohne das ich vorher die Docsis vom Netz trenne.