[gelöst] Netzwerkverlust

[TomL]

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

Das tut er auch nicht. Was bei Dir passiert ist, dass sich in dem Moment, wo der wieder Strom kriegt und neu gestartet wurde, alle angeschlossenen Geräte neu connecten... also auch Dein PC. War Dein PC (beim durchlaufenden Router) nur im suspend-Mode, hat das NIC noch Strom und behält sein Setting. Das muss imho auch so sein, es könnten ja gestartete Programme offene Ressourcen im Web vorhalten. War Dein Rechner aus, war natürlich auch das NIC aus und aus irgendeinem Grund verbindet es sich nicht neu beim Boot.

Mein Rat wäre, der Ursache in der bestehenden Konfiguration auf den Grund zu gehen und nicht planlos durch den Nebel rennen und irgendwas updaten, was m.E. gar keinen oder nur zufälligen Einfluss auf das Problem oder dessen Lösung hat. Deshalb bleibe ich dabei, erst mal sehen, was beim manuellen Start/Öffnen des Interfaces passiert und darauf hoffen, dass Fehlermeldungen entstehen. Und dazu brauchst Du das Programm "ip". Warum ist das nicht installiert bzw. warum kommt keine Fehlermeldung, wenn du es aufrufst, obwohl es nicht installiert ist? Oder anders gefragt, was startest Du mit der Eingabe des Befehls "ip", wenn keine Fehlermeldung kommt?

Also erst mal feststellen, wo sich das Tool zum Handling der Netzkonfiguration befindet (... und alle Befehle hier immer als rootausführen):

Code: Alles auswählen

which ip
dpkg -l iproute2

oder suchen lassen:

Code: Alles auswählen

find / -path /media -prune -o -iname "ip" -print
     /bin/ip
     /sbin/ip
     /usr/src/linux-headers-3.16.0-4-amd64/include/config/ip
     /usr/src/linux-headers-3.16.0-4-amd64/include/config/net/ip

Wenn es nicht gefunden wird, dann solltest Du das installieren:
https://de.wikipedia.org/wiki/Iproute2

Code: Alles auswählen

apt install iproute2

Dann testen, ob die Befehle jetzt möglich sind und vernünftige Ergebnisse bringen. Und wenn ja, auf den nächsten Ausfall beim Start nach dem echten "aus" warten und checken, ob der Connect von Hand funktioniert. Wenn ja, ist NIC, Kabel und Router in Ordnung und wir gucken uns die Netz-Konfiguration an. Und solange das nicht geklärt ist, würde ich nicht an der Hardware umfummeln und ggf. neue Probleme erzeugen.

BTW: Was hast Du überhaupt für ein Debian? Schau mal nach, ob einer oder mehrere der folgenden Befehle was mitteilt:

Code: Alles auswählen

cat /etc/*release
cat /etc/debian_version
cat /proc/version
cat /etc/issue 

j.m.2.c.

[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'

So, hier sind die Ausgaben, hat etwas gedauert:

cat /lib/systemd/system/NetworkManager.service
[Unit]
Description=Network Manager

[Service]
Type=dbus
BusName=org.freedesktop.NetworkManager
ExecStart=/usr/sbin/NetworkManager --no-daemon
Restart=on-failure
# NM doesn't want systemd to kill its children for it
KillMode=process

[Install]
WantedBy=multi-user.target
Also=NetworkManager-dispatcher.service

systemd-analyze blame
336ms lm-sensors.service
184ms exim4.service
127ms NetworkManager.service
124ms ModemManager.service
119ms loadcpufreq.service
65ms systemd-logind.service
62ms keyboard-setup.service
59ms alsa-restore.service
55ms rc-local.service
54ms gdomap.service
54ms ntp.service
54ms hddtemp.service
49ms avahi-daemon.service
46ms console-setup.service
32ms networking.service
27ms lightdm.service
24ms polkitd.service
22ms rsyslog.service
18ms systemd-fsck@dev-disk-by\x2duuid-342e8a91\x2dc3bc\x2d4375\x2d8f2b\x2d241f66bf7f11.service
16ms kbd.service
15ms cpufrequtils.service
14ms colord.service
13ms systemd-modules-load.service
12ms hdparm.service
11ms systemd-udev-trigger.service
10ms upower.service
10ms systemd-tmpfiles-setup-dev.service
9ms user@108.service
9ms systemd-tmpfiles-setup.service
8ms user@1000.service
7ms home.mount
7ms systemd-setup-dgram-qlen.service
6ms sys-kernel-debug.mount
5ms kmod-static-nodes.service
4ms dev-disk-by\x2duuid-8eb14b88\x2dfe9d\x2d4266\x2da84a\x2dbfa2dc2c7098.swap
4ms systemd-random-seed.service
4ms systemd-journal-flush.service
3ms systemd-remount-fs.service
3ms udev-finish.service
3ms systemd-update-utmp.service
2ms systemd-sysctl.service
2ms dev-mqueue.mount
2ms systemd-update-utmp-runlevel.service
2ms systemd-user-sessions.service
1ms systemd-udevd.service
1ms dev-hugepages.mount
1ms sys-fs-fuse-connections.mount

systemctl list-units | grep -iE 'target|device'
sys-devices-pci0000:00-0000:00:14.0-usb3-3\x2d1-3\x2d1:1.2-host6-target6:0:0-6:0:0:0-block-sdc.device loaded active plugged Photosmart_5510
sys-devices-pci0000:00-0000:00:14.0-usb3-3\x2d1.device loaded active plugged Photosmart_5510_series
sys-devices-pci0000:00-0000:00:16.3-tty-ttyS1.device loaded active plugged 7 Series/C210 Series Chipset Family KT Controller
sys-devices-pci0000:00-0000:00:19.0-net-eth0.device loaded active plugged 82579LM Gigabit Network Connection
sys-devices-pci0000:00-0000:00:1b.0-sound-card0.device loaded active plugged 7 Series/C210 Series Chipset Family High Definition Audio Controller
sys-devices-pci0000:00-0000:00:1f.2-ata1-host0-target0:0:0-0:0:0:0-block-sda-sda1.device loaded active plugged Samsung_SSD_850_EVO_250GB 1
sys-devices-pci0000:00-0000:00:1f.2-ata1-host0-target0:0:0-0:0:0:0-block-sda-sda2.device loaded active plugged Samsung_SSD_850_EVO_250GB 2
sys-devices-pci0000:00-0000:00:1f.2-ata1-host0-target0:0:0-0:0:0:0-block-sda-sda5.device loaded active plugged Samsung_SSD_850_EVO_250GB 5
sys-devices-pci0000:00-0000:00:1f.2-ata1-host0-target0:0:0-0:0:0:0-block-sda-sda6.device loaded active plugged Samsung_SSD_850_EVO_250GB 6
sys-devices-pci0000:00-0000:00:1f.2-ata1-host0-target0:0:0-0:0:0:0-block-sda.device loaded active plugged Samsung_SSD_850_EVO_250GB
sys-devices-pci0000:00-0000:00:1f.2-ata2-host1-target1:0:0-1:0:0:0-block-sdb-sdb10.device loaded active plugged WDC_WD15EARS-00Z5B1 10
sys-devices-pci0000:00-0000:00:1f.2-ata2-host1-target1:0:0-1:0:0:0-block-sdb-sdb3.device loaded active plugged WDC_WD15EARS-00Z5B1 b64443a5-fb65-4b
sys-devices-pci0000:00-0000:00:1f.2-ata2-host1-target1:0:0-1:0:0:0-block-sdb-sdb4.device loaded active plugged WDC_WD15EARS-00Z5B1 4
sys-devices-pci0000:00-0000:00:1f.2-ata2-host1-target1:0:0-1:0:0:0-block-sdb-sdb5.device loaded active plugged WDC_WD15EARS-00Z5B1 sda5
sys-devices-pci0000:00-0000:00:1f.2-ata2-host1-target1:0:0-1:0:0:0-block-sdb-sdb6.device loaded active plugged WDC_WD15EARS-00Z5B1 sda6
sys-devices-pci0000:00-0000:00:1f.2-ata2-host1-target1:0:0-1:0:0:0-block-sdb-sdb7.device loaded active plugged WDC_WD15EARS-00Z5B1 sda8
sys-devices-pci0000:00-0000:00:1f.2-ata2-host1-target1:0:0-1:0:0:0-block-sdb-sdb8.device loaded active plugged WDC_WD15EARS-00Z5B1 8
sys-devices-pci0000:00-0000:00:1f.2-ata2-host1-target1:0:0-1:0:0:0-block-sdb-sdb9.device loaded active plugged WDC_WD15EARS-00Z5B1 9
sys-devices-pci0000:00-0000:00:1f.2-ata2-host1-target1:0:0-1:0:0:0-block-sdb.device loaded active plugged WDC_WD15EARS-00Z5B1
sys-devices-pci0000:00-0000:00:1f.2-ata3-host2-target2:0:0-2:0:0:0-block-sr0.device loaded active plugged hp_DVD_D_DH16D7SH
sys-devices-platform-serial8250-tty-ttyS2.device loaded active plugged /sys/devices/platform/serial8250/tty/ttyS2
sys-devices-platform-serial8250-tty-ttyS3.device loaded active plugged /sys/devices/platform/serial8250/tty/ttyS3
sys-devices-pnp0-00:08-tty-ttyS0.device loaded active plugged /sys/devices/pnp0/00:08/tty/ttyS0
sys-module-fuse.device loaded active plugged /sys/module/fuse
sys-subsystem-net-devices-eth0.device loaded active plugged 82579LM Gigabit Network Connection
kmod-static-nodes.service loaded active exited Create list of required static device nodes for the current kernel
systemd-tmpfiles-setup-dev.service loaded active exited Create Static Device Nodes in /dev
systemd-udev-trigger.service loaded active exited udev Coldplug all Devices
systemd-udevd.service loaded active running udev Kernel Device Manager
basic.target loaded active active Basic System
cryptsetup.target loaded active active Encrypted Volumes
getty.target loaded active active Login Prompts
graphical.target loaded active active Graphical Interface
local-fs-pre.target loaded active active Local File Systems (Pre)
local-fs.target loaded active active Local File Systems
multi-user.target loaded active active Multi-User System
network-online.target loaded active active Network is Online
network.target loaded active active Network
paths.target loaded active active Paths
printer.target loaded active active Printer
remote-fs-pre.target loaded active active Remote File Systems (Pre)
remote-fs.target loaded active active Remote File Systems
slices.target loaded active active Slices
sockets.target loaded active active Sockets
sound.target loaded active active Sound Card
swap.target loaded active active Swap
sysinit.target loaded active active System Initialization
timers.target loaded active active Timers

[TomL]

Sorry... aber mit den Ausgaben kannst Du imho gar nix anfangen. Außer vielleicht mit der geänderten Variante von

Code: Alles auswählen

systemctl status /lib/systemd/system/NetworkManager.service

...den ich für den Übeltäter halte.

[gambit]

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.

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

3396
CZC30644RN
Hewlett-Packard

Ein paar weitere Angaben sind noch in meinem Ausgangsposting am Ende.

Den Buchsenwechsel bzgl. des LAN-Kabels an der Fritzbox habe ich durchgeführt. Ich teste das weiter.

[NAB]

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

3396
CZC30644RN
Hewlett-Packard

Wenn mich Google richtig informiert hat, müsste dieses Mainboard zu einem Hewlett-Packard Compaq Elite 8300 CMT gehören. Dazu finde ich dann diese Supportseite von HP:
http://h20564.www2.hp.com/hpsc/swd/publ ... id=5232663
Und dort leider nur Downloads für Windows. Irgendwo ist immerhin von einem Flash-Programm für DOS und Linux die Rede, aber zum Auspacken und Installieren braucht's wohl trotzdem Windows und etwas Frickelei

Da neuste BIOS soll "v02.99 Rev.A" vom 19 Okt 2015 sein. Und es soll identisch zu "v02.98 Rev.A" sein.

Schau doch mal, was

Code: Alles auswählen

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

dazu sagt.

Edit: Upps, das steht ja auf der ersten Seite: Bios: Hewlett-Packard v: K01 v02.05 date: 05/07/2012

Das älteste BIOS, das HP noch auf seiner Seite erwähnt, ist " 2.56 Rev. A 30 Okt 2012". Da würde ich so oder so mal zum Update raten.

[TomL]

So.. habe gerade mal mein Netzwerk deaktiviert und die Schritte manuell durchgeführt.... und wenn dabei keine Fehler passieren, ist es nicht das Mainboard:

Wie man sieht: state DOWN

Code: Alles auswählen

# ip addr show
2: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
    link/ether 74:d4:35:ba:37:1f brd ff:ff:ff:ff:ff:ff
    inet 10.10.1.27/24 brd 10.10.1.255 scope global eth0
       valid_lft forever preferred_lft forever

Dann step by step.... erst das NIC öffnen

Code: Alles auswählen

# ip link set dev eth0 up

NIC = state UP

Code: Alles auswählen

# ip addr show
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 74:d4:35:ba:37:1f brd ff:ff:ff:ff:ff:ff
    inet 10.10.1.27/24 brd 10.10.1.255 scope global eth0
       valid_lft forever preferred_lft forever

Dann via DHCP die IP anfordern:

Code: Alles auswählen

# dhclient -v eth0
Internet Systems Consortium DHCP Client 4.3.1
Copyright 2004-2014 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/eth0/74:d4:35:ba:37:1f
Sending on   LPF/eth0/74:d4:35:ba:37:1f
Sending on   Socket/fallback
DHCPREQUEST on eth0 to 255.255.255.255 port 67
DHCPACK from 10.10.1.1
RTNETLINK answers: File exists
bound to 10.10.1.27 -- renewal in 422734 seconds.

Und siehe da... verbunden:

Code: Alles auswählen

# ip addr show
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 74:d4:35:ba:37:1f brd ff:ff:ff:ff:ff:ff
    inet 10.10.1.27/24 brd 10.10.1.255 scope global eth0
       valid_lft forever preferred_lft forever

@Nab
Ich würde diese Mainboard-Baustelle nicht öffnen...
Um diese Fehlerursache zu testen, wäre meines Erachtens stattdessen erst mal (und vor dem Test, s.o.) nur eins notwendig:

Code: Alles auswählen

systemctl stop NetworkManager.service

[gambit]

Sorry... aber mit den Ausgaben kannst Du imho gar nix anfangen. Außer vielleicht mit der geänderten Variante von

Code: Alles auswählen

systemctl status /lib/systemd/system/NetworkManager.service

...den ich für den Übeltäter halte.

Ich hatte, wie gesagt, NWM mal abgeschaltet und es über die Eintragung "auto eth0" in /etc/network/interfaces versucht. Das hat aber nicht richtig funktioniert, möglicherweise aufgrund eines Fehlers von mir und ich bin wieder zu NWM zurückgekehrt.

Falls Deine Vermutung richtig ist und das Problem bei NWM liegt, würde ich nicht zögern, es mit einer festen IP ohne NWM und ohne DHCP zu probieren, denn ich nutze nur Ethernet, kein Wlan.

Aber ich halte Deinen Rat von weiter oben für unbedingt richtig, zunächst der bestehenden Konfiguration auf den Grund zu gehen.

Zu Deinem Posting "Mo 9. Mai 2016, 20:51" melde ich mich noch.

[TomL]

Zu Deinem Posting "Mo 9. Mai 2016, 20:51" melde ich mich noch.

Besser ist das letzte Posting, 21:47, nur eins oberhalb... denn ich muss gestehen, ich habe da zuerst irgendwas in Deinen Antworten übersehen. Das Programm "ip" ist ja offensichtlich da, jetzt gehts nur darum, es korrekt zu bedienen und genau zu schauen, wo es stockt... und da habe ich ja den Weg im Vorposting aufgeschrieben.

Also, zuerst (nach dem Kaltstart, wenn das Netz nicht verbunden ist) den NWM stoppen, dann genau wie beschrieben manuell verbinden und nach jedem Schritt immer den aktuellen Status prüfen. Und dabei KEINE Befehle mischen.... ifconfig, ifup, ifdown sind alte Kamellen, die hier ggf. nicht funktionieren, wenn /etc/interfaces nicht vorhanden ist... und auch die brauchen wir ebenfalls überhaupt nicht mehr

[gambit]

So.. habe gerade mal mein Netzwerk deaktiviert und die Schritte manuell durchgeführt....

Das habe ich über NWN "Verbindung trennen" soeben auch gemacht, aber bei mir zeigen die Befehle teilweise etwas anderes:

Code: Alles auswählen

# ip addr show
2: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
    link/ether 74:d4:35:ba:37:1f brd ff:ff:ff:ff:ff:ff
    inet 10.10.1.27/24 brd 10.10.1.255 scope global eth0
       valid_lft forever preferred_lft forever

Bei mir ist das:

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: <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

Dann step by step.... erst das NIC öffnen

Code: Alles auswählen

# ip link set dev eth0 up

/quote]

Hier kommt bei mir nur ein neuer Prompt. Ist das "NIC = state UP" eine Ausgabe bei Dir, oder hast Du das hier zur Erklärung beigefügt?

Code: Alles auswählen

# ip addr show
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 74:d4:35:ba:37:1f brd ff:ff:ff:ff:ff:ff
    inet 10.10.1.27/24 brd 10.10.1.255 scope global eth0
       valid_lft forever preferred_lft forever

Das ist bei mir:

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: <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

Dann via DHCP die IP anfordern:

Code: Alles auswählen

# dhclient -v eth0
Internet Systems Consortium DHCP Client 4.3.1
Copyright 2004-2014 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/eth0/74:d4:35:ba:37:1f
Sending on   LPF/eth0/74:d4:35:ba:37:1f
Sending on   Socket/fallback
DHCPREQUEST on eth0 to 255.255.255.255 port 67
DHCPACK from 10.10.1.1
RTNETLINK answers: File exists
bound to 10.10.1.27 -- renewal in 422734 seconds.

Das ist bei mir:

dhclient -v eth0
Internet Systems Consortium DHCP Client 4.3.1
Copyright 2004-2014 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/eth0/10:60:4b:81:76:38
Sending on LPF/eth0/10:60:4b:81:76:38
Sending on Socket/fallback
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 8
DHCPREQUEST on eth0 to 255.255.255.255 port 67
DHCPOFFER from 192.168.178.1
DHCPACK from 192.168.178.1
bound to 192.168.178.21 -- renewal in 342089 seconds.

Und siehe da... verbunden:

Code: Alles auswählen

# ip addr show
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 74:d4:35:ba:37:1f brd ff:ff:ff:ff:ff:ff
    inet 10.10.1.27/24 brd 10.10.1.255 scope global eth0
       valid_lft forever preferred_lft forever

Das zeigt bei mir:

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: <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 eth0
valid_lft forever preferred_lft forever
inet6 fe80::1260:4bff:fe81:7638/64 scope link
valid_lft forever preferred_lft forever

Die Wiederherstellung der zuvor (über NWM) getrennten Verbindung klappt bei mir also auch, aber zu Beginn des händischen Procedere unterscheiden sich die Meldungen.

[gambit]

Also, zuerst (nach dem Kaltstart, wenn das Netz nicht verbunden ist) den NWM stoppen ...

Das habe ich zu spät gesehen. Ich wiederhole das mit ausgeschaltetem NWM nach Kaltstart und berichte dann

[NAB]

@Nab
Ich würde diese Mainboard-Baustelle nicht öffnen...

Joa ... mich würd die Ausgabe von dmesg auch wesentlich mehr interessieren. Die "Mainboard-Baustelle" würde ich jetzt auch noch nicht öffnen, das ist zu umständlich und zu wenig erfolgsversprechend. Mich würd nur interessieren, ob es so eine Baustelle überhaupt gibt, also welche BIOS-Version vorliegt.

[TomL]

Das habe ich über NWN "Verbindung trennen" soeben auch gemacht, aber bei mir zeigen die Befehle teilweise etwas anderes:

"ip link set dev eth0 up" selber hat keine Ausgabe. Du siehst den Unterschied (vorher/nachher) nur beim Kontrollieren des NIC-Status, einmal vorher, einmal nachher. Und wenn Du gerne ne Ausgabe sehen möchtest, machs mit dieser Variante:

Code: Alles auswählen

ip link set dev eth0 up && echo "geöffnet" || echo "nicht geöffnet"

Zuerst ergibt

Code: Alles auswählen

ip addr show

in der Ausgabe zu eth0 den Text "state DOWN" und dann nach

Code: Alles auswählen

ip link set dev eth0 up

siehst Du mit

Code: Alles auswählen

ip addr show

in den Ausgabe-Zeilen zu eth0 den Text "state UP" Und wenn "state UP", dann mit

Code: Alles auswählen

dhclient -v eth0

die IP anfordern.

Und wenn das klappt, dann bin ich sicher, dass der NWM der Übeltäter ist. ACHTUNG: NWN "Verbindung trennen" ist was anders, als den zu stoppen. Denn bei nur getrennter Verbindung ist der immer noch aktiv und fummelt am Netzwerk rum. Du musst ihn tatsächlich völlig beenden. Und wie schon mehrfach gesagt, den Test nur nach Kaltstart durchführen, wenn das Netz wegen des Kaltstarts nicht vorhanden ist. Mit

Code: Alles auswählen

systemctl | grep network -i

findest Du heraus, wie dieser spezielle Service richtigerweise (case-sensitive) heisst, und mit

Code: Alles auswählen

systemctl stop NetworkManager.service

ist er nur jetzt beendet. Beim nächsten Boot wird er wieder gestartet. Und von Hand kannst Du ihn auch starten:

Code: Alles auswählen

systemctl start NetworkManager.service

Ich würde auch kontrollieren, ob der nach dem stop wirklich weg ist:

Code: Alles auswählen

systemctl status NetworkManager.service
ps -aux | grep network

Da sollte nix mehr vom NWM zu sehen sein. Und erst dann die o.g. Diagnose-Schritte durchführen.... entweder es kommen Fehlermeldungen, oder es klappt.

[gambit]

Das habe ich über NWN "Verbindung trennen" soeben auch gemacht, aber bei mir zeigen die Befehle teilweise etwas anderes:

"ip link set dev eth0 up" selber hat keine Ausgabe. Du siehst den Unterschied beim Kontrollieren des NIC-Status, einmal vorher, einmal nachher. Und wenn Du gerne ne Ausgabe sehen möchtest, machs mit dieser Variante:

Code: Alles auswählen

ip link set dev eth0 up && echo "geöffnet" || echo "nicht geöffnet"

Zuerst ergibt

Code: Alles auswählen

ip addr show

in der Ausgabe zu eth0 den Text "state DOWN" und dann nach

Code: Alles auswählen

ip link set dev eth0 up

siehst Du mit

Code: Alles auswählen

ip addr show

in den Ausgabe-Zeilen zu eth0 den Text "state UP" Und wenn "state UP", dann mit

Code: Alles auswählen

dhclient -v eth0

die IP anfordern.

Ich habe nach Runterfahren und Strom-an / Strom-aus des Rechners und dessen Neustart (LAN-Kontrollleuchte brannte nicht) als root folgendes eingegeben:

Code: Alles auswählen

# systemctl stop NetworkManager.service
# systemctl status Networkmanager.service
● Networkmanager.service
   Loaded: not-found (Reason: No such file or directory)
   Active: inactive (dead)

# 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: <BROADCAST,MULTICAST> 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

# ip link set dev eth0 up

# 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

# dhclient -v eth0
Internet Systems Consortium DHCP Client 4.3.1
Copyright 2004-2014 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/eth0/10:60:4b:81:76:38
Sending on   LPF/eth0/10:60:4b:81:76:38
Sending on   Socket/fallback
DHCPREQUEST on eth0 to 255.255.255.255 port 67
DHCPREQUEST on eth0 to 255.255.255.255 port 67
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 4
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 5
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 14
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 9
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 10

^C

# 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

Dann wieder das Procedere mit Router-an / Router-aus, wieder ohne NWM:

Code: Alles auswählen

ping 8.8.8.8
connect: Network is unreachable
$ su
Passwort: 

# 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: <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
    inet6 fe80::1260:4bff:fe81:7638/64 scope link 
       valid_lft forever preferred_lft forever

# dhclient -v eth0
Internet Systems Consortium DHCP Client 4.3.1
Copyright 2004-2014 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/eth0/10:60:4b:81:76:38
Sending on   LPF/eth0/10:60:4b:81:76:38
Sending on   Socket/fallback
DHCPREQUEST on eth0 to 255.255.255.255 port 67
DHCPACK from 192.168.178.1
bound to 192.168.178.21 -- renewal in 360946 seconds.

# 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: <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 eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::1260:4bff:fe81:7638/64 scope link 
       valid_lft forever preferred_lft forever

# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=49 time=15.7 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=49 time=15.1 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=49 time=16.1 ms
^C
--- 8.8.8.8 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 15.160/15.696/16.129/0.402 ms
root@seneca:/home/rmb# 

[gambit]

... mich würd die Ausgabe von dmesg auch wesentlich mehr interessieren.

Pardon,

Code: Alles auswählen

dmesg | grep -e e100 -e eth0

zeige ich sobald es geht, habe ich beim jetzigen Kaltstart übersehen.

[TomL]

Bitte mach das noch einmal, wieder nach dem Kaltstart und ohne das der Router gestartet wurde, wieder mit ausgeschaltetem NWM:
Zuerst

Code: Alles auswählen

ip link set dev eth0 up

Und dann im Abstand von 5 Sekunden mehrere Male wiederholen:

Code: Alles auswählen

ip addr show

Und dann beobachten, ob sich der Status von "state DOWN" auf "state UP" ändert

Und poste mal die Ausgaben von:

Code: Alles auswählen

 journalctl -b -k | grep link
 journalctl -b | grep network

[gambit]

Bitte mach das noch einmal, wieder nach dem Kaltstart und ohne das der Router gestartet wurde, wieder mit ausgeschaltetem NWM:
Zuerst

Code: Alles auswählen

ip link set dev eth0 up

Und dann im Abstand von 5 Sekunden mehrere Male wiederholen:

Code: Alles auswählen

ip addr show

Und dann beobachten, ob sich der Status von "state DOWN" auf "state UP" ändert

Nein, "state DoWN" ändert sich auch bei 20 Versuchen nicht.

Und poste mal die Ausgaben von:

Code: Alles auswählen

 journalctl -b -k | grep link
 journalctl -b | grep network

Das habe ich wieder zu spät gesehen, falls das für den Status vor Router an / aus gemeint war - entschuldige bitte.

Sicherheitshalber, für den Zustand jetzt (nach Router aus / an):

Code: Alles auswählen

journalctl -b -k | grep link
Mai 09 23:34:28 seneca kernel: audit: initializing netlink subsys (disabled)
Mai 09 23:34:28 seneca kernel: ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
Mai 09 23:34:28 seneca kernel: ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
Mai 09 23:34:28 seneca kernel: ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
Mai 09 23:34:29 seneca kernel: IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
Mai 09 23:39:40 seneca kernel: IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
Mai 09 23:40:14 seneca kernel: IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

Code: Alles auswählen

journalctl -b | grep network
Mai 09 23:34:28 seneca networking[423]: Configuring network interfaces...done.
Mai 09 23:34:29 seneca NetworkManager[601]: <info>       interface-parser: parsing file /etc/network/interfaces
Mai 09 23:34:29 seneca NetworkManager[601]: <info>       interface-parser: source line includes interfaces file(s) /etc/network/interfaces.d/*
Mai 09 23:34:29 seneca NetworkManager[601]: <warn> interfaces file /etc/network/interfaces.d/* doesn't exist
Mai 09 23:34:29 seneca NetworkManager[601]: <info>       interface-parser: finished parsing file /etc/network/interfaces
Mai 09 23:34:29 seneca NetworkManager[601]: <info> monitoring ifupdown state file '/run/network/ifstate'.

Zur Klarstellung: NWM ist weiterhin deaktiviert

[gambit]

... mich würd die Ausgabe von dmesg auch wesentlich mehr interessieren ...

So, hier ist jetzt die Ausgabe:

Code: Alles auswählen

$ su
Passwort: 
# dmesg | grep -e e100 -e eth0
[    0.535072] e1000e: Intel(R) PRO/1000 Network Driver - 2.3.2-k
[    0.535073] e1000e: Copyright(c) 1999 - 2014 Intel Corporation.
[    0.551700] e1000e 0000:00:19.0: Interrupt Throttling Rate (ints/sec) set to dynamic conservative mode
[    0.551719] e1000e 0000:00:19.0: irq 40 for MSI/MSI-X
[    0.758714] e1000e 0000:00:19.0 eth0: registered PHC clock
[    0.758716] e1000e 0000:00:19.0 eth0: (PCI Express:2.5GT/s:Width x1) 10:60:4b:81:76:38
[    0.758717] e1000e 0000:00:19.0 eth0: Intel(R) PRO/1000 Network Connection
[    0.758749] e1000e 0000:00:19.0 eth0: MAC: 10, PHY: 11, PBA No: 0100FF-0FF
[    3.072611] e1000e 0000:00:19.0: irq 40 for MSI/MSI-X
[    3.176592] e1000e 0000:00:19.0: irq 40 for MSI/MSI-X
[    3.176835] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready

[mat6937]

Code: Alles auswählen

journalctl -b | grep network
Mai 09 23:34:28 seneca networking[423]: Configuring network interfaces...done.
Mai 09 23:34:29 seneca NetworkManager[601]: <info>       interface-parser: parsing file /etc/network/interfaces
Mai 09 23:34:29 seneca NetworkManager[601]: <info>       interface-parser: source line includes interfaces file(s) /etc/network/interfaces.d/*
Mai 09 23:34:29 seneca NetworkManager[601]: <warn> interfaces file /etc/network/interfaces.d/* doesn't exist
Mai 09 23:34:29 seneca NetworkManager[601]: <info>       interface-parser: finished parsing file /etc/network/interfaces
Mai 09 23:34:29 seneca NetworkManager[601]: <info> monitoring ifupdown state file '/run/network/ifstate'.

Zur Klarstellung: NWM ist weiterhin deaktiviert

Bist Du sicher, dass der NWM deaktiviert war?

Code: Alles auswählen

ps aux | grep -i NetworkManager

Versuch mal vor dem:

Code: Alles auswählen

ip link set dev eth0 up

noch Folgendes:

Code: Alles auswählen

modprobe -rfv e1000e
modprobe -v e1000e CrcStripping=0

auszuführen.

[NAB]

Gut, einen Fehler meldet der Treiber nicht. Es fehlt halt nur die Meldung "e1000e: eth0 NIC Link is Up", aber das wissen wir ja schon.

Hast du es mal mit der anderen LAN-Buchse an der Fritzbox ausprobiert?

Und installiere dir bitte mal das Paket "ethtool". Und dann probiere mal folgenden Befehl als root aus:

Code: Alles auswählen

ethtool -r eth0

und schau, ob die Lampe dann grün leuchtet.

Den modprobe-Befehl von mat6937 würde ich erst danach ausprobieren. Und vorsicht, der kann dir den gesamten Rechner abschießen, also vorher alles speichern.

Die gesuchte BIOS-Version habe ich inzwischen in deinem ersten Posting gefunden und meinen Beitrag auf der vorigen Seite editiert.

[TomL]

Hast du es mal mit der anderen LAN-Buchse an der Fritzbox ausprobiert?

Bin jetzt leider bis heute abend nur am Handy ... aber was mich ungläubig staunen lässt, ist die "anscheinende" Tatsache, dass er mit
ip link set dev eth0 up
nach dem Kaltstart nicht das Interface öffnen kann. Das ist für mich unbegreiflich. Was mich jetzt vor dem Hintergrund deiner Frage interessieren würde, ist die Antwort darauf , ob für den 'up' (oder 'down') überhaupt ein Patchkabel und damit Verbindung zum Router vorhanden sein muss. Also, kann ich das Interface auch ohne Kabel up'n und down'n (dhclient -das ist klar- geht dann natürlich nicht)?

Warum diese Frage? Ganz einfach.... geht das im Normalfall auch ohne Patchkabel, kann er das Kabel, den Router und den Lan-Port am Router als Ursache vergessen. Dann muss die Ursache imho beim PC liegen .... denn es kann m.E. nicht sein, dass ein direkt mit dem Kernel kommunizierendes Programm nicht das Interface öffnen kann.

[mat6937]

Code: Alles auswählen

# systemctl stop NetworkManager.service

Code: Alles auswählen

# ip addr show
2: eth0: <BROADCAST,MULTICAST> 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

Code: Alles auswählen

# ip addr show
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

"ip link set dev eth0 up" hat schon dazu geführt, dass das eth0-Interface danach up ist.

Siehe den Unterschied Zwischen "BROADCAST,MULTICAST" und nach dem ip-Befehl, "NO-CARRIER,BROADCAST,MULTICAST,UP" in der Ausgabe von "ip addr show".

EDIT:

Versuch mal nach dem das eth0-Interface up ist, eine manuelle Zuweisung der IP-Adresse (die nicht im DHCP-Pool der FritzBox ist). Z. B.:

Code: Alles auswählen

ip addr add 192.168.178.9/24 broadcast 192.168.178.255 dev eth0

und danach:

Code: Alles auswählen

ip a
ip n s
ip r
ping -c 3 -W 2 192.168.178.1
ip n s

Evtl. auch die Kabelverbindung zum Router (FritzBox) kurz unterbrechen (d. h. raus und wieder rein).

[mat6937]

Und vorsicht, der kann dir den gesamten Rechner abschießen, ...

Wenn das passiert, dann hat er noch ganz andere Probleme mit seinem Rechner. Ich kann den Treiber für das eth0-Interface, so oft ich will entfernen und hinzufügen und da wird mein Rechner nie abgeschossen.

BTW: Er nutzt seinen Rechner ja nicht headless, mit Zugang über das eth0-Interface.

[TomL]

"ip link set dev eth0 up" hat schon dazu geführt, dass das eth0-Interface danach up ist.

Nee, eigentlich nicht. Meiner Meinung nach hat er schon wieder am Router rumgefummelt und den zwischenzeitlich neu gestartet.
Er muss bei der Fehlersuche zunächst mal den Router völlig in Ruhe lassen und darf den keinesfalls ständig neu starten. Der Fehler (keine Netzverbindung nach dem Kaltstart des PC) muss unbedingt solange bestehen bleiben, bis man ihn pc-seitig behoben hat.

Der Fehler ist: Nach einem Kaltstart verbindet der Client NICHT automatisch. Punkt!

Zur Lösung deaktiviere ich alle "automatischen" Vorgänge (Dienste, Daemons) zum Start und Betrieb des Netzwerks und starte nach dem Kaltstart und wenn eth0 noch down ist alle Schritte einzeln von Hand, um festzustellen wo genau es hakt. An dem Punkt ist es Quatsch, mit manueller resp. statischer IP zu hantieren, weil der Normalbetrieb ja DHCP ist und das ja außerhalb der Störung funktioniert.

Die Frage lautet: Ist es möglich nach dem Kaltstart (bei deaktivierten Automatismus) eth0 von down zu up zu bringen? Wenn das nicht gelingt, kann man alles andere vergessen und man muss sich nicht mit IP oder Kabel oder Vollmond beschäftigen. Wenn eth0 nicht 'up' geht, funktioniert sowieso gar nix. Dieser Fehler muss imho zuerst behoben werden...das muss zuverlässig 10 von 10 mal funktionieren. Und erst wenn das klappt, folgt imho der nächste schritt, und zwar dhclient. Und auch das muss 10 von 10 mal zuverlässig klappen ... beim ersten Mal ohne -r, ab dem 2. Mal mit -r.

Und wenn das alles klappt schaut man sich die Automatismen an und prüft, welcher Teil davon Probleme nach dem Kaltstart hat.

Das wäre meine Vorgehensweise zur Fehlersuche. Nur eins darf man bei der Suche nicht anpacken ... und zwar den Router. Erst wenn vermutbar davon auszugehen ist, dass es kein Client -Problem ist, schaue ich mir den Rest an. Aber ich bin immer noch davon überzeugt, dass es ein reines Client-Problem ist.

Btw, gibts evtl. andere Geräte ...?... vielleicht nen Laptop? Dann einfach mal an dem Patchkabel des Problem-PC nen anderes Gerät anschließen. Wenn der dann sofort verbindet, kann man Kabel und Router als Ursache ausschließen.

[mat6937]

Nee, eigentlich nicht. Meiner Meinung nach hat er schon wieder am Router rumgefummelt und den zwischenzeitlich neu gestartet.

Meinst Du das oder weißt Du das? Denn in seinem Beitrag vom 09.05.2016 23:22:14 Uhr, hat der TE. Folgendes geschreiben:

Ich habe nach Runterfahren und Strom-an / Strom-aus des Rechners und dessen Neustart (LAN-Kontrollleuchte brannte nicht) als root folgendes eingegeben:

Da ist von am Router "rumzfummeln" ( neu starten, etc.) nichts geschrieben worden bzw. nichts zu lesen. Dann schreibt der TE weiter:

systemctl stop NetworkManager.service

Code: Alles auswählen

# ip addr show
2: eth0: <BROADCAST,MULTICAST> 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

Daraus ist ersichtlich, dass das eth0-Interface noch nicht up ist.

Danach schreibt der TE weiter, das er richtigerweise:

Code: Alles auswählen

ip link set dev eth0 up

ausgeführt hat, und danach postet der TE die Ausgabe von "ip addr show":

# ip addr show
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

... und daraus ist ab hier ersichtlich, dass das eth0-Interface up ist. Mehr up geht zu diesem Zeitpunkt, m. E. erstmal nicht (... auch auf meinem System nicht).

Oder welche Art von up, erwartest Du zu diesem Zeitpunkt?

Warum das mit dem dhclient ab hier nicht funktioniert, weiß ich nicht und deshalb mein Vorschlag mit der manuellen Zuweisung der IP-Adresse (als Test). Alles was ich hier beobachtet und geschrieben habe, kann ich auf meinem System auch so reproduzieren.

[TomL]

@ mat6937, sorry, Du hast Recht.... bitte zum nächsten Post springen... ich lass das hier trotzdem stehen, auch wenns wegen meines Lesefehlers unrichtig ist.

Meinst Du das oder weißt Du das? Denn in seinem Beitrag vom 09.05.2016 23:22:14 Uhr, hat der TE. Folgendes geschreiben:

Ich habe nach Runterfahren und Strom-an / Strom-aus des Rechners und dessen Neustart (LAN-Kontrollleuchte brannte nicht) als root folgendes eingegeben:

Ich meine gar nix und ich weiss auch nix, ich nehme nur einfach das, was da steht.... und da steht, dass eth0 "down" bleibt. Punkt! Und erst nach dem der Router neu gestartet wurde, war eth0 up. Das heisst, das Problem des Interfaces, was mit "ip link set dev eth0 up" nicht geöffnet wird, ist an der Stelle überhaupt nicht gelöst. Und an dem Punkt muss ich mir mit DHCP oder Static-IP ganz sicher noch keine Gedanken machen.

Ich habe nach Runterfahren und Strom-an / Strom-aus des Rechners und dessen Neustart (LAN-Kontrollleuchte brannte nicht) als root folgendes eingegeben:
# systemctl stop NetworkManager.service
# systemctl status Networkmanager.service
● Networkmanager.service
Loaded: not-found (Reason: No such file or directory)
Active: inactive (dead)

# ip addr show
2: eth0: <BROADCAST,MULTICAST> 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

# ip link set dev eth0 up
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

Dann wieder das Procedere mit Router-an / Router-aus, wieder ohne NWM:
# ip addr show
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
inet6 fe80::1260:4bff:fe81:7638/64 scope link
valid_lft forever preferred_lft forever

Also, meiner Meinung nach ist es unumgänglich zur Diagnose den Network-Manager ausser Betrieb zu nehmen, mit

Code: Alles auswählen

systemctl disable NetworkManager.service

Dann Kaltstart des Rechners und sicherstellen, dass kein anderer Daemon oder Service das Interface blockiert oder für sich beansprucht:

Code: Alles auswählen

ps -aux | grep -i network

Und dann muss sich das NIC mit "ip link set dev eth0 up" öffnen lassen. Und wenn es geöffnet ist, muss sich dhclient eine IP holen. Und wenn das nicht passiert, ist was anderes faul. BTW, ist das ein Onboard-NIC oder eine Interface-Karte?

Und -einfach so- würde ich auch vor dem nächsten Kaltstart IPV6 abschalten:

Code: Alles auswählen

nano /etc/sysctl.d/disable-ipv6.conf

mit folgendem Inhalt

Code: Alles auswählen

net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1
net.ipv6.conf.eth0.disable_ipv6 = 1

Falls sich das NIC nicht öffnen lässt, muss er halt den Router wieder neu starten und das NIC dann öffnen und mit dhclient eine IP anfordern. Oder er nimmt den NWM wieder in Betrieb mit:

Code: Alles auswählen

systemctl enable network-manager.server
systemctl start network-manager.server

Aber wenn sich das NIC nicht öffnen lässt, ist vielleicht doch was an der Hardware faul.... deswegen auch meine Frage mit OnBoard oder Karte.... denn wenn Karte, dann "nachdrücken".