[gelöst] Netzwerkverlust

[gambit]

Hallo zusammen,

mein Rechner verliert beim Einschalten das Netzwerk. Die Verbindung des LAN-Kabels zum Router (Fritzbox) wird vor dem Einschalten des Rechners mit einer grünen Lampe am Rechner signalisiert. Unmittelbar nach dem Einschalten erlischt die Lampe. Nach der Anmeldung ist ein ping zu 8.8.8.8 nicht möglich, bzw. wird die Unerreichbarkeit des Netzwerks angezeigt.
Networkmanager ist aktiv:

Code: Alles auswählen

$ systemctl status NetworkManager.service
● NetworkManager.service - Network Manager
   Loaded: loaded (/lib/systemd/system/NetworkManager.service; enabled)
   Active: active (running) since So 2016-05-08 14:37:07 CEST; 9min ago
 Main PID: 589 (NetworkManager)
   CGroup: /system.slice/NetworkManager.service
           └─589 /usr/sbin/NetworkManager --no-daemon

Mache ich, während der Rechner läuft, den Router stromlos und schalte ihn sodann wieder ein, leuchtet nach kurzer Zeit die grüne sowie ein gelbe Kontrollleuchte am Rechner. Anschließend funktioniert das Netzwerk normal.
Ich habe versucht, das Problem durch Deaktivierung des Networkmanagers und eine Eintragung "auto eth0" in /etc/network/interfaces zu lösen (nach Maßgabe network_manager_README.Debian), aber das hat das Problem nicht beseitigt. Ich bin deshalb wieder zum Ausgangszustand zurückgekehrt.

interfaces zeigt jetzt wieder:

Code: Alles auswählen

 source /etc/network/interfaces.d/*
# The loopback network interface
auto lo
iface lo inet loopback

Vorab zu meinem System folgende Info:

Code: Alles auswählen

System:    Kernel: 3.16.0-4-amd64 x86_64 (64 bit) Desktop: Openbox 3.5.2 
                 Distro: BunsenLabs 8.4 bunsen-hydrogen 
Machine:  System: Hewlett-Packard product: HP Compaq Elite 8300 CMT
                Mobo: Hewlett-Packard model: 3396 Bios: Hewlett-Packard v: K01 v02.05 date: 05/07/2012
CPU:       Quad core Intel Core i5-3470 (-MCP-) cache: 6144 KB 
                Clock Speeds: 1: 1718 MHz 2: 3513 MHz 3: 3463 MHz 4: 3490 MHz
Network:  Card: Intel 82579LM Gigabit Network Connection driver: e1000e           
                IF: eth0 state: up speed: 100 Mbps duplex: full mac: 10:60:4b:81:76:38

Ich weiß leider nicht, welche weiteren spezifischen Informationen erforderlich sind, nutze Linux (zuvor openSuse) zwar schon einige Zeit, aber nur als "Konsument" und bin gerade erst auf ein Debian basiertes System umgestiegen.

Vielen Dank für euer Interesse,

gambit

[TomL]

Kannst Du das Interface von Hand öffnen?

Code: Alles auswählen

/sbin/ip link set dev eth0 up 
/sbin/ip addr show

[gambit]

Kannst Du das Interface von Hand öffnen?

Code: Alles auswählen

/sbin/ip link set dev eth0 up 
/sbin/ip addr show

Hallo Thomas, vielen Dank für Deine Antwort.

Ich weiß nicht, ob Deine Frage richtig verstehe wenn ich "/sbin/ip link set dev eth0 up" ohne 'sudo' eingebe, kommt "RTNETLINK answers: Operation not permitted", mit "sudo" und Rootpasswort ('sudo' ist so konfiguriert) kommt nur ein neuer prompt.
Mit 'sudo nano /sbin/ip link set dev eth0 up' sehe ich nur verschlüsselten Text.

'/sbin/ip addr show' zeigt:

Code: Alles auswählen

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 10:60:4b:81:76:38 brd ff:ff:ff:ff:ff:ff
    inet 192.168.178.21/24 brd 192.168.178.255 scope global dynamic eth0
       valid_lft 853593sec preferred_lft 853593sec
    inet6 fe80::1260:4bff:fe81:7638/64 scope link 
       valid_lft forever preferred_lft forever

[TomL]

Mit 'sudo nano /sbin/ip link set dev eth0 up' sehe ich nur verschlüsselten Text.

Das geht auf gar keinen Fall! Wenn dann ohne "nano" (nano ist ein Text-Editor)

Code: Alles auswählen

sudo /sbin/ip link set dev eth0 up

Am besten wäre es, vor Eingabe von Befehlen zum System-Customizing einfach mit "su" zu root zu werden. Dann braucht man diesen verwirrenden (und völlig unnötigen) sudo-Quatsch auch nicht mehr.

Aber wenn ich das richtig sehe, steht doch die Netzwerkverbindung. Du hast doch eine IP Deines Routers.... also ist das Netzwerk auch verbunden. Mach mal kurz Deinen Router stromlos und starte ihn damit mal neu durch... vielleicht hat der sich irgendwie weghängt....

Code: Alles auswählen

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    inet 192.168.178.21/24 brd 192.168.178.255 scope global dynamic eth0

[gambit]

also

Code: Alles auswählen

 sudo /sbin/ip link set dev eth0 up

gibt als root nur wieder einen leeren Eingabeprompt

Aber wenn ich das richtig sehe, steht doch die Netzwerkverbindung. Du hast doch eine IP Deines Routers.... also ist das Netzwerk auch verbunden. Mach mal kurz Deinen Router stromlos und starte den mal neu durch... vielleicht hat der sich irgendwie weghängt....
CODE: ALLES AUSWÄHLEN
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 10:60:4b:81:76:38 brd ff:ff:ff:ff:ff:ff
inet 192.168.178.21/24 brd 192.168.178.255 scope global dynamic eth0

Ich habe mich wohl unklar ausgedrückt: Im Moment habe ich eine normale Verbindung zum Netz (ich schreibe jetzt von dem besagten Rechner). Das Problem besteht, wenn ich den Rechner aus ist und ich ihn dann einschalte. Dann verliert er das Netz (grüne Lampe neben der LAN-Kabelbuchse am Rechner erlischt) bzw. er erkennt es nicht.

Diesen Zustand kann ich nur durch Stromlosmachung des Routers und dessen anschließendes Wiedereinschalten beheben. Dann leuchten diese beiden Lämpchen (grün und gelb) nach kurzer Zeit wieder und ich habe ganz normale Verbindung zum Netz.

Mach mal kurz Deinen Router stromlos und starte den mal neu durch... vielleicht hat der sich irgendwie weghängt....

Das was ich zuvor beschrieben habe (zunächst keine Netzwerverbindung nach Rechnerstart -- Router stromlos machen -- Netzwerkverbindung ist da) ist beliebig reproduzierbar.

[TomL]

Code: Alles auswählen

 sudo /sbin/ip link set dev eth0 up

gibt als root nur wieder einen leeren Eingabeprompt

Das zu versuchen wenn der Rechner bereits verbunden ist, nachdem Du Deinen Router zuvor neu gestartet hast, ist natürlich Unsinn. Versuche es bitte dann, wenn Du meinst, dass das Netz NICHT verbunden ist. Dabei geht es darum festzustellen, ob vielleicht eine Fehlermeldung im Terminal kommt. Und versuch es ohne den Zusatz "sudo", stattdessen vorher mit "su" root werden.

Code: Alles auswählen

su
ip addr show
ip link set dev eth0 up

Das ist eigentlich ganz einfach, zuerst root werden, dann den Istzustand prüfen, und wenn das Interface "down" ist, einfach mal von Hand öffnen. Wenn "ip" nix antwortet, dann mal suchen, ob "ip" überhaupt installiert ist.

Code: Alles auswählen

which ip

Wenn auf diesem Wege wg. fehlendem 'ip' nix herauszubekommen ist, dann eben über die /etc/interfaces und

Code: Alles auswählen

ifconfig
ifup eth0
ifdown eth0

Das für mich jetzt im Moment nicht greifbare Randproblem ist der Networkmanager..... schlimmstenfalls würde ich den zum Testen kurz stoppen. Um das Problem zu lösen, muss man die Ursachen eingrenzen... isses der NWM, oder das DHCP des Routers, oder der DHCP-Client des Rechners, oder noch was ganz anderes...? Also erst mal schauen, ob beim wichtigsten (dem Connect) schon Fehlermeldungen kommen.

[mat6937]

... bin gerade erst auf ein Debian basiertes System umgestiegen.

Um welches Debian basiertes System geht es?

[gambit]

@TomL

Das zu versuchen wenn der Rechner bereits verbunden ist, nachdem Du Deinen Router zuvor neu gestartet hast, ist natürlich Unsinn.

Ja, das war ein Missverständnis

Versuche es bitte dann, wenn Du meinst, dass das Netz NICHT verbunden ist. Dabei geht es darum festzustellen, ob vielleicht eine Fehlermeldung im Terminal kommt.

Ja, das mach ich, sobald die Netzverbindung ungewünscht fehlt, und berichte dann hier weiter.

@mat6937

Hallo,
das ist BunsenLabs 8.4 bunsen-hydrogen (i. Übr. siehe mein Ausgangsposting)

[mat6937]

... sobald die Netzverbindung ungewünscht fehlt, und berichte dann hier weiter.

Poste dann auch die Ausgaben von:

Code: Alles auswählen

cat /lib/systemd/system/NetworkManager.service

Code: Alles auswählen

systemd-analyze blame

Code: Alles auswählen

systemctl list-units | grep -iE 'target|device'

[NAB]

gambit, nur um andere Fehlerursachen auszuschließen: Unter Suse war das kein Problem? Und da wurde auch das gleiche LAN-Kabel verwendet? Und das LAN-Kabel steckte auch in der gleichen Buchse der Fritzbox?

[TomL]

Und da wurde auch das gleiche LAN-Kabel verwendet? Und das LAN-Kabel steckte auch in der gleichen Buchse der Fritzbox?

Irritierend ist, dass es ja funktioniert, wenn er kurz den Router stromlos macht. Danach ist er ja sauber verbunden. Also kann es doch eigentlich nix Hardwaremäßiges sein...oder? Ich glaube, dass das Problem Softwareseitig verursacht wird... und irgendwie kommt mir immer wieder DHCP in den Sinn.... und da entweder der NWM oder der DHCP-Client. Bin mal gespannt darauf, wie sich das auflöst.

[mat6937]

... und irgendwie kommt mir immer wieder DHCP in den Sinn.... und da entweder der NWM oder der DHCP-Client. Bin mal gespannt darauf, wie sich das auflöst.

BTW: Ich habe ein ähnliches Problem, und das liegt bei mir daran, dass "systemd-networkd.service" manchmal zu früh gestartet wird:

Code: Alles auswählen

:~ $ systemd-analyze blame | grep -i systemd-networkd.service
            82ms systemd-networkd.service

Ich nutze kein DHCP und kein NWM, die Konfiguration ist bei mir statisch und mit Hilfe einer unit-Datei (... d. h. nicht die interfaces-Datei). Als workaround habe ich einen cronjob, der systemd-networkd.service restartet, wenn das Interface keine IP-Adresse sofort nach dem booten hat.

Diverse Abhängigkeiten/Reihenfolgen in der unit-Datei habe ich auch schon probiert, hat aber (noch) nicht geholfen.

[TomL]

BTW: Ich habe ein ähnliches Problem, und das liegt bei mir daran, dass "systemd-networkd.service" manchmal zu früh gestartet wird:

Zu früh für 'was'? Ich glaube, dass du an dem Punkt auf falscher Fährte bist. Kontrolliere mal die runlevels, ob 'networking' noch irgendwo gestartet wird. Das sieht eher nach Konflikten wg. Konkurrenz aus. Einen workaround oder gar cronjob braucht es hier eigentlich nicht.

[mat6937]

Zu früh für 'was'?

Zu früh um mit Hilfe der *.network-Datei, die statische IP-Adresse zugewiesen zu bekommen.

Ich glaube, dass du an dem Punkt auf falscher Fährte bist. Kontrolliere mal die runlevels, ob 'networking' noch irgendwo gestartet wird. Das sieht eher nach Konflikten wg. Konkurrenz aus.

Nein, "networking" war und ist inaktiv, weil disabled (d. h. auch keine S*-symlinks auf "/etc//init.d/networking" mehr vorhanden, in den runlevels):

Code: Alles auswählen

:~ $ systemctl status networking.service
● networking.service - LSB: Raise network interfaces.
   Loaded: loaded (/etc/init.d/networking)
  Drop-In: /run/systemd/generator/networking.service.d
           └─50-insserv.conf-$network.conf
        /lib/systemd/system/networking.service.d
           └─network-pre.conf
   Active: inactive (dead)

BTW: /etc/init.d-Scripte würde ist mit systemd eher nicht (d. h. nur wenn es anders nicht geht) nutzen, weil systemd angeblich "# Required-Start: ..."-Reihenfolge (noch) nicht berücksichtigt.

[TomL]

Wenn ich das nicht völlig falsch verstanden habe, ist systemd-networkd derjenige Dienst, der die Interfaces öffnet und gemäß der Datei /etc/systemd/network/*.network den connect durchführt. In dieser Kombination ist ein zu früh m.e. nicht gegeben.

[mat6937]

..., ist systemd-networkd derjenige Dienst, der die Interfaces öffnet und gemäß der Datei /etc/systemd/network/*.network den connect durchführt. In dieser Kombination ist ein zu früh m.e. nicht gegeben.

Mein workaround loggt auch die Fälle wenn ein restart des systemd-networkd erforderlich ist (, damit das Interface die statische IP-Adresse bekommt). Wenn ich mir in so einem Fall in der Ausgabe von "systemd-analyze blame" die Zeit in der der systemd-networkd-Dienst initialisiert wird anschaue und vergleiche die Initialisierungs-Zeit bei der problemlosen Zuweisung der IP-Adresse, dann ist im Problemfall die Initialisierungs-Zeit für den systemd-networkd-Dienst, immer wesentlich kürzer/niedriger.

Was ich noch nicht verglichen habe ist, ob "sys-subsystem-net-devices-eth0.device", immer vor "systemd-networkd.service" aktiviert wird:

Code: Alles auswählen

:~ $ systemctl status sys-subsystem-net-devices-eth0.device | grep -i active
   Active: active (plugged) since Mon 2016-05-09 10:44:52 CEST; 2h 36min ago

Code: Alles auswählen

:~ $ systemctl status systemd-networkd.service | grep -i active
   Active: active (running) since Mon 2016-05-09 10:44:54 CEST; 2h 37min ago

[TomL]

Wie ich schon sagte ...meiner Meinung nach falsche Fährte. Das Kernel-Modul für das NIC hat imho gar nix mit dem Start des Netzwerks zu tun. Soll heissen, das Kernel-Modul wird auch dann geladen, wenn das Netzwerk überhaupt nicht verbunden wird, oder später (lange nach dem Boot) manuell gestartet wird. Und das Kernel-Modul für das NIC (Device eth0) muss IMMER vor dem Netzwerkstart geladen werden.... und das hat zu diesem Zeitpunkt überhaupt nichts mit einer späteren IP-Adresse zu tun. Natürlich ist klar, dass ohne Kernel-Modul das NIC gar nicht betrieben werden kann.

Ist das Kernel-Modul geladen kann systemd-networkd (irgendwann) dieses Interface zuerst 'öffnen' und dann gemäß der Einstellung in der *.network mit dem Host des Netzwerks resp. Router verbinden... entweder via DHCP-Client oder eben mit Static-IP. Ein "zu Früh" gibt es hier nicht, weil systemd-networkd immer nach den Kernel-Modulen aktiv ist. Außerdem musst du zwischen Kernel-Messages und 'anderen' unterscheiden.

[mat6937]

Ein "zu Früh" gibt es hier nicht, weil systemd-networkd immer nach den Kernel-Modulen aktiv ist. Außerdem musst du zwischen Kernel-Messages und 'anderen' unterscheiden.

Das ist ja plausibel was Du schreibst, aber was ist dein konkreter Vorschlag um das Problem zu lösen?

[TomL]

Das ist ja plausibel was Du schreibst, aber was ist dein konkreter Vorschlag um das Problem zu lösen?

Dazu müsste man jetzt erst mal wissen, was Du getan hast, um dieses Problem zu verursachen... ... bitte jetzt nicht persönlich nehmen. Wenn Du z.B. deinen Static-IP-Gedanken als HowTo im Web gesucht/gegooglet hast und vielleicht dabei das hier gefunden hast: https://wiki.archlinux.de/title/Statische_IP
dann frage ich mich "warum einfach, wenn es auch kompliziert geht?" Ich habe dieses Verfahren nicht getestet, aber allein beim drübersehen scheinen mir Timeouts und damit verbundene Inkonsistenzen im weiteren Ablauf denkbar. Das Unit-Statement "After=subsystem*eth0.device" in systemd-networkd bedeutet nur, dass systemd-networkd danach gestartet wird, aber eben nicht zwingend, dass solange gewartet wird, bis dieser ganze subsystem-Kram hier erfolgreich durch ist. Ausserdem wird dazu systemd-networkd sowieso konkurrierend laufen... das heisst, das braucht man eigentlich bei einer solchen Lösung gar nicht.

Ich würde jetzt erst mal alles auf Null zurücksetzen und deaktivieren, was Du bisher für das Netzwerk oder am Netzwerk geschraubt oder als Workaround eingerichtet hast.Und irgendwelche geänderten systemd-Services wieder auf den Originalzustand zurücksetzen. Das heisst, alle manipulierten oder eigenen Services, Dienste und Cronjobs (fürs Netzwerk) deaktivieren, so das gar kein Netzwerk gestartet wird. Und danach dann das Netzwerk neu einrichten.

Prüfen: Netzwerk ist nach Reboot down, keine IP

Code: Alles auswählen

ip addr show

Dann wird diese Datei angelegt und...

Code: Alles auswählen

nano /etc/systemd/network/eth0.network

...mit diesem Inhalt die Static-IP im Netz gesetzt (die IP-Adresse "dieses" Rechners und das Gateway musst Du natürlich auf Deine Gegebenheiten ändern):

Code: Alles auswählen

[Match]
Name=eth0

[Network]
# DHCP=v4
  Address=10.10.1.4/24
  Gateway=10.10.1.1

Soll die IP via DHCP bezogen werden, den Comment-Tag # bei DHCP entfernen und dafür jeweils vor Address und Gateway einen # setzen. Dann noch die Rechte setzen:

Code: Alles auswählen

chmod 644 /etc/systemd/network/eth0.network
chown root:root /etc/systemd/network/eth0.network

Jetzt das Netzwerk einrichten... zuerst systemd-resolved (natürlich wieder Dein Gateway eintragen):

Code: Alles auswählen

nano /etc/systemd/resolved.conf 

Code: Alles auswählen

    [Resolve]
    DNS=10.10.1.1

Prüfen:

Code: Alles auswählen

systemctl start systemd-resolved.service; systemctl status systemd-resolved.service

Fertig machen:

Code: Alles auswählen

[ -f /etc/resolv.conf ] && rm /etc/resolv.conf
ln -sf /run/systemd/resolve/resolv.conf /etc/resolv.conf
systemctl restart systemd-resolved.service

Prüfen:

Code: Alles auswählen

ls /etc/resolv.conf
     lrwxrwxrwx 1 root root 32 Mai  9 15:26 /etc/resolv.conf -> /run/systemd/resolve/resolv.conf
cat /etc/resolv.conf
     nameserver 10.10.1.1

Netzwerk starten und prüfen, ob verbunden wird:

Code: Alles auswählen

ip addr show
systemctl start systemd-networkd.service
systemctl start systemd-networkd-wait-online.service
ip addr show
systemctl status systemd-networkd systemd-resolved systemd-networkd-wait-online

Wenn keine Fehler berichtet werden, für den nächsten Boot aktivieren, ansonsten zuerst die Fehler beheben:

Code: Alles auswählen

systemctl enable systemd-networkd.service
systemctl enable systemd-networkd-wait-online.service
systemctl enable systemd-resolved.service

[gambit]

Entschuldige, das hat etwas gedauert. Arbeiten geht halt vor.

Nachdem der Rechner stromlos war (da komme ich später nochmal drauf zurück), gleiches Problem: Netz nicht erreichbar.

Dann, jeweils als su, habe ich Folgendes eingegeben:

Code: Alles auswählen

ip addr show:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
    link/ether 10:60:4b:81:76:38 brd ff:ff:ff:ff:ff:ff

Code: Alles auswählen

ip link set dev eth0 up:

ergibt nur einen neuen prompt

Code: Alles auswählen

ifup eth0

gnoring unknown interface eth0=eth0.

Code: Alles auswählen

ifdown eth0 :

ifdown: interface eth0 not configured

Ich habe das ganze nochmal rekonstruiert. Ich meine, das Verhalten des Rechners hätte gewechselt, aber ich bin unsicher, weil ich soviel probiert habe.
Zuletzt war es so:
Wenn ich den Rechner ausschalte, aber nicht stromlos mache, leuchtet die grüne Lampe an der LAN-Buchse weiter. Schalte ich den Rechner wieder ein, kommt normal eine Netzwerkverbindung zustande.
War der Rechner (zB über Nacht) komplett stromlos uns ich schalte ihn dann wieder ein, kommt keine Netzwerkverbindung zustande, bis ich den Router stromlos mache und ihn dann wieder einschalte. Aber auch danach, zeigt ein Ping zunächst, dass keine Netzwerkverbindung besteht. Nach einiger Zeit kommt die Verbindung dann zustande.

Ergänzung: Ein Reboot zerstört die laufende Netzwerkverbindung auch nicht

[gambit]

gambit, nur um andere Fehlerursachen auszuschließen: Unter Suse war das kein Problem? Und da wurde auch das gleiche LAN-Kabel verwendet? Und das LAN-Kabel steckte auch in der gleichen Buchse der Fritzbox?

Hallo NAB, vielen Dank fürs reinspringen.

Doch, unter Suse gab es das Problem auch. Die Geschichte ist etwas komplizierter, dshalb im Stenogrammstil:

• Unter Suse 13.1 und 13.2 keinerlei Probleme
  Dann Hardwareproblem am Rechner => Rechner ausgetauscht
  War gebraucht (refurbished) mit Windows drauf.
  Windows HDD komplett raus genommen, SDD + alte Suse HDD (nur /home, /-Partition gelöscht)
  Suse Leap 42.1 aufgespielt, das Netzwerkproblem tauchte auf
  (weil ich mich über die Verwendung m. E. unausgereifter Software und Btrfs als Standard maßlos geärgert habe, Wechsel zu Debian)
  nach Installation bunsenlabs bestand das Netzproblem
  LAN_Kabel ist es nicht, habe ich mit anderem Kabel probiert
  Ob dieselbe Buchse, weiß ich nicht, muss ich auch noch ausprobieren, ob ein Buchsenwechsel was bringt

Ich habe natürlich auch schon an ein Hardwareproblem gedacht, aber was ich dann nicht verstünde, wäre das Funktionieren nach Router aus/an.

[gambit]

... sobald die Netzverbindung ungewünscht fehlt, und berichte dann hier weiter.

Poste dann auch die Ausgaben von:

Code: Alles auswählen

cat /lib/systemd/system/NetworkManager.service

Code: Alles auswählen

systemd-analyze blame

Code: Alles auswählen

systemctl list-units | grep -iE 'target|device'

Vielen Dank, das habe ich gemacht, aber die Datei, wo ich die Ergebnisse gespeichert habe, finde ich nicht mehr. Ich wiederhole das und berichte.
Die Ausgabe von "systemctl list-units | grep -iE 'target|device'" war allerdings so umfangreich, dass ich gar nicht weiß, ob sowas in ein Posting gehört, oder irgendwo hochgeladen werden muss.

[NAB]

Ich habe natürlich auch schon an ein Hardwareproblem gedacht, aber was ich dann nicht verstünde, wäre das Funktionieren nach Router aus/an.

Naja, dadurch veranlasst du ein Reset der Ethernet-Verbindung. Vorher finden die beiden Geräte irgendwie nicht zueinander.

Probiere bitte erst mal irgendeine andere Buchse an der Fritzbox aus.

Und die Fritzbox möchte bestimmt die aktuellste Firmware haben. Und dein Mainboard ebenfalls.

Wenn sich dadurch nichts ändert, würde mich interessieren, was

Code: Alles auswählen

dmesg | grep -e e100 -e eth0

ausgibt, wenn die grüne Lampe nicht leuchtet.

[gambit]

Naja, dadurch veranlasst du ein Reset der Ethernet-Verbindung. Vorher finden die beiden Geräte irgendwie nicht zueinander.

Ja, aber ich verstehe trotzdem nicht, wieso ein Router an/aus ein Hardwareproblem überwinden könnte.

Probiere bitte erst mal irgendeine andere Buchse an der Fritzbox aus.

Ja, das mach ich.

Und die Fritzbox möchte bestimmt die aktuellste Firmware haben.

das ist eine ziemlich alte Fritzbox (7170) und die Firmware ist die Version "29.04.88". Ich meine, da gibt es nicht aktuelleres, aber das prüfe ich.

Und dein Mainboard ebenfalls.

Da kriege ich ehrlich gesagt Gänsehaut und muss mich einlesen. Ich weiß insgesamt zweifellos sehr wenig (ich bin unter anderem zu Debian gewechselt, um das zu ändern) aber von Firmwareupdate für ein Mainboard weiß ich gar nichts.

Wenn sich dadurch nichts ändert, würde mich interessieren, was

Code: Alles auswählen

dmesg | grep -e e100 -e eth0

ausgibt, wenn die grüne Lampe nicht leuchtet.

Ich probiere den Buchsenwechsel und berichte dann

[NAB]

Da kriege ich ehrlich gesagt Gänsehaut und muss mich einlesen. Ich weiß insgesamt zweifellos sehr wenig (ich bin unter anderem zu Debian gewechselt, um das zu ändern) aber von Firmwareupdate für ein Mainboard weiß ich gar nichts.

Sorry, das nennt man üblicher Weise auch "BIOS-Update". Aber bevor du dich gruselst, könnte man ja erst mal gucken, wie schlimm es wirklich ist. Schau mal, was

Code: Alles auswählen

cat /sys/devices/virtual/dmi/id/board_*

ausgibt, dann wissen wir vielleicht schon mal, um welches Mainboard es sich handelt.