ubuntuusers.de

Moin, wir haben ein Kubuntu 22.04 auf einem älteren Lenovo L560 installiert. Nun ist es so, daß das Einstecken des Ethernet-LAN-Steckers ohne Reaktion bleibt. WLAN funktioniert. In der Regel ist es doch so, daß WLAN nicht verfügbar ist - hier ist es genau anders herum 🤣 Ich steh ein wenig wie der Ochs vor dem Berg und bin für Unterstützung dankbar. Hier ein paar Rahmendaten:

tina@L560:~$ uname -a
Linux L560 5.15.0-47-generic #51-Ubuntu SMP Thu Aug 11 07:51:15 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

tina@L560:~$ lspci -nnk | grep -i net -A2 
00:1f.6 Ethernet controller [0200]: Intel Corporation Ethernet Connection I219-V [8086:1570] (rev 21)
        Subsystem: Intel Corporation Ethernet Connection I219-V [8086:0000]
        Kernel driver in use: e1000e
        Kernel modules: e1000e
02:00.0 Network controller [0280]: Intel Corporation Wireless 8260 [8086:24f3] (rev 3a)
        Subsystem: Intel Corporation Wireless 8260 [8086:1130]
        Kernel driver in use: iwlwifi

tina@L560:~$ ip link 
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: enp0s31f6: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN mode DEFAULT group default qlen 1000
    link/ether fc:45:96:68:08:5b brd ff:ff:ff:ff:ff:ff
4: wlp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DORMANT group default qlen 1000
    link/ether f4:8c:50:fb:a9:2d brd ff:ff:ff:ff:ff:ff
    

    tina@L560:~$ ip -4 addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
4: wlp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    inet 192.168.2.112/24 brd 192.168.2.255 scope global dynamic noprefixroute wlp2s0
       valid_lft 863042sec preferred_lft 863042sec 

tina@L560:~$ grep renderer /{lib,etc,run}/netplan/*yaml 
grep: /lib/netplan/*yaml: Datei oder Verzeichnis nicht gefunden
/etc/netplan/01-network-manager-all.yaml:  renderer: NetworkManager
grep: /run/netplan/*yaml: Datei oder Verzeichnis nicht gefunden

tina@L560:~$ nmcli general ; nmcli device ; nmcli connection 
STATE      CONNECTIVITY  WIFI-HW    WIFI       WWAN-HW    WWAN      
verbunden  vollständig   aktiviert  aktiviert  aktiviert  aktiviert 
DEVICE          TYPE      STATE            CONNECTION 
wlp2s0          wifi      verbunden        urnet      
p2p-dev-wlp2s0  wifi-p2p  nicht verbunden  --         
enp0s31f6       ethernet  nicht verfügbar  --         
lo              loopback  nicht verwaltet  --         
NAME                         UUID                                  TYPE      DEVICE 
urnet                        e967d1da-e0f7-4a1e-af1f-2ed9a3aa3da8  wifi      wlp2s0 
Kabelgebundene Verbindung 1  6cacffba-e252-3369-9b6d-1947abb3df7d  ethernet  --  

Weise bitte der "Kabelgebundenen Verbindung 1" mal ein Gerät zu im nm-connection-editor.

Habe im Reiter "Kabelgebunden" bei "auf Gerät beschränken" nun "enp0s31f6" ausgewählt. Das blieb aber wohl ohne Effekt:

tina@L560:~$ nmcli general ; nmcli device ; nmcli connection 
STATE      CONNECTIVITY  WIFI-HW    WIFI       WWAN-HW    WWAN      
verbunden  vollständig   aktiviert  aktiviert  aktiviert  aktiviert 
DEVICE          TYPE      STATE            CONNECTION 
wlp2s0          wifi      verbunden        urnet      
p2p-dev-wlp2s0  wifi-p2p  nicht verbunden  --         
enp0s31f6       ethernet  nicht verfügbar  --         
lo              loopback  nicht verwaltet  --         
NAME                         UUID                                  TYPE      DEVICE 
urnet                        e967d1da-e0f7-4a1e-af1f-2ed9a3aa3da8  wifi      wlp2s0 
Kabelgebundene Verbindung 1  6cacffba-e252-3369-9b6d-1947abb3df7d  ethernet  --

Mache mal bitte einen Neustart und poste die Ausgabe nochmal. Dann noch

sudo dmesg |egrep -i 'eth\e1000e'|

Neustart ohne Wirkung, dmesg ohne Ausgabe.

tina@L560:~$ nmcli general ; nmcli device ; nmcli connection
STATE      CONNECTIVITY  WIFI-HW    WIFI       WWAN-HW    WWAN      
verbunden  vollständig   aktiviert  aktiviert  aktiviert  aktiviert 
DEVICE          TYPE      STATE            CONNECTION 
wlp2s0          wifi      verbunden        urnet      
p2p-dev-wlp2s0  wifi-p2p  nicht verbunden  --         
enp0s31f6       ethernet  nicht verfügbar  --         
lo              loopback  nicht verwaltet  --         
NAME                         UUID                                  TYPE      DEVICE 
urnet                        e967d1da-e0f7-4a1e-af1f-2ed9a3aa3da8  wifi      wlp2s0 
Kabelgebundene Verbindung 1  6cacffba-e252-3369-9b6d-1947abb3df7d  ethernet  -- 

tina@L560:~$ sudo dmesg | egrep -i 'eth\e1000e'
tina@L560:~$

Gerade ist aufgefallen, daß die LEDs an der Netzwerkbuchse leuchten, wenn der Rechner im Ruhezustand ist. Wird der Ruhezustand beendet, gehen die LEDs sofort aus. Es ist wie als ob der LAN-Adapter schläft, wenn der Rechner wach ist und umgekehrt.

tina@L560:~$ ip link 
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: enp0s31f6: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN mode DEFAULT group default qlen 1000
    link/ether fc:45:96:68:08:5b brd ff:ff:ff:ff:ff:ff
4: wlp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DORMANT group default qlen 1000
    link/ether f4:8c:50:fb:a9:2d brd ff:ff:ff:ff:ff:ff

Der ist dann an wegen WakeonLAN, das sollte das UEFI kontrollieren.

svchost schrieb:

[…] Einstecken des Ethernet-LAN-Steckers ohne Reaktion

Prüfe ob das Ethernet-Kabel einen Defekt hat.

Wenn Das sicher ausgeschlossen werden kann,

1. entferne das Kabel vom Rechner,

2. starte den Rechner neu,

3. schreibe mit diesem Befehl eine Zeile in Logbuch:

   logger '===== e1000e =====' 

4. stecke dann das Ethernet-Kabel in den Rechner,

5. warte ca. 1 Minute ab,

6. und zeige uns dann den Logbuch-Auszug:

   journalctl -b  | grep e1000e 

   .

Kabel funktioniert sicher, ich kommuniziere in diesem Moment von einem anderen Rechner durch das Kabel mit diesem Forum. Die angeregte Prozedur habe ich um 11:49 durchgeführt, es findet sich also nach dem Einstecken des Netzwerkkabels nichts in der Ausgabe:

 
tina@L560:~$ logger '===== e1000e ====='
tina@L560:~$ journalctl -b  | grep e1000e
Sep 14 11:48:08 tina-ThinkPad kernel: e1000e: Intel(R) PRO/1000 Network Driver
Sep 14 11:48:08 tina-ThinkPad kernel: e1000e: Copyright(c) 1999 - 2015 Intel Corporation.
Sep 14 11:48:08 tina-ThinkPad kernel: e1000e 0000:00:1f.6: Interrupt Throttling Rate (ints/sec) set to dynamic conservative mode
Sep 14 11:48:08 tina-ThinkPad kernel: e1000e 0000:00:1f.6 0000:00:1f.6 (uninitialized): registered PHC clock
Sep 14 11:48:08 tina-ThinkPad kernel: e1000e 0000:00:1f.6 eth0: (PCI Express:2.5GT/s:Width x1) fc:45:96:68:08:5b
Sep 14 11:48:08 tina-ThinkPad kernel: e1000e 0000:00:1f.6 eth0: Intel(R) PRO/1000 Network Connection
Sep 14 11:48:08 tina-ThinkPad kernel: e1000e 0000:00:1f.6 eth0: MAC: 12, PHY: 12, PBA No: FFFFFF-0FF
Sep 14 11:48:08 tina-ThinkPad kernel: e1000e 0000:00:1f.6 enp0s31f6: renamed from eth0

svchost schrieb:

Kabel funktioniert sicher, ich kommuniziere in diesem Moment von einem anderen Rechner durch das Kabel mit diesem Forum.

Was passiert wenn Du bei Kabelverbindung, dem Interface die/eine IP-Adresse manuell zuweist? Z. B.:

sudo ifconfig enp0s31f6 inet 192.168.2.6 netmask 255.255.255.0 broadcast 192.168.2.255 up

danach:

ip a
route -n
arp -a
ping -c 3 -I enp0s31f6 -W 6 192.168.2.1

?

Nach

ifconfig enp0s31f6 inet 192.168.2.6 netmask 255.255.255.0 broadcast 192.168.2.255 up

meldet der KDE Netzwerkmanager, dass enp0s31f6 mit einem Netzwerk verbunden ist. Über das Netzwerk kommunizieren mag der Rechner aber dennoch nicht.

root@L560:/home/tina# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    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: enp0s31f6: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
    link/ether fc:45:96:68:08:5b brd ff:ff:ff:ff:ff:ff
    inet 192.168.2.6/24 brd 192.168.2.255 scope global enp0s31f6
       valid_lft forever preferred_lft forever
4: wlp2s0: <BROADCAST,MULTICAST> mtu 1500 qdisc noqueue state DOWN group default qlen 1000
    link/ether f4:8c:50:fb:a9:2d brd ff:ff:ff:ff:ff:ff

root@L560:/home/tina# route -n
Kernel-IP-Routentabelle
Ziel            Router          Genmask         Flags Metric Ref    Use Iface
192.168.2.0     0.0.0.0         255.255.255.0   U     0      0        0 enp0s31f6

root@L560:/home/tina# arp -a
? (192.168.2.1) auf <unvollständig> auf enp0s31f6
? (192.168.2.100) auf <unvollständig> auf enp0s31f6
? (192.168.2.112) auf <unvollständig> auf enp0s31f6

root@L560:/home/tina# ping -c 3 -I enp0s31f6 -W 6 192.168.2.1
PING 192.168.2.1 (192.168.2.1) from 192.168.2.6 enp0s31f6: 56(84) bytes of data.
From 192.168.2.6 icmp_seq=1 Destination Host Unreachable
From 192.168.2.6 icmp_seq=2 Destination Host Unreachable
From 192.168.2.6 icmp_seq=3 Destination Host Unreachable

--- 192.168.2.1 ping statistics ---
3 packets transmitted, 0 received, +3 errors, 100% packet loss, time 2035ms
pipe 3

Im NM ist für die Verbindung IPv6 deaktiviert, schalte das im nm-connection-editor an, sonst kann die Verbindung nicht funktionieren.

svchost schrieb:

Über das Netzwerk kommunizieren mag der Rechner aber dennoch nicht.

root@L560:/home/tina# arp -a
? (192.168.2.1) auf <unvollständig> auf enp0s31f6

Ja, das liegt daran, dass noch kein vollständiger arp-cache-Eintrag für den Router vorhanden ist. Konfiguriere einen statischen arp-cache-Eintrag für den Router. Dazu brauchst Du die _richtige_ MAC-Adresse (die btw. anders als die für die WLAN-Verbindung sein kann) vom Router. Schau in einem anderen Rechner der auch per Kabel verbunden ist nach. Wenn der arp-cache vollständig ist (arp -a), wiederhole den Ping auf den Router.

svchost schrieb:

[…] es findet sich also nach dem Einstecken des Netzwerkkabels nichts in der Ausgabe […]

Bitte zeige die komplette Ausgabe dieses Befehls:

 journalctl -b  | grep e1000e

Nach einigen Stunden und nahe am Rand der Verzweifelung kam die Idee auf, daß ein Hardwareproblem vorliegen könnte. Es wurde ein Portreplicator für das Lenovo L560 beschafft und siehe da: Über dessen RJ-45 läuft LAN mit e1000e makellos. Vielen Dank dennoch für eure Unterstützung!