Hallo,

ich habe eine Installation von Buster auf Bullseye hochgezogen. Nun habe
ich ein Problem mit dem Netzwerk nach dem Booten, welches ich vorher nicht hatte.

Nach dem Booten ist die Default-Route immer auf der automatisch
ermittelten IP eingestellt anstatt auf dem "richtigen" Gateway, so dass
kein Routing möglich ist.

Also, nach dem Booten habe ich:

# ip r
default dev eth0 scope link src 169.254.178.15 metric 202
169.254.0.0/16 dev eth0 scope link src 169.254.178.15 metric 202
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.11

Offenbar drängt sich AVAHI vor und löscht die Route, die nach dem up des Netzwerkinterfaces vorhanden ist, raus und setzt seine neue.

Das eine richtige Route ursprünglich da ist sehe ich, wenn ich "ip r" in den up von /etc/network/interfaces.d/eth0 einbaue. Dann sieht es nämlich so aus:

# ip r
default via 192.168.1.1 dev eth0 onlink linkdown
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.11 linkdown

Also scheint nach dem erhalt der IP nochmal die IP 169.254.178.15 (o.ä.)
zu erhalten und dazu die Route zu konfigurieren, nachdem die
ursprüngliche gelöscht wurde.

# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
[...]
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether dc:a6:32:b1:a0:4e brd ff:ff:ff:ff:ff:ff
inet 192.168.1.11/24 brd 192.168.1.255 scope global eth0
valid_lft forever preferred_lft forever
inet 169.254.178.15/16 brd 169.254.255.255 scope global noprefixroute eth0
valid_lft forever preferred_lft forever
inet6 fe80::3c66:3ccb:32c8:b10e/64 scope link
valid_lft forever preferred_lft forever
3: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
[...]


Das Netzwerk wird per /etc/network/interfaces.d/eth0 konfiguriert, und zwar so:

allow-hotplug eth0
iface eth0 inet static
address 192.168.1.11
netmask 255.255.255.0
network 192.168.1.0
broadcast 192.168.1.255
gateway 192.168.1.1

Ich helfe mir gerade dadurch, dass ich in /etc/rc.local die folgenden
beiden Zeilen einbaue:

ip route del default
ip route add default via 192.168.1.1 metric 1 dev eth0

Aber das kann ja wohl kaum die richtige Lösung sein?

Es bringt übrigens nichts, die zeilen in up in der /etc/network/interfaces.d/eth0 zu ergänzen, weil das Löschen der Route
ja erst später passiert.

avahi möchte ich nicht abschalten, da ich es z.B. zur Erkennung des
Druckers benötige.

Die IP stört mich nicht, nur das Löschen der Default-Route.

Hat jemand eine Idee, wie ich das beheben kann?

Viele Grüße,
Spiro.

--
Spiro R. Trikaliotis
https://spiro.trikaliotis.net/

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Moin Spiro,

Am 28.08.21 um 21:18 schrieb Spiro Trikaliotis:

Offenbar drängt sich AVAHI vor und löscht die Route, die nach dem up des Netzwerkinterfaces vorhanden ist, raus und setzt seine neue.

[snip]

Das Netzwerk wird per /etc/network/interfaces.d/eth0 konfiguriert, und zwar so:

allow-hotplug eth0
iface eth0 inet static
address 192.168.1.11
netmask 255.255.255.0
network 192.168.1.0
broadcast 192.168.1.255
gateway 192.168.1.1

Ist AVAHI und die direkte NIC-Konfiguration in /etc/interfaces nicht ein konzeptioneller Widerspruch?

Grüße,

Boris

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

* On Sat, Aug 28, 2021 at 10:09:36PM +0200 Boris wrote:

Ist AVAHI und die direkte NIC-Konfiguration in /etc/interfaces nicht ein konzeptioneller Widerspruch?

Ich bin bei AVAHI nicht so bewandert, aber soweit ich weiß, macht es
mehr (z.B. auch die Erkennung von AirPrint-fähigen Druckern).

Ich will ja nur die automatische IP ausschalten, oder zumindest das
setzen der EINZIGEN Route für die automatische IP.

Nach vielem Suchen im Web und herumprobieren habe ich erkannt, dass der
DHCP Client das Problem verursacht. Ob es mit dem zweiten Interface
(wlan0) zu tun hat, da bin ich mir nicht ganz sicher. Es ändert sich
aber nichts an dem Verhalten, wenn ich es statisch, per dhcp oder
manuell konfigueriere.

Jedenfalls habe es nun für mich gelöst, indem ich in /etc/dhcpcd.conf
die Zeile "noipv4ll" (natürlich ohne Anführungszeichen) ergänzt habe.
Ich hätte auch den dhcpcd.service ausschalten können ("systemctl disable dhcpdc.service"), aber da finde ich die Gefahr zu groß, dass ich
irgendwann nicht mehr weiß, wieso ich das gemacht habe.

Dabei fällt mir auf, dass bei mir beide folgende Pakete installiert sind:

* dhcpd5
* isc-dhcp-client

Soweit ich das verstehe ist /etc/dhcpdc.conf die Config-Datei für
dhcpd5; also wird wohl das benutzt.

Das würde auch verstehe, wieso das Problem mit Bullseye neu auftritt. In
Buster hatte ich dhcpd5 nicht installiert.

Weiß jemand, wie Debian entscheidet, welchen dhcp-Client es benutzt -
gerade dann, wenn beide Pakete installiert sind, so wie hier?


Beste Grüße,
Spiro.

--
Spiro R. Trikaliotis
https://spiro.trikaliotis.net/

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am Sun, 29 Aug 2021 12:25:20 +0200
schrieb Spiro Trikaliotis <list-debian-user-german@spiro.trikaliotis.net>:

Dabei fällt mir auf, dass bei mir beide folgende Pakete installiert sind:
* dhcpd5
* isc-dhcp-client

Wenn ich mich richtig erinnere, ist dhcpd5 Client und Server,
isc-dhcp-client eben nur Client. Wenn Du keine Server-Funktion brauchst,
dann ist dhcpd5 Overkill und daher nicht nötig.

Da Dein System nach Änderung der /etc/dhcpcd.conf wie gewünscht läuft,
wird wohl der dhcpd5 als Client benutzt. Der isc-dhcp-client liegt also
nur untätig auf Deiner Platte/SSD herum.

Frage so nebenbei: Warum benutzt Du nicht systemd für Deine Netzwerk Konfiguration? Dann hättest Du alles aus einer Hand. Systemd wird eh installiert und damit ist bereits alles vorhanden, was zur Netzwerk Konfiguration benötigt wird. Die Installation weiterer Pakete wie z.B.
dhcpd5 oder isc-dhcp-client entfällt damit.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)