Du bist nicht angemeldet.

Eine Antwort schreiben

Schreibe deinen Beitrag und versende ihn
Beitragsoptionen
Deine Antwort

Zurück

Themen-Übersicht (Neuester Beitrag zuerst)

tomsam
22.07.2020 11:03:43

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.

tomsam
15.07.2020 17:51:48

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?

tomsam
15.07.2020 12:29:04

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?

tomsam
04.07.2020 09:40:27
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.

segfault
04.07.2020 05:43:37

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.

tomsam
03.07.2020 17:22:22
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.

segfault
03.07.2020 15:14:15

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

tomsam
03.07.2020 10:53:35
tomsam schrieb:
segfault schrieb:

Ich würde prüfen, was passiert, wenn man "zu Fuß" eine Adresse vergibt: "ip addr add 1.2.3.4/nn dev <device>". Ansonsten mit tcpdump debuggen, was mit dem DHCP los ist.

Während meiner Tests hatte ich auch versucht, per .network Konfiguration eine feste Adresse zu vergeben. Das hatte nicht funktioniert.
Bei nächsten Fehlschlag werde ich deinen Vorschlag händisch ausprobieren.

Das manuelle Setzen hat nicht zum Erfolg geführt. Einen tcpdump habe ich unten angehängt (oder sollte der mit anderen Parametern laufen?).
Für mich sieht das erstmal so aus, als ob da nur ipv4 gequasselt wird (obwohl die FB ipv6 können sollte)
Deswegen noch mal die Frage: Was wäre zu tun, damit das Interface von Anfang an nur ipv4 spricht.
Der oben genannte Kernel Parameter hat ja nicht funktioniert und auch das Verändern von /etc/sysctl.d/40-ipv6.conf,
aka so was wie

net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.enp5s0f0.disable_ipv6 = 1

führt nur dazu, dass das Interface gar nicht mehr da ist. Auch der Eintrag DHCP=ipv4 in der .network Datei (anstatt DHCP=yes) half nicht.


Der tcpdump

$ sudo tcpdump -xvv host 192.168.178.1

tcpdump: listening on enp5s0f0, link-type EN10MB (Ethernet), capture size 262144 bytes
10:24:52.482879 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.178.1 tell warp10, length 28
	0x0000:  0001 0800 0604 0001 0019 9971 d8af c0a8
	0x0010:  b2e9 0000 0000 0000 c0a8 b201
10:24:53.521377 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.178.1 tell warp10, length 28
	0x0000:  0001 0800 0604 0001 0019 9971 d8af c0a8
	0x0010:  b2e9 0000 0000 0000 c0a8 b201
10:24:54.561369 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.178.1 tell warp10, length 28
	0x0000:  0001 0800 0604 0001 0019 9971 d8af c0a8
	0x0010:  b2e9 0000 0000 0000 c0a8 b201
10:24:55.601490 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.178.1 tell warp10, length 28
	0x0000:  0001 0800 0604 0001 0019 9971 d8af c0a8
	0x0010:  b2e9 0000 0000 0000 c0a8 b201
10:24:55.895055 IP (tos 0x0, ttl 4, id 12560, offset 0, flags [none], proto UDP (17), length 151)
    192.168.178.1.53123 > 239.255.255.250.ssdp: [udp sum ok] UDP, length 123
	0x0000:  4500 0097 3110 0000 0411 22a2 c0a8 b201
	0x0010:  efff fffa cf83 076c 0083 a9d3 4d2d 5345
	0x0020:  4152 4348 202a 2048 5454 502f 312e 310d
	0x0030:  0a48 4f53 543a 2032 3339 2e32 3535 2e32
	0x0040:  3535 2e32 3530 3a31 3930 300d 0a4d 414e
	0x0050:  3a20 2273 7364 703a 6469 7363 6f76 6572
	0x0060:  220d 0a4d 583a 2035 0d0a 5354 3a20 7572
	0x0070:  6e3a 7363 6865 6d61 732d 7570 6e70 2d6f
	0x0080:  7267 3a64 6576 6963 653a 6176 6d2d 6168
	0x0090:  613a 310d 0a0d 0a
10:24:56.641357 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.178.1 tell warp10, length 28
	0x0000:  0001 0800 0604 0001 0019 9971 d8af c0a8
	0x0010:  b2e9 0000 0000 0000 c0a8 b201
10:24:57.681362 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.178.1 tell warp10, length 28
	0x0000:  0001 0800 0604 0001 0019 9971 d8af c0a8
	0x0010:  b2e9 0000 0000 0000 c0a8 b201
10:24:58.721471 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.178.1 tell warp10, length 28
	0x0000:  0001 0800 0604 0001 0019 9971 d8af c0a8
	0x0010:  b2e9 0000 0000 0000 c0a8 b201
10:24:59.761378 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.178.1 tell warp10, length 28
	0x0000:  0001 0800 0604 0001 0019 9971 d8af c0a8
	0x0010:  b2e9 0000 0000 0000 c0a8 b201
10:25:00.801378 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.178.1 tell warp10, length 28
	0x0000:  0001 0800 0604 0001 0019 9971 d8af c0a8
	0x0010:  b2e9 0000 0000 0000 c0a8 b201
10:25:00.895299 IP (tos 0x0, ttl 4, id 12561, offset 0, flags [none], proto UDP (17), length 151)
    192.168.178.1.53123 > 239.255.255.250.ssdp: [udp sum ok] UDP, length 123
	0x0000:  4500 0097 3111 0000 0411 22a1 c0a8 b201
	0x0010:  efff fffa cf83 076c 0083 a9d3 4d2d 5345
	0x0020:  4152 4348 202a 2048 5454 502f 312e 310d
	0x0030:  0a48 4f53 543a 2032 3339 2e32 3535 2e32
	0x0040:  3535 2e32 3530 3a31 3930 300d 0a4d 414e
	0x0050:  3a20 2273 7364 703a 6469 7363 6f76 6572
	0x0060:  220d 0a4d 583a 2035 0d0a 5354 3a20 7572
	0x0070:  6e3a 7363 6865 6d61 732d 7570 6e70 2d6f
	0x0080:  7267 3a64 6576 6963 653a 6176 6d2d 6168
	0x0090:  613a 310d 0a0d 0a
10:25:01.841484 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.178.1 tell warp10, length 28
	0x0000:  0001 0800 0604 0001 0019 9971 d8af c0a8
	0x0010:  b2e9 0000 0000 0000 c0a8 b201
10:25:02.881370 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.178.1 tell warp10, length 28
	0x0000:  0001 0800 0604 0001 0019 9971 d8af c0a8
	0x0010:  b2e9 0000 0000 0000 c0a8 b201
10:25:03.921358 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.178.1 tell warp10, length 28
	0x0000:  0001 0800 0604 0001 0019 9971 d8af c0a8
	0x0010:  b2e9 0000 0000 0000 c0a8 b201
10:25:05.895363 IP (tos 0x0, ttl 4, id 12562, offset 0, flags [none], proto UDP (17), length 151)
    192.168.178.1.53123 > 239.255.255.250.ssdp: [udp sum ok] UDP, length 123
	0x0000:  4500 0097 3112 0000 0411 22a0 c0a8 b201
	0x0010:  efff fffa cf83 076c 0083 a9d3 4d2d 5345
	0x0020:  4152 4348 202a 2048 5454 502f 312e 310d
	0x0030:  0a48 4f53 543a 2032 3339 2e32 3535 2e32
	0x0040:  3535 2e32 3530 3a31 3930 300d 0a4d 414e
	0x0050:  3a20 2273 7364 703a 6469 7363 6f76 6572
	0x0060:  220d 0a4d 583a 2035 0d0a 5354 3a20 7572
	0x0070:  6e3a 7363 6865 6d61 732d 7570 6e70 2d6f
	0x0080:  7267 3a64 6576 6963 653a 6176 6d2d 6168
	0x0090:  613a 310d 0a0d 0a
10:25:05.962852 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.178.1 tell warp10, length 28
	0x0000:  0001 0800 0604 0001 0019 9971 d8af c0a8
	0x0010:  b2e9 0000 0000 0000 c0a8 b201
10:25:07.041360 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.178.1 tell warp10, length 28
	0x0000:  0001 0800 0604 0001 0019 9971 d8af c0a8
	0x0010:  b2e9 0000 0000 0000 c0a8 b201
10:25:08.081360 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.178.1 tell warp10, length 28
	0x0000:  0001 0800 0604 0001 0019 9971 d8af c0a8
	0x0010:  b2e9 0000 0000 0000 c0a8 b201
10:25:09.121489 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.178.1 tell warp10, length 28
	0x0000:  0001 0800 0604 0001 0019 9971 d8af c0a8
	0x0010:  b2e9 0000 0000 0000 c0a8 b201
10:25:10.161357 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.178.1 tell warp10, length 28
	0x0000:  0001 0800 0604 0001 0019 9971 d8af c0a8
	0x0010:  b2e9 0000 0000 0000 c0a8 b201
10:25:11.201363 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.178.1 tell warp10, length 28
	0x0000:  0001 0800 0604 0001 0019 9971 d8af c0a8
	0x0010:  b2e9 0000 0000 0000 c0a8 b201
10:25:12.241459 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.178.1 tell warp10, length 28
	0x0000:  0001 0800 0604 0001 0019 9971 d8af c0a8
	0x0010:  b2e9 0000 0000 0000 c0a8 b201
10:25:13.281362 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.178.1 tell warp10, length 28
	0x0000:  0001 0800 0604 0001 0019 9971 d8af c0a8
	0x0010:  b2e9 0000 0000 0000 c0a8 b201
10:25:14.321373 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.178.1 tell warp10, length 28
	0x0000:  0001 0800 0604 0001 0019 9971 d8af c0a8
	0x0010:  b2e9 0000 0000 0000 c0a8 b201
10:25:15.361480 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.178.1 tell warp10, length 28
	0x0000:  0001 0800 0604 0001 0019 9971 d8af c0a8
	0x0010:  b2e9 0000 0000 0000 c0a8 b201
10:25:16.401356 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.178.1 tell warp10, length 28
	0x0000:  0001 0800 0604 0001 0019 9971 d8af c0a8
	0x0010:  b2e9 0000 0000 0000 c0a8 b201
10:25:17.441380 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.178.1 tell warp10, length 28
	0x0000:  0001 0800 0604 0001 0019 9971 d8af c0a8
	0x0010:  b2e9 0000 0000 0000 c0a8 b201
10:25:18.482547 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.178.1 tell warp10, length 28
	0x0000:  0001 0800 0604 0001 0019 9971 d8af c0a8
	0x0010:  b2e9 0000 0000 0000 c0a8 b201
10:25:19.531321 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.178.1 tell warp10, length 28
	0x0000:  0001 0800 0604 0001 0019 9971 d8af c0a8
	0x0010:  b2e9 0000 0000 0000 c0a8 b201
10:25:20.571312 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.178.1 tell warp10, length 28
	0x0000:  0001 0800 0604 0001 0019 9971 d8af c0a8
	0x0010:  b2e9 0000 0000 0000 c0a8 b201
10:25:21.611490 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.178.1 tell warp10, length 28
	0x0000:  0001 0800 0604 0001 0019 9971 d8af c0a8
	0x0010:  b2e9 0000 0000 0000 c0a8 b201
10:25:22.641355 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.178.1 tell warp10, length 28
	0x0000:  0001 0800 0604 0001 0019 9971 d8af c0a8
	0x0010:  b2e9 0000 0000 0000 c0a8 b201
10:25:23.681359 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.178.1 tell warp10, length 28
	0x0000:  0001 0800 0604 0001 0019 9971 d8af c0a8
	0x0010:  b2e9 0000 0000 0000 c0a8 b201
10:25:24.721460 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.178.1 tell warp10, length 28
	0x0000:  0001 0800 0604 0001 0019 9971 d8af c0a8
	0x0010:  b2e9 0000 0000 0000 c0a8 b201
10:25:25.761358 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.178.1 tell warp10, length 28
	0x0000:  0001 0800 0604 0001 0019 9971 d8af c0a8
	0x0010:  b2e9 0000 0000 0000 c0a8 b201
10:25:26.801357 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.178.1 tell warp10, length 28
	0x0000:  0001 0800 0604 0001 0019 9971 d8af c0a8
	0x0010:  b2e9 0000 0000 0000 c0a8 b201
10:25:27.841481 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.178.1 tell warp10, length 28
	0x0000:  0001 0800 0604 0001 0019 9971 d8af c0a8
	0x0010:  b2e9 0000 0000 0000 c0a8 b201
10:25:28.881354 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.178.1 tell warp10, length 28
	0x0000:  0001 0800 0604 0001 0019 9971 d8af c0a8
	0x0010:  b2e9 0000 0000 0000 c0a8 b201
10:25:29.921378 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.178.1 tell warp10, length 28
	0x0000:  0001 0800 0604 0001 0019 9971 d8af c0a8
	0x0010:  b2e9 0000 0000 0000 c0a8 b201
10:25:48.962638 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.178.1 tell warp10, length 28
	0x0000:  0001 0800 0604 0001 0019 9971 d8af c0a8
	0x0010:  b2e9 0000 0000 0000 c0a8 b201
10:25:50.011305 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.178.1 tell warp10, length 28
	0x0000:  0001 0800 0604 0001 0019 9971 d8af c0a8
	0x0010:  b2e9 0000 0000 0000 c0a8 b201
10:25:51.051309 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.178.1 tell warp10, length 28
	0x0000:  0001 0800 0604 0001 0019 9971 d8af c0a8
	0x0010:  b2e9 0000 0000 0000 c0a8 b201
10:25:52.091437 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.178.1 tell warp10, length 28
	0x0000:  0001 0800 0604 0001 0019 9971 d8af c0a8
	0x0010:  b2e9 0000 0000 0000 c0a8 b201
10:25:53.131309 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.178.1 tell warp10, length 28
	0x0000:  0001 0800 0604 0001 0019 9971 d8af c0a8
	0x0010:  b2e9 0000 0000 0000 c0a8 b201
10:25:54.171311 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.178.1 tell warp10, length 28
	0x0000:  0001 0800 0604 0001 0019 9971 d8af c0a8
	0x0010:  b2e9 0000 0000 0000 c0a8 b201
10:25:55.201502 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.178.1 tell warp10, length 28
	0x0000:  0001 0800 0604 0001 0019 9971 d8af c0a8
	0x0010:  b2e9 0000 0000 0000 c0a8 b201
10:25:56.241382 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.178.1 tell warp10, length 28
	0x0000:  0001 0800 0604 0001 0019 9971 d8af c0a8
	0x0010:  b2e9 0000 0000 0000 c0a8 b201
10:25:57.281354 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.178.1 tell warp10, length 28
	0x0000:  0001 0800 0604 0001 0019 9971 d8af c0a8
	0x0010:  b2e9 0000 0000 0000 c0a8 b201

48 packets captured
48 packets received by filter
0 packets dropped by kernel
$ 
tomsam
03.07.2020 08:55:27
segfault schrieb:

Ich würde prüfen, was passiert, wenn man "zu Fuß" eine Adresse vergibt: "ip addr add 1.2.3.4/nn dev <device>". Ansonsten mit tcpdump debuggen, was mit dem DHCP los ist.

Während meiner Tests hatte ich auch versucht, per .network Konfiguration eine feste Adresse zu vergeben. Das hatte nicht funktioniert.
Bei nächsten Fehlschlag werde ich deinen Vorschlag händisch ausprobieren.

tomsam
03.07.2020 08:50:46
schard schrieb:

Hm. Dumme Frage: Hast du das Paket linux-firmware installiert?

$ pacman -Q | grep firm
linux-firmware 20200519.8ba6fa6-1

segfault
03.07.2020 04:56:42
schard schrieb:

Der Zustand "degraded" ist ein weiteres Indiz für ein physikalisches Problem.

Degraded sagt: Der Link ist up. Es gibt eine linklocal Adresse. Es gibt keine globale Adresse. Sonst ist alles in Ordnung. Aus Gründen, die wir hier nicht kennen, wird keine Adresse per DHCP ausgereicht. Ich würde prüfen, was passiert, wenn man "zu Fuß" eine Adresse vergibt: "ip addr add 1.2.3.4/nn dev <device>". Ansonsten mit tcpdump debuggen, was mit dem DHCP los ist.

schard
02.07.2020 19:12:12

Hm. Dumme Frage: Hast du das Paket linux-firmware installiert?

tomsam
02.07.2020 16:39:19

Ich hatte schon den Anschluss an die zweite Fritzbox und auch ein anderes Kabel  (neues CAT7 Kabel, frisch ausgepackt) wie auch andere Ports an meinem Switch ausprobiert,
alles mit dem gleichen Ergebnis. Allerdings hatte ich es bisher nicht im laufenden Betrieb getauscht.

Wenn ich es im laufenden Betrieb aus dem Rechner herausziehe und dann dasselbe oder ein anderes Kabel hineinstecke (egal an welchem Port des Switches oder der FB der hängt), wird der Link konfiguriert. Reboote ich dann das ja vollständig funktionierende System, erhalte ich wieder den Zustand, dass es nicht funktioniert.

Komisch nur, dass es in den anderen Distros auf demselben System (einschließlich bsd und solaris) funktioniert,
hier der Auszug von dem aktuellen System,  mit dem 8169er Treiber

dmesg | grep enp5s0f0
[    1.373904] r8169 0000:05:00.0 enp5s0f0: renamed from eth0
[   10.045913] IPv6: ADDRCONF(NETDEV_UP): enp5s0f0: link is not ready
[   10.148115] r8169 0000:05:00.0 enp5s0f0: link down
[   10.148117] r8169 0000:05:00.0 enp5s0f0: link down
[   10.148196] IPv6: ADDRCONF(NETDEV_UP): enp5s0f0: link is not ready
[   11.659576] r8169 0000:05:00.0 enp5s0f0: link up
[   11.659583] IPv6: ADDRCONF(NETDEV_CHANGE): enp5s0f0: link becomes ready
schard
02.07.2020 15:53:57

Der Zustand "degraded" ist ein weiteres Indiz für ein physikalisches Problem.
Dass das Interface verschwindet, wenn du IPv6 deaktivierst liegt daran, dass systemd-networkd dem Interface nun auch keine Link-Local Adresse mehr zuweisen kann und es daher mangels IPvX Adresse nicht aktiviert.
Unter ip link sollte es allerdings auch dann weiterhin auftauchen.
Hast du überhaupt mal ein anderes Netzwerkkabel und eine andere Gegenstelle ausprobiert? Nur so zum Spaß?

tomsam
02.07.2020 15:43:11

Ok, ich hab nun zuerst ein System nach der (nicht vollständig richtigen) obigen Anleitung installiert, mit pacstrap ... linux r8168 (also 5.7.6).
Hat nicht funktioniert (führte sogar dazu, dass auch in den anderen OS mit einmal USB Devices nicht mehr gesehen wurden oder mit permanenten timeouts arbeiteten.
Unter Arch wurde damit auch ein "CPU #4 soft lockup stuck for 22s" protokolliert).

Also nochmal in das chroot, r8168 und linux deinstalliert, dafür linux-lts und r8168-lts installiert.

Auf Euren Wunsch nur mit systemd-networkd (kein dhcpcd, kein NetworkManager.service)

# 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: 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
    inet6 fe80::219:99ff:fe71:d8af/64 scope link 
       valid_lft forever preferred_lft forever

Das Interface hat nun den State "up"

# networkctl
IDX LINK     TYPE     OPERATIONAL SETUP      
  1 lo       loopback carrier     unmanaged  
  2 enp5s0f0 ether    degraded    configuring

Dieser "configuring" Zustand bleibt für immer so.

# systemctl status systemd-networkd
● systemd-networkd.service - Network Service
     Loaded: loaded (/usr/lib/systemd/system/systemd-networkd.service; enabled; vendor preset: enabled)
     Active: active (running) since Thu 2020-07-02 14:55:29 CEST; 1min 46s ago
TriggeredBy: ● systemd-networkd.socket
       Docs: man:systemd-networkd.service(8)
   Main PID: 411 (systemd-network)
     Status: "Processing requests..."
      Tasks: 1 (limit: 11922)
     Memory: 2.6M
     CGroup: /system.slice/systemd-networkd.service
             └─411 /usr/lib/systemd/systemd-networkd

Jul 02 14:55:29 warp10 systemd[1]: Starting Network Service...
Jul 02 14:55:29 warp10 systemd-networkd[411]: Enumeration completed
Jul 02 14:55:29 warp10 systemd[1]: Started Network Service.
Jul 02 14:55:29 warp10 systemd-networkd[411]: enp5s0f0: IPv6 successfully enabled
Jul 02 14:55:30 warp10 systemd-networkd[411]: enp5s0f0: Link UP
Jul 02 14:55:33 warp10 systemd-networkd[411]: enp5s0f0: Gained carrier
Jul 02 14:55:35 warp10 systemd-networkd[411]: enp5s0f0: Gained IPv6LL
# journalctl | grep enp5s0f0 (Nur die letzten relevanten Zeilen)
Jul 02 14:54:04 warp10 kernel: r8168 0000:05:00.0 enp5s0f0: renamed from eth0
Jul 02 14:55:29 warp10 systemd-networkd[411]: enp5s0f0: IPv6 successfully enabled
Jul 02 14:55:29 warp10 kernel: enp5s0f0: 0xffffa4ea801fd000, 00:19:99:71:d8:af, IRQ 34
Jul 02 14:55:30 warp10 systemd-networkd[411]: enp5s0f0: Link UP
Jul 02 14:55:33 warp10 kernel: r8168: enp5s0f0: link up
Jul 02 14:55:33 warp10 systemd-networkd[411]: enp5s0f0: Gained carrier
Jul 02 14:55:33 warp10 kernel: IPv6: ADDRCONF(NETDEV_CHANGE): enp5s0f0: link becomes ready
Jul 02 14:55:35 warp10 systemd-networkd[411]: enp5s0f0: Gained IPv6LL
# cd /etc/systemd/network
# cat lan8168.network 

[Match]
Name=enp5s0f0

[Network]
DHCP=yes

Zwischendurch hab ich auch einmal mit ipv6.disable=1 gebootet, was dazu geführt hat, dass das Interface gar mehr vorhanden war.
(Meine Fritzbox ist so konfiguriert, dass sie v4 und v6 können soll. I.Ü: Wie erhalte ich denn ein Interface, welches ausschließlich ipv4 spricht?)

Was habe ich hier also noch falsch gemacht?

Fußzeile des Forums

Powered by FluxBB