Du bist nicht angemeldet.

Seiten: 1 2

Beitrag schreiben

#26 03.07.2020 14:14:15

segfault
Mitglied

Re: Kein Netzwerk beim Installieren (Realtek 8111/8168/8411)

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

#27 03.07.2020 16:22:22

tomsam
Mitglied

Re: Kein Netzwerk beim Installieren (Realtek 8111/8168/8411)

segfault schrieb:

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

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

#28 04.07.2020 04:43:37

segfault
Mitglied

Re: Kein Netzwerk beim Installieren (Realtek 8111/8168/8411)

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

#29 04.07.2020 08:40:27

tomsam
Mitglied

Re: Kein Netzwerk beim Installieren (Realtek 8111/8168/8411)

segfault schrieb:

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.

segfault schrieb:

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 wink )

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

#30 15.07.2020 11:29:04

tomsam
Mitglied

Re: Kein Netzwerk beim Installieren (Realtek 8111/8168/8411)

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

#31 15.07.2020 16:51:48

tomsam
Mitglied

Re: Kein Netzwerk beim Installieren (Realtek 8111/8168/8411)

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

#32 22.07.2020 10:03:43

tomsam
Mitglied

Re: Kein Netzwerk beim Installieren (Realtek 8111/8168/8411)

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

Seiten: 1 2

Beitrag schreiben

Schnellantwort auf dieses Thema

Schreibe deinen Beitrag und versende ihn
Deine Antwort

Fußzeile des Forums