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 <[email protected]>:

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)