Du bist nicht angemeldet.
Einige Anmerkungen:
Auf dem "kaputten" Host würde ich so mit tcpdump kucken:
tcpdump -n -p -e -i enp5s0f0
-e dumpt die Ethernet Header mit, dass du siehst, wer das Frame geschickt hat. Es ist auch immer günstig, einen Spickzettel zu haben, auf den die Zuordnung MAC-Adresse Hostname/IP steht (ip -4 n s).
So wie den Dump auf den ersten Blick aussieht, ruft der Host ständig ARP Requests raus, aber keiner antwortet.
Vielleicht solltest Du auch mal den Kernel updaten wegen: https://lkml.org/lkml/2020/6/29/2147
Beitrag geändert von segfault (03.07.2020 14:14:48)
Offline
Einige Anmerkungen:
Auf dem "kaputten" Host würde ich so mit tcpdump kucken:tcpdump -n -p -e -i enp5s0f0
Voila
Stecker raus/Stecker rein nach dem Zeitstempel 16:50:44.084084
$ sudo tcpdump -n -p -e -i enp5s0f0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on enp5s0f0, link-type EN10MB (Ethernet), capture size 262144 bytes
16:50:19.384577 00:19:99:71:d8:af > 33:33:00:00:00:16, ethertype IPv6 (0x86dd), length 110: :: > ff02::16: HBH ICMP6, multicast listener report v2, 2 group record(s), length 48
16:50:19.416262 00:19:99:71:d8:af > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 332: 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:19:99:71:d8:af, length 290
16:50:19.444594 00:19:99:71:d8:af > 33:33:00:00:00:16, ethertype IPv6 (0x86dd), length 110: :: > ff02::16: HBH ICMP6, multicast listener report v2, 2 group record(s), length 48
16:50:20.114571 00:19:99:71:d8:af > 33:33:ff:a8:c0:ad, ethertype IPv6 (0x86dd), length 86: :: > ff02::1:ffa8:c0ad: ICMP6, neighbor solicitation, who has fe80::9b48:3541:aa8:c0ad, length 32
16:50:20.434540 00:19:99:71:d8:af > 33:33:00:00:00:16, ethertype IPv6 (0x86dd), length 110: :: > ff02::16: HBH ICMP6, multicast listener report v2, 2 group record(s), length 48
16:50:21.154608 00:19:99:71:d8:af > 33:33:00:00:00:16, ethertype IPv6 (0x86dd), length 110: fe80::9b48:3541:aa8:c0ad > ff02::16: HBH ICMP6, multicast listener report v2, 2 group record(s), length 48
16:50:21.194540 00:19:99:71:d8:af > 33:33:00:00:00:16, ethertype IPv6 (0x86dd), length 110: fe80::9b48:3541:aa8:c0ad > ff02::16: HBH ICMP6, multicast listener report v2, 2 group record(s), length 48
16:50:21.342947 00:19:99:71:d8:af > 33:33:00:00:00:02, ethertype IPv6 (0x86dd), length 62: fe80::9b48:3541:aa8:c0ad > ff02::2: ICMP6, router solicitation, length 8
16:50:21.364494 00:19:99:71:d8:af > 33:33:00:00:00:16, ethertype IPv6 (0x86dd), length 110: fe80::9b48:3541:aa8:c0ad > ff02::16: HBH ICMP6, multicast listener report v2, 2 group record(s), length 48
16:50:21.416266 00:19:99:71:d8:af > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 332: 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:19:99:71:d8:af, length 290
16:50:21.574512 00:19:99:71:d8:af > 33:33:00:00:00:16, ethertype IPv6 (0x86dd), length 110: fe80::9b48:3541:aa8:c0ad > ff02::16: HBH ICMP6, multicast listener report v2, 2 group record(s), length 48
16:50:21.578156 00:19:99:71:d8:af > 33:33:00:00:00:fb, ethertype IPv6 (0x86dd), length 200: fe80::9b48:3541:aa8:c0ad.5353 > ff02::fb.5353: 0*- [0q] 2/0/0 (Cache flush) PTR warp10.local., (Cache flush) AAAA fe80::9b48:3541:aa8:c0ad (138)
16:50:23.783680 00:19:99:71:d8:af > 33:33:00:00:00:fb, ethertype IPv6 (0x86dd), length 200: fe80::9b48:3541:aa8:c0ad.5353 > ff02::fb.5353: 0*- [0q] 2/0/0 (Cache flush) PTR warp10.local., (Cache flush) AAAA fe80::9b48:3541:aa8:c0ad (138)
16:50:24.198627 00:19:99:71:d8:af > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 332: 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:19:99:71:d8:af, length 290
16:50:25.343932 00:19:99:71:d8:af > 33:33:00:00:00:02, ethertype IPv6 (0x86dd), length 62: fe80::9b48:3541:aa8:c0ad > ff02::2: ICMP6, router solicitation, length 8
16:50:28.941150 00:19:99:71:d8:af > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 332: 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:19:99:71:d8:af, length 290
16:50:29.343768 00:19:99:71:d8:af > 33:33:00:00:00:02, ethertype IPv6 (0x86dd), length 62: fe80::9b48:3541:aa8:c0ad > ff02::2: ICMP6, router solicitation, length 8
16:50:37.549982 00:19:99:71:d8:af > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 332: 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:19:99:71:d8:af, length 290
16:50:39.778283 00:19:99:71:1e:b9 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.178.51 tell 192.168.178.103, length 46
16:50:39.856391 00:19:99:71:d8:af > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 330: 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:19:99:71:d8:af, length 288
16:50:40.496642 00:19:99:71:1e:b9 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.178.51 tell 192.168.178.103, length 46
16:50:41.496582 00:19:99:71:1e:b9 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.178.51 tell 192.168.178.103, length 46
16:50:44.084084 00:19:99:71:d8:af > 33:33:00:00:00:02, ethertype IPv6 (0x86dd), length 70: fe80::9b48:3541:aa8:c0ad > ff02::2: ICMP6, router solicitation, length 16
--------------------------------------------------------------------------------
hier umstecken und kurz danach ist das Interface funktionstüchtig
--------------------------------------------------------------------------------
16:51:12.475743 00:19:99:71:d8:af > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 330: 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:19:99:71:d8:af, length 288
16:51:12.480436 24:65:11:e1:1b:18 > 00:19:99:71:d8:af, ethertype IPv4 (0x0800), length 590: 192.168.178.1.67 > 192.168.178.110.68: BOOTP/DHCP, Reply, length 548
16:51:12.480604 00:19:99:71:d8:af > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 342: 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:19:99:71:d8:af, length 300
16:51:12.481923 00:19:99:71:d8:af > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 332: 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:19:99:71:d8:af, length 290
16:51:12.482000 24:65:11:e1:1b:18 > 00:19:99:71:d8:af, ethertype IPv4 (0x0800), length 590: 192.168.178.1.67 > 192.168.178.110.68: BOOTP/DHCP, Reply, length 548
16:51:12.484583 24:65:11:e1:1b:18 > 00:19:99:71:d8:af, ethertype IPv4 (0x0800), length 590: 192.168.178.1.67 > 192.168.178.110.68: BOOTP/DHCP, Reply, length 548
16:51:12.504467 00:19:99:71:d8:af > 01:00:5e:00:00:16, ethertype IPv4 (0x0800), length 54: 192.168.178.110 > 224.0.0.22: igmp v3 report, 1 group record(s)
16:51:12.504479 00:19:99:71:d8:af > 33:33:00:00:00:16, ethertype IPv6 (0x86dd), length 110: :: > ff02::16: HBH ICMP6, multicast listener report v2, 2 group record(s), length 48
16:51:12.594557 00:19:99:71:d8:af > 33:33:ff:a8:c0:ad, ethertype IPv6 (0x86dd), length 86: :: > ff02::1:ffa8:c0ad: ICMP6, neighbor solicitation, who has fe80::9b48:3541:aa8:c0ad, length 32
16:51:12.661649 00:19:99:71:d8:af > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 252: 192.168.178.110.5353 > 224.0.0.251.5353: 0 [3q] [4n] ANY (QM)? d.a.0.c.8.a.a.0.1.4.5.3.8.4.b.9.0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa. ANY (QM)? warp10.local. ANY (QM)? 110.178.168.192.in-addr.arpa. (210)
16:51:12.731348 00:19:99:71:d8:af > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.178.1 tell 192.168.178.110, length 28
16:51:12.731803 24:65:11:e1:1b:18 > 00:19:99:71:d8:af, ethertype ARP (0x0806), length 60: Reply 192.168.178.1 is-at 24:65:11:e1:1b:18, length 46
16:51:12.731812 00:19:99:71:d8:af > 24:65:11:e1:1b:18, ethertype IPv4 (0x0800), length 77: 192.168.178.110.42494 > 192.168.178.1.53: 62902+ A? www.archlinux.org. (35)
16:51:12.731815 00:19:99:71:d8:af > 24:65:11:e1:1b:18, ethertype IPv4 (0x0800), length 77: 192.168.178.110.54563 > 192.168.178.1.53: 48871+ AAAA? www.archlinux.org. (35)
16:51:12.732994 24:65:11:e1:1b:18 > 00:19:99:71:d8:af, ethertype IPv4 (0x0800), length 212: 192.168.178.1.53 > 192.168.178.110.42494: 62902 2/3/0 CNAME apollo.archlinux.org., A 138.201.81.199 (170)
16:51:12.733338 24:65:11:e1:1b:18 > 00:19:99:71:d8:af, ethertype IPv4 (0x0800), length 224: 192.168.178.1.53 > 192.168.178.110.54563: 48871 2/3/0 CNAME apollo.archlinux.org., AAAA 2a01:4f8:172:1d86::1 (182)
16:51:12.798252 00:19:99:71:d8:af > 24:65:11:e1:1b:18, ethertype IPv4 (0x0800), length 74: 192.168.178.110.49778 > 138.201.81.199.80: Flags [S], seq 4022329118, win 64240, options [mss 1460,sackOK,TS val 1902284791 ecr 0,nop,wscale 7], length 0
16:51:12.849703 24:65:11:e1:1b:18 > 00:19:99:71:d8:af, ethertype IPv4 (0x0800), length 74: 138.201.81.199.80 > 192.168.178.110.49778: Flags [S.], seq 2134788498, ack 4022329119, win 65160, options [mss 1452,sackOK,TS val 2005124632 ecr 1902284791,nop,wscale 7], length 0
16:51:12.849758 00:19:99:71:d8:af > 24:65:11:e1:1b:18, ethertype IPv4 (0x0800), length 66: 192.168.178.110.49778 > 138.201.81.199.80: Flags [.], ack 1, win 502, options [nop,nop,TS val 1902284843 ecr 2005124632], length 0
16:51:12.849817 00:19:99:71:d8:af > 24:65:11:e1:1b:18, ethertype IPv4 (0x0800), length 165: 192.168.178.110.49778 > 138.201.81.199.80: Flags [P.], seq 1:100, ack 1, win 502, options [nop,nop,TS val 1902284843 ecr 2005124632], length 99: HTTP: GET /check_network_status.txt HTTP/1.1
16:51:12.893695 24:65:11:e1:1b:18 > 00:19:99:71:d8:af, ethertype IPv4 (0x0800), length 66: 138.201.81.199.80 > 192.168.178.110.49778: Flags [.], ack 100, win 509, options [nop,nop,TS val 2005124675 ecr 1902284843], length 0
16:51:12.893802 24:65:11:e1:1b:18 > 00:19:99:71:d8:af, ethertype IPv4 (0x0800), length 276: 138.201.81.199.80 > 192.168.178.110.49778: Flags [P.], seq 1:211, ack 100, win 509, options [nop,nop,TS val 2005124675 ecr 1902284843], length 210: HTTP: HTTP/1.1 200 OK
16:51:12.893817 00:19:99:71:d8:af > 24:65:11:e1:1b:18, ethertype IPv4 (0x0800), length 66: 192.168.178.110.49778 > 138.201.81.199.80: Flags [.], ack 211, win 501, options [nop,nop,TS val 1902284887 ecr 2005124675], length 0
16:51:12.893911 00:19:99:71:d8:af > 24:65:11:e1:1b:18, ethertype IPv4 (0x0800), length 66: 192.168.178.110.49778 > 138.201.81.199.80: Flags [F.], seq 100, ack 211, win 501, options [nop,nop,TS val 1902284887 ecr 2005124675], length 0
16:51:12.894121 24:65:11:e1:1b:18 > 00:19:99:71:d8:af, ethertype IPv4 (0x0800), length 66: 138.201.81.199.80 > 192.168.178.110.49778: Flags [F.], seq 211, ack 100, win 509, options [nop,nop,TS val 2005124675 ecr 1902284843], length 0
16:51:12.894137 00:19:99:71:d8:af > 24:65:11:e1:1b:18, ethertype IPv4 (0x0800), length 66: 192.168.178.110.49778 > 138.201.81.199.80: Flags [.], ack 212, win 501, options [nop,nop,TS val 1902284887 ecr 2005124675], length 0
16:51:12.912319 00:19:99:71:d8:af > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 252: 192.168.178.110.5353 > 224.0.0.251.5353: 0 [3q] [4n] ANY (QM)? d.a.0.c.8.a.a.0.1.4.5.3.8.4.b.9.0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa. ANY (QM)? warp10.local. ANY (QM)? 110.178.168.192.in-addr.arpa. (210)
16:51:12.945957 24:65:11:e1:1b:18 > 00:19:99:71:d8:af, ethertype IPv4 (0x0800), length 66: 138.201.81.199.80 > 192.168.178.110.49778: Flags [.], ack 101, win 509, options [nop,nop,TS val 2005124728 ecr 1902284887], length 0
16:51:13.044571 00:19:99:71:d8:af > 33:33:00:00:00:16, ethertype IPv6 (0x86dd), length 110: :: > ff02::16: HBH ICMP6, multicast listener report v2, 2 group record(s), length 48
16:51:13.064527 00:19:99:71:d8:af > 01:00:5e:00:00:16, ethertype IPv4 (0x0800), length 54: 192.168.178.110 > 224.0.0.22: igmp v3 report, 1 group record(s)
16:51:13.162864 00:19:99:71:d8:af > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 252: 192.168.178.110.5353 > 224.0.0.251.5353: 0 [3q] [4n] ANY (QM)? d.a.0.c.8.a.a.0.1.4.5.3.8.4.b.9.0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa. ANY (QM)? warp10.local. ANY (QM)? 110.178.168.192.in-addr.arpa. (210)
16:51:13.363065 00:19:99:71:d8:af > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 234: 192.168.178.110.5353 > 224.0.0.251.5353: 0*- [0q] 4/0/0 (Cache flush) PTR warp10.local., (Cache flush) A 192.168.178.110, (Cache flush) PTR warp10.local., (Cache flush) AAAA fe80::9b48:3541:aa8:c0ad (192)
16:51:13.479239 00:19:99:71:d8:af > 24:65:11:e1:1b:18, ethertype IPv4 (0x0800), length 71: 192.168.178.110.57956 > 192.168.178.1.53: 58301+ A? mozilla.org. (29)
# Nach dem Umstecken (Sollte das vor dem Umstecken in der nächsten Runde anders aussehen, trage ich das noch nach)
$ ip -4 n s
192.168.178.1 dev enp5s0f0 lladdr 24:65:11:e1:1b:18 REACHABLE
Vielleicht solltest Du auch mal den Kernel updaten wegen: https://lkml.org/lkml/2020/6/29/2147
$ sudo pacman -Syu
:: Synchronizing package databases...
core 134.1 KiB 958 KiB/s 00:00 [###############################] 100%
extra is up to date
community 5.0 MiB 1098 KiB/s 00:05 [###############################] 100%
:: Starting full system upgrade...
resolving dependencies...
looking for conflicting packages...
Packages (8) curl-7.71.1-1 libappindicator-gtk3-12.10.0.r296-1 linux-lts-5.4.50-1
linux-lts-headers-5.4.50-1 popt-1.18-1 qt5-base-5.15.0-4 r8168-lts-8.048.03-8
tslib-1.22-1
Total Download Size: 102.80 MiB
Total Installed Size: 251.97 MiB
Net Upgrade Size: 0.03 MiB
:: Proceed with installation? [Y/n] y
:: Retrieving packages...
curl-7.71.1-1-x86_64 1039.4 KiB 1444 KiB/s 00:01 [###############################] 100%
popt-1.18-1-x86_64 67.7 KiB 3.30 MiB/s 00:00 [###############################] 100%
linux-lts-5.4.50-1-x86_64 68.3 MiB 1795 KiB/s 00:39 [###############################] 100%
linux-lts-headers-5.4.5... 20.2 MiB 1854 KiB/s 00:11 [###############################] 100%
tslib-1.22-1-x86_64 100.0 KiB 2001 KiB/s 00:00 [###############################] 100%
qt5-base-5.15.0-4-x86_64 12.9 MiB 1786 KiB/s 00:07 [###############################] 100%
libappindicator-gtk3-12... 52.6 KiB 1053 KiB/s 00:00 [###############################] 100%
r8168-lts-8.048.03-8-x86_64 115.5 KiB 1651 KiB/s 00:00 [###############################] 100%
(8/8) checking keys in keyring [###############################] 100%
(8/8) checking package integrity [###############################] 100%
(8/8) loading package files [###############################] 100%
(8/8) checking for file conflicts [###############################] 100%
(8/8) checking available disk space [###############################] 100%
:: Running pre-transaction hooks...
(1/1) Removing linux initcpios...
:: Processing package changes...
(1/8) upgrading curl [###############################] 100%
(2/8) upgrading popt [###############################] 100%
(3/8) upgrading libappindicator-gtk3 [###############################] 100%
(4/8) upgrading linux-lts [###############################] 100%
(5/8) upgrading linux-lts-headers [###############################] 100%
(6/8) upgrading tslib [###############################] 100%
(7/8) upgrading qt5-base [###############################] 100%
(8/8) upgrading r8168-lts [###############################] 100%
:: Running post-transaction hooks...
(1/3) Arming ConditionNeedsUpdate...
(2/3) Updating module dependencies...
(3/3) Updating linux initcpios...
==> Building image from preset: /etc/mkinitcpio.d/linux-lts.preset: 'default'
-> -k /boot/vmlinuz-linux-lts -c /etc/mkinitcpio.conf -g /boot/initramfs-linux-lts.img
==> Starting build: 5.4.50-1-lts
-> Running build hook: [base]
-> Running build hook: [udev]
-> Running build hook: [autodetect]
-> Running build hook: [modconf]
-> Running build hook: [block]
-> Running build hook: [lvm2]
-> Running build hook: [filesystems]
-> Running build hook: [keyboard]
-> Running build hook: [fsck]
==> Generating module dependencies
==> Creating gzip-compressed initcpio image: /boot/initramfs-linux-lts.img
==> Image generation successful
==> Building image from preset: /etc/mkinitcpio.d/linux-lts.preset: 'fallback'
-> -k /boot/vmlinuz-linux-lts -c /etc/mkinitcpio.conf -g /boot/initramfs-linux-lts-fallback.img -S autodetect
==> Starting build: 5.4.50-1-lts
-> Running build hook: [base]
-> Running build hook: [udev]
-> Running build hook: [modconf]
-> Running build hook: [block]
==> WARNING: Possibly missing firmware for module: wd719x
==> WARNING: Possibly missing firmware for module: aic94xx
-> Running build hook: [lvm2]
-> Running build hook: [filesystems]
-> Running build hook: [keyboard]
-> Running build hook: [fsck]
==> Generating module dependencies
==> Creating gzip-compressed initcpio image: /boot/initramfs-linux-lts-fallback.img
==> Image generation successful
$
Der Update hat nicht zur Beseitigung des primären Problems geführt.
Edit: Das ip -4 n s gibt im Fehlerfall (also vor dem Umstecken) nichts aus.
Beitrag geändert von tomsam (03.07.2020 16:30:28)
Offline
Es ist schon interessant was das in den tcpdumps steht. Im Fall 1 hast Du ausgehenden Traffic, aber nichts (außer Layer2 Broadcast) kommt zurück. Nach Reseten des Links hast Du plötzlich auch eingehendes Unicast und plötzlich klappt alles. Das sieht für mich wie ein defekter Treiber/NIC aus. Was ich Dir da so richtig raten soll weiss ich nicht. Du könntest versuchen einen Workaround zu bauen. Zum Beispiel im Zustand "defekt" zu schauen, ob ein "ip link set down dev enp5s0f0" + "ip link set up dev enp5s0f0" etwas bringt. Falls ja, dann kannst Du ja eine kleine systemd Unit schreiben die beim Systemstart das macht. Du könntest auch mal in der Linux netdev Mailingliste vorsprechen. Vielleicht kann man Dir da helfen.
Beitrag geändert von segfault (04.07.2020 04:46:06)
Offline
Das sieht für mich wie ein defekter Treiber/NIC aus.
Ja, die Treiber werden wohl irgendwo ein paar Macken haben (der r8168 genau wie der r8169).
Da das Ganze mit vielen der anderen Distributionen funktioniert und die natürlich den Treiber auch nicht selbst geschrieben haben,
vermute ich aber weiterhin, dass es einen mehr oder weniger trivialen Workaround gibt.
Thema defekte NIC: Das Verhalten an dem baugleichen System meines Vaters ist identisch. Dann müssten schon beide NICs defekt sein.
Zum Beispiel im Zustand "defekt" zu schauen, ob ein "ip link set down dev enp5s0f0" + "ip link set up dev enp5s0f0" etwas bringt. Falls ja, dann kannst Du ja eine kleine systemd Unit schreiben die beim Systemstart das macht. Du könntest auch mal in der Linux netdev Mailingliste vorsprechen. Vielleicht kann man Dir da helfen.
Das hilft leider nicht (Das hatte ich ja als erstes probiert, noch bevor ich dieses Topic überhaupt angefangen habe )
Ich werd noch ein wenig weiter testen.
Edit: Mail an Realtek ist raus. Mal schauen, was die zu dem Thema sagen.
Beitrag geändert von tomsam (06.07.2020 08:26:34)
Offline
So, weiterer Zwischenbericht:
Realtek hat natürlich nicht geantwortet!
Dann hab ich parallel jeweils auf einer Installation Mint 20 XFCE (dort mit direkt von der Realtek Seite geladenen 8168 Treibersourcen) und Arch-LTS (beide 5.4.* Kernel) das Folgende getan:
Dem Treiber README konnte man entnehmen, dass man ggf. Kernel Modulparameter fix setzen sollte, somit hab ich nun ein /etc/modprobe.d/r8168.conf angelegt mit dem Inhalt
options r8168 speed_mode=100 duplex_mode=1 autoneg_mode=1
welches auch gelesen wird (da ich - wie im README zu lesen - beim ersten Mal all die Optionen ohne _mode geschrieben hatte und eine Fehlermeldung in den dmesg hochkam). Unter Mint hab ich dann die Advanced Network Settings aufgerufen und dort den Eintrag für Autonegotiation ebenfalls auf Auto gesetzt und ipv6 deaktiviert. Letzteres war final aber nicht ausschlaggebend. Danach funktionierte die Karte unter Mint20 und sie verhält sich auch beim Reboot nicht falsch (Am Switch sieht man während des Reboots kurz "Led aus", "Led an")!
Also frohen Mutes in die Arch Installation und dort systemd_networkd deaktiert und Networkmanager aktiviert. Auch hier verbindet sich die Karte (nach einem Link down, Link up durch den NetworkManager in den Logs) beim Starten korrekt. Allerdings zersetzt es hier die Karte beim Reboot oder Herunterfahren mit den schon vorher genannten Problemen, dass man beides, Rechner und Switch für mehrere Minuten vom Strom nehmen muss (Am Switch sieht man beim Reboot in diesem Szenario nur "Led aus").
NetworkManager wieder deaktiviert, systemd_networkd wieder aktiviert, ethtool installiert.
$ sudo ethtool enp5s0f0
netlink error: No such file or directory
Settings for enp5s0f0:
Supported ports: [ TP ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Supported pause frame use: Symmetric Receive-only
Supports auto-negotiation: Yes
Supported FEC modes: Not reported
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Advertised pause frame use: Symmetric Receive-only
Advertised auto-negotiation: Yes
Advertised FEC modes: Not reported
Link partner advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Link partner advertised pause frame use: Symmetric
Link partner advertised auto-negotiation: Yes
Link partner advertised FEC modes: Not reported
Speed: 100Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 0
Transceiver: internal
Auto-negotiation: on
MDI-X: Unknown
Supports Wake-on: pumbg
Wake-on: g
Current message level: 0x00000033 (51)
drv probe ifdown ifup
Link detected: yes
$ ping 8.8.8.8
ping: connect: Network is unreachable
$ sudo /usr/bin/ethtool -s enp5s0f0 autoneg on
netlink error: No such file or directory
$ 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
2: enp5s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 00:19:99:71:d8:af brd ff:ff:ff:ff:ff:ff
inet 192.168.178.110/24 brd 192.168.178.255 scope global dynamic enp5s0f0
valid_lft 863990sec preferred_lft 863990sec
inet6 fe80::219:99ff:fe71:d8af/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=115 time=44.6 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=115 time=49.8 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=115 time=46.8 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=115 time=60.3 ms
^C
--- 8.8.8.8 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3006ms
rtt min/avg/max/mdev = 44.649/50.366/60.258/5.994 ms
Das Interface reported also bereits AutoNeg als on und nur alleine das Triggern mit dem zweiten - eigentlich unnützen - ethtool Kommando führt dazu, dass es nun auch eine Adresse bezieht.
Es verbleibt das Problem beim Herunterfahren: Hat jemand eine Idee, weshalb sich der Treiber unter Arch hier anders verhält?
PS Und so nebenbei: Gibt es eine Erklärung dafür, dass ein frisch installiertes ethtool den Fehler "netlink error: No such file or directory" bringt?
Offline
Bevor ich hier unten weiter den Workaround vorstelle, möchte ich die Frage stellen, wieso der folgende (enable-te) Service:
> cat trigger8168.service
[Unit]
Description=Trigger 8168
After=network-online.target
Wants=network-online.target
[Service]
Type=oneshot
ExecStart=/usr/sbin/ethtool -s enp5s0f0 autoneg on
[Install]
WantedBy=multi-user.target
de-facto zweimal innerhalb sehr kurzer Zeit einen Eintrag erzeugt:
[ 129.975398] audit: type=1130 audit(1594826009.613:56): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=trigger8168 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
[ 129.975404] audit: type=1131 audit(1594826009.613:57): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=trigger8168 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
[ 130.558204] r8168: enp5s0f0: link down
[ 133.220426] r8168: enp5s0f0: link up
und wieso es ab und an bis zu 1 Minute nach dem Einloggen dauern kann, bis er ausgeführt wird. Das trigger8168 soll natürlich, sofern möglich, dann ausgeführt werden, wenn das Interface zur Verfügung steht, bestenfalls natürlich noch bevor der User überhaupt was tippt.
---
Bei der Analyse der möglichen Moduleparameter sind mir drei Werte ins Auge gestochen, dich ich allesamt in die oben genannte Kernelparameterdatei aufgenommen habe, wobei aber letztlich der Parameter s5wol=1 (Wake on LAN) derjenige ist, der dazu führt, dass das Interface beim rebooten nicht heruntergefahren und unnutzbar gemacht wird, selbst wenn ich Wake on LAN bei mir im BIOS deaktiviert habe.
Die Datei /etc/modprobe.d/r8168.conf sieht also bei mir nun wie folgt aus
options r8168 speed_mode=100 duplex_mode=1 autoneg_mode=1 s5wol=1
Im Makefile von Realtek ist dieser Wert standardmäßig gesetzt:
Makefile:ENABLE_S5WOL = y
weshalb die von mir selbst übersetzte Variante unter Mint 20 sofort und auch ohne explizite Nennung in der Kernelparameterdatei funktioniert hat.
Es liegt die Vermutung nahe, dass aus unbekannten Gründen dieses Setting bei der Paketierung des r8168-lts Pakets verloren gegangen ist.
Ist https://www.archlinux.org/packages/comm … r8168-lts/ die richtige Stelle, um dieses zu adressieren?
Offline
Der Package Maintainer für das r8168-lts hat das zweite Problem gefixed (s5wol).
Es wurden nicht das Standard-Makefile und somit auch nicht die Defaultsettings verwendet.
Das nunmehr vorhandene r8168-lts-8.048.03-11 benutzt die Defaults und braucht auch kein s5wol=1 mehr.
Dasselbe dürfte für das r8168-8.048.03-12 gelten, welches ich aber nicht getestet habe.
Offline