Remove route '169.254.0.0/16 dev ovs-system'

[Geert Stappers]

Hi,

Having installed package openvswitch-switch and doing `ip route` I do get

169.254.0.0/16 dev ovs-system scope link src 169.254.201.7 metric 1004


What can be done to prevent that "zeroconf"
configures interface `ovs-system`?


Groeten
Geert Stappers
--
Silence is hard to parse

[Christoph Brinkhaus]

Am Sun, Feb 19, 2023 at 05:21:47PM +0100 schrieb Geert Stappers:

Hello Geert,

> Having installed package openvswitch-switch and doing `ip route` I do get
> 169.254.0.0/16 dev ovs-system scope link src 169.254.201.7 metric 1004
>
> What can be done to prevent that "zeroconf"
> configures interface `ovs-system`?

Please have a look at https://wiki.debian.org/Avahi.
According to the section "Disabling avahi-daemon" the following
commands should work:

For permenant disablement (surviving a machine reboot):
systemctl mask avahi-daemon.service avahi-daemon.socket
systemctl disable avahi-daemon.service avahi-daemon.socket
systemctl stop avahi-daemon.service avahi-daemon.socket

On my system I have deinstalled the avahi stuff before testing the
commands. I have found the link for searching infos for the
thread "ipv6 may be has arrived".

Kind regards,
Christoph
--
Ist die Katze gesund
schmeckt sie dem Hund.

[Stefan Monnier]

>> Having installed package openvswitch-switch and doing `ip route` I do get
>> 169.254.0.0/16 dev ovs-system scope link src 169.254.201.7 metric 1004
>>
>> What can be done to prevent that "zeroconf"
>> configures interface `ovs-system`?
>
> Please have a look at https://wiki.debian.org/Avahi.
> According to the section "Disabling avahi-daemon" the following
> commands should work:
>
> For permenant disablement (surviving a machine reboot):
> systemctl mask avahi-daemon.service avahi-daemon.socket
> systemctl disable avahi-daemon.service avahi-daemon.socket
> systemctl stop avahi-daemon.service avahi-daemon.socket

But Avahi provides more functionality (e.g. mdns) than merely
configuring network interfaces, so disabling it altogether may
be undesired.

So hopefully there's a way to keep Avahi and still avoid that interface
being configured in such a dummy way.
[ I thought Avahi only did such configuration as a "last recourse", so
there's a chance that you're only seeing the effect of another problem
which prevents the interface from being configured properly and
there's just no need to worry about preventing this dummy config:
just find and fix the other problem, and then Avahi won't kick in. ]


Stefan

[Geert Stappers]

On Sun, Feb 19, 2023 at 12:21:36PM -0500, Stefan Monnier wrote:
> >> Having installed package openvswitch-switch and doing `ip route` I do get
> >> 169.254.0.0/16 dev ovs-system scope link src 169.254.201.7 metric 1004
> >>
> >> What can be done to prevent that "zeroconf"
> >> configures interface `ovs-system`?
> >
> > Please have a look at https://wiki.debian.org/Avahi.
> > According to the section "Disabling avahi-daemon" the following
> > commands should work:
> >
> > For permenant disablement (surviving a machine reboot):
> > systemctl mask avahi-daemon.service avahi-daemon.socket
> > systemctl disable avahi-daemon.service avahi-daemon.socket
> > systemctl stop avahi-daemon.service avahi-daemon.socket
>
> But Avahi provides more functionality (e.g. mdns) than merely
> configuring network interfaces,
> so disabling it altogether may be undesired.

Yes, may. And by disabling it I will find out what I miss :-)

> So hopefully there's a way to keep Avahi and still avoid that interface
> being configured in such a dummy way.
> [ I thought Avahi only did such configuration as a "last recourse", so
> there's a chance that you're only seeing the effect of another problem
> which prevents the interface from being configured properly and
> there's just no need to worry about preventing this dummy config:
> just find and fix the other problem, and then Avahi won't kick in. ]

Disabling avahi did not prevent route set on device ovs-system.

My guess is that other compoments ( network-manager, systemd-networkd )
are involved.


Regards Geert Stappers


screenshot:

$ systemctl status avahi-daemon{,.socket}
○ avahi-daemon.service
Loaded: masked (Reason: Unit avahi-daemon.service is masked.)
Active: inactive (dead)

○ avahi-daemon.socket
Loaded: masked (Reason: Unit avahi-daemon.socket is masked.)
Active: inactive (dead)
$ ip route | grep ovs-system

169.254.0.0/16 dev ovs-system scope link src 169.254.201.7 metric 1004

$ systemctl --failed
UNIT LOAD ACTIVE SUB DESCRIPTION
● systemd-networkd-wait-online.service loaded failed failed Wait for
Network to be Configured

LOAD = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of
SUB.
SUB = The low-level unit activation state, values depend on unit
type.
1 loaded unit listed.
$ systemctl status systemd-networkd-wait-online
× systemd-networkd-wait-online.service - Wait for Network to be Configured
Loaded: loaded (/lib/systemd/system/systemd-networkd-wait-online.service; enabled; preset: disabled)
Active: failed (Result: exit-code) since Sun 2023-02-19 18:48:17 CET; 10min ago
Docs: man:systemd-networkd-wait-online.service(8)
Process: 601 ExecStart=/lib/systemd/systemd-networkd-wait-online (code=exited, status=1/FAILURE)
Main PID: 601 (code=exited, status=1/FAILURE)
CPU: 32ms

feb 19 18:46:18 trancilo systemd-networkd-wait-online[601]: wlan0: Failed to update link state, ignoring: No such file or directory
feb 19 18:46:18 trancilo systemd-networkd-wait-online[601]: ovs-system: Failed to update link state, ignoring: No such file or directory
feb 19 18:46:18 trancilo systemd-networkd-wait-online[601]: ovs-system: Failed to update link state, ignoring: No such file or directory
feb 19 18:46:18 trancilo systemd-networkd-wait-online[601]: ovsbr0: Failed to update link state, ignoring: No such file or directory
feb 19 18:46:18 trancilo systemd-networkd-wait-online[601]: ovsbr0: Failed to update link state, ignoring: No such file or directory
feb 19 18:46:18 trancilo systemd-networkd-wait-online[601]: ovsbr0: Failed to update link state, ignoring: No such file or directory
feb 19 18:48:17 trancilo systemd-networkd-wait-online[601]: Timeout occurred while waiting for network connectivity.
feb 19 18:48:17 trancilo systemd[1]: systemd-networkd-wait-online.service: Main process exited, code=exited, status=1/FAILURE
feb 19 18:48:17 trancilo systemd[1]: systemd-networkd-wait-online.service: Failed with result 'exit-code'.
feb 19 18:48:17 trancilo systemd[1]: Failed to start systemd-networkd-wait-online.service - Wait for Network to be Configured.
$

[Christoph Brinkhaus]

Am Sun, Feb 19, 2023 at 07:57:56PM +0100 schrieb Geert Stappers:

Hi Geert,

> On Sun, Feb 19, 2023 at 12:21:36PM -0500, Stefan Monnier wrote:
> > >> Having installed package openvswitch-switch and doing `ip route` I do get
> > >> 169.254.0.0/16 dev ovs-system scope link src 169.254.201.7 metric 1004
> > >>
> > >> What can be done to prevent that "zeroconf"
> > >> configures interface `ovs-system`?

Deleted almost everything.

> > But Avahi provides more functionality (e.g. mdns) than merely
> > configuring network interfaces,
> > so disabling it altogether may be undesired.
>
> Yes, may. And by disabling it I will find out what I miss :-)

> Disabling avahi did not prevent route set on device ovs-system.
> My guess is that other compoments ( network-manager, systemd-networkd )
> are involved.

This is quite likely. I have disabled and deleted a low of stuff to
keep the installation as lean as possible. But I have started with
xfce to see if Debian works on my laptop and switched to awesome
later. Therefore a lot of tools are not required anymore compared to a
more complex desktop environment.

I hope that users chime in with experience on systemd and its
toolchain.

Kind regards to the lovely Netherlands,
Christoph

All the rest deleted.

[Max Nikulin]

On 19/02/2023 23:35, Christoph Brinkhaus wrote:
> Am Sun, Feb 19, 2023 at 05:21:47PM +0100 schrieb Geert Stappers:
>> Having installed package openvswitch-switch and doing `ip route` I do get
>> 169.254.0.0/16 dev ovs-system scope link src 169.254.201.7 metric 1004
>

> Please have a look at https://wiki.debian.org/Avahi.

I hope, somebody with more knowledge of related technology will correct me.

I find it confusing that the wiki page neither mentions avahi-autoipd
nor has a link explaining interaction of avahi and avahi-autoipd.

My impression is that the purpose if Avahi is discovery of services in
multicast network segment and publishing services available on the host
where avahi daemon is running to make them available for other
computers. Its scope is .local host names. IP address may be received
from centralized DHCP server.

169.254.x.y addresses are link local (IPv4LL) and usually appears when
IP address is not configured and an attempt to get it through DHCP
fails. Such addresses may be configured by avahi-autoipd, unsure
concerning systemd(-networkd?).

So to avoid 169.254.x.y addresses, it necessary to disable link local
addressed (avahi-autoipd). My guess is that Avahi as service discovery
tool may still work when usual (static or DHCP) IP address is configured.

Perhaps to get rid of 169.254.x.y addresses, it is enough to properly
configure network interface, either to ensure that DHCP server is
available or to assign a static address. After that you may forget about
existence of avahi-autoipd.

[David Wright]

I would agree with pretty well all of that. I'd just add a few points.

Having a 169.254.0.0 route, like the one posted here, shouldn't cause
any ill-effects if other routes exist, as in for example:

$ ip r
default via 192.168.1.1 dev wlp2s4
169.254.0.0/16 dev wlp2s4 scope link metric 1000
192.168.1.0/24 dev wlp2s4 proto kernel scope link src 192.168.1.10
$

That machine has no 169.254.x.y address configured either:

$ 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: enp2s2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 00:98:76:54:32:10 brd ff:ff:ff:ff:ff:ff
3: wlp2s4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 00:0e:12:34:56:78 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.10/24 brd 192.168.1.255 scope global dynamic wlp2s4
valid_lft 80846sec preferred_lft 80846sec
inet6 fe80::20e:12ff:fe34:5678/64 scope link
valid_lft forever preferred_lft forever
$

I don't recall ever seeing a 169.254.0.0 route generated in the
absence of avahi-autoipd.

I use avahi-daemon for driverless printing on systems that have
no 169.254.… addresses, routes, etc. The entire LAN is given its
IP addresses by a DHCP server in my primary router.

Cheers,
David.

[Max Nikulin]

On 20/02/2023 01:57, Geert Stappers wrote:
> feb 19 18:46:18 trancilo systemd-networkd-wait-online[601]: ovs-system: Failed to update link state, ignoring: No such file or directory
> feb 19 18:46:18 trancilo systemd-networkd-wait-online[601]: ovs-system: Failed to update link state, ignoring: No such file or directory
> feb 19 18:46:18 trancilo systemd-networkd-wait-online[601]: ovsbr0: Failed to update link state, ignoring: No such file or directory
> feb 19 18:46:18 trancilo systemd-networkd-wait-online[601]: ovsbr0: Failed to update link state, ignoring: No such file or directory
> feb 19 18:46:18 trancilo systemd-networkd-wait-online[601]: ovsbr0: Failed to update link state, ignoring: No such file or directory
> feb 19 18:48:17 trancilo systemd-networkd-wait-online[601]: Timeout occurred while waiting for network connectivity.

Which way IP address is supposed to be configured for the ovs-system
network device? My guess is that there will be no 169.254.x.y address
and route when this failure is fixed.

I am unsure if it is possible to configure avahi-autoipd (or another
zeroconf daemon actually running) to ignore specific nework interface.

The following is unrelated to the original question. I am curious if
Avahi (not autoipd) supports IPv4LL addresses on multiple network
interfaces. Likely its primary use case is a laptop connected to WiFi
(or with plugged in ethernet cable), not a router or a host having
complex network configuration for the sake of VMs.

[Jeffrey Walton]

On Sun, Feb 19, 2023 at 11:22 AM Geert Stappers <stap...@stappers.nl> wrote:
>
> Having installed package openvswitch-switch and doing `ip route` I do get
>
> 169.254.0.0/16 dev ovs-system scope link src 169.254.201.7 metric 1004

Those are called "APIPA's". Automatic Private IP Addressing (APIPA).
The host parts are randomly generated by the host when a DHCP server
cannot be contacted for a DHCP address. It is an ad-hoc networking so
hosts on the same local LAN can talk to one another when Mom and Pop
don't know how to architect a local LAN and setup the necessary
servers.

> What can be done to prevent that "zeroconf"

Ensure your DHCP server is available.

Jeff

[to...@tuxteam.de]

On Mon, Feb 20, 2023 at 12:53:25AM -0500, Jeffrey Walton wrote:
> On Sun, Feb 19, 2023 at 11:22 AM Geert Stappers <stap...@stappers.nl> wrote:
> >
> > Having installed package openvswitch-switch and doing `ip route` I do get
> >
> > 169.254.0.0/16 dev ovs-system scope link src 169.254.201.7 metric 1004
>
> Those are called "APIPA's". Automatic Private IP Addressing (APIPA).

That's what Microsoft calls them. I prefer the RFC's IP4LL.

Cheers
--
t

[Jeffrey Walton]

And Wireshark (https://wiki.wireshark.org/APIPA.md) and Cisco
(https://study-ccna.com/apipa-automatic-private-ip-addressing/).

Jeff

[to...@tuxteam.de]

On Mon, Feb 20, 2023 at 02:42:59AM -0500, Jeffrey Walton wrote:
> On Mon, Feb 20, 2023 at 2:27 AM <to...@tuxteam.de> wrote:

[...]

> > That's what Microsoft calls them. I prefer the RFC's IP4LL.
>
> And Wireshark (https://wiki.wireshark.org/APIPA.md) and Cisco
> (https://study-ccna.com/apipa-automatic-private-ip-addressing/).

So let's not give them even more mindshare for free , shall we ;-)

Cheers
--
t

[rhkr...@gmail.com]

Or let's promote communication and understanding by adtopting a possibly more
widely known acronym? (If I need to, I might use APIPA (/ IP4LL.)

Atm, I don't need to. ;-)


--
rhk

(sig revised 20221206)

If you reply: snip, snip, and snip again; leave attributions; avoid HTML;
avoid top posting; and keep it "on list". (Oxford comma (and semi-colon)
included at no charge.) If you revise the topic, change the Subject: line.
If you change the topic, start a new thread.

Writing is often meant for others to read and understand (legal documents
excepted?) -- make it easier for your reader by various means, including
liberal use of whitespace (short paragraphs, separated by whitespace / blank
lines) and minimal use of (obscure?) jargon, abbreviations, acronyms, and
references.

If someone has already responded to a question, decide whether any response
you add will be helpful or not ...

A picture is worth a thousand words. A video (or "audio"): not so much --
divide by 10 for each minute of video (or audio) or create a transcript and
edit it to 10% of the original.

A speaker who uses ahhs, ums, or such may have a real physical or mental
disability, or may be showing disrespect for his listeners by not properly
preparing in advance and thinking before speaking. (Remember Cicero who did
not have enough time to write a short missive.) (That speaker might have been
"trained" to do this by being interrupted often if he pauses.)

A radio (or TV) station which broadcasts speakers with high pitched voices (or
very low pitched / gravelly voices) (which older people might not be able to
hear properly) disrespects its listeners. Likewise if it broadcasts
extraneous or disturbing sounds (like gunfire or crying), or broadcasts
speakers using their native language (with or without an overdubbed
translation).

A person who writes a sig this long probably has issues and disrespects (and
offends) a large number of readers. ;-)
'

[Christoph Brinkhaus]

Am Mon, Feb 20, 2023 at 09:59:20AM +0700 schrieb Max Nikulin:

Hi Max,

> On 19/02/2023 23:35, Christoph Brinkhaus wrote:
> > Am Sun, Feb 19, 2023 at 05:21:47PM +0100 schrieb Geert Stappers:
> > > Having installed package openvswitch-switch and doing `ip route` I do get
> > > 169.254.0.0/16 dev ovs-system scope link src 169.254.201.7 metric 1004
> >
> > Please have a look at https://wiki.debian.org/Avahi.

[deleted 20 lines]

> Perhaps to get rid of 169.254.x.y addresses, it is enough to properly
> configure network interface, either to ensure that DHCP server is available
> or to assign a static address. After that you may forget about existence of
> avahi-autoipd.

On my system it did not help. One "issue" might be, that systemd
starts services in some sequence. But it does not wait for a service
to complete. At least in case of stuff I have observed on my system.

[Jeffrey Walton]

On Mon, Feb 20, 2023 at 9:28 AM <rhkr...@gmail.com> wrote:
>[...]

>From https://www.ietf.org/rfc/rfc1855.txt :

- If you include a signature keep it short. Rule of thumb
is no longer than 4 lines. Remember that many people pay for
connectivity by the minute, and the longer your message is,
the more they pay.

[The Wanderer]

On 2023-02-19 at 11:21, Geert Stappers wrote:

> Hi,
>
> Having installed package openvswitch-switch and doing `ip route` I do get
>
> 169.254.0.0/16 dev ovs-system scope link src 169.254.201.7 metric 1004
>
>
> What can be done to prevent that "zeroconf"
> configures interface `ovs-system`?

One angle I haven't seen suggested thus far, in the discussion of avahi
et cetera: a bit of 'apt-file search' and 'apt-cache search' seems to
suggest that ovs-system may be related to the OpenVSwitch stack (and a
bit of Googling seems to back that up). You might see whether you have
any packages installed that match "ovs", "ovn", "openvswitch", or
similar, and if so either remove them (if you don't need them) or
investigate the configuration settings they may offer.

--
The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw

[Max Nikulin]

Out of curiosity, is link-local IP address assigned during boot or later
when e.g. WiFi connection is temporary lost? How long does it take to
get response from DHCP server? Which way network is configured
(ifupdown, NetworkManager, systemd-networkd) in your case?

[Christoph Brinkhaus]

Am Tue, Feb 21, 2023 at 11:00:56PM +0700 schrieb Max Nikulin:
> On 20/02/2023 21:44, Christoph Brinkhaus wrote:
> > Am Mon, Feb 20, 2023 at 09:59:20AM +0700 schrieb Max Nikulin:

Hello Max,

> > > Perhaps to get rid of 169.254.x.y addresses, it is enough to properly
> > > configure network interface, either to ensure that DHCP server is available
> > > or to assign a static address. After that you may forget about existence of
> > > avahi-autoipd.
> >
> > On my system it did not help. One "issue" might be, that systemd
> > starts services in some sequence. But it does not wait for a service
> > to complete. At least in case of stuff I have observed on my system.
>
> Out of curiosity, is link-local IP address assigned during boot or later
> when e.g. WiFi connection is temporary lost? How long does it take to get
> response from DHCP server? Which way network is configured (ifupdown,
> NetworkManager, systemd-networkd) in your case?

The 169.254.x.y has been assigned during boot. I have not used DHCP.
The configuration has been static. The ping to the router takes about
4ms. I have no idea if it is possible to estimate a DHCP response
time. The network has been configured via systemd-networking.

In the current setup I have removed a lot of packages I did not make
use of. Additionally I have switched to systemd-networkd.

[Jeffrey Walton]

On Tue, Feb 21, 2023 at 12:45 PM Christoph Brinkhaus
<c.bri...@t-online.de> wrote:
> Am Tue, Feb 21, 2023 at 11:00:56PM +0700 schrieb Max Nikulin:
> > On 20/02/2023 21:44, Christoph Brinkhaus wrote:

> > > Am Mon, Feb 20, 2023 at 09:59:20AM +0700 schrieb Max > > > > Perhaps to get rid of 169.254.x.y addresses, it is enough to properly

> > > > configure network interface, either to ensure that DHCP server is available
> > > > or to assign a static address. After that you may forget about existence of
> > > > avahi-autoipd.
> > >
> > > On my system it did not help. One "issue" might be, that systemd
> > > starts services in some sequence. But it does not wait for a service
> > > to complete. At least in case of stuff I have observed on my system.
> >
> > Out of curiosity, is link-local IP address assigned during boot or later
> > when e.g. WiFi connection is temporary lost? How long does it take to get
> > response from DHCP server? Which way network is configured (ifupdown,
> > NetworkManager, systemd-networkd) in your case?
>
> The 169.254.x.y has been assigned during boot. I have not used DHCP.
> The configuration has been static. The ping to the router takes about
> 4ms. I have no idea if it is possible to estimate a DHCP response
> time. The network has been configured via systemd-networking.

You have to supply a static ip address or a DHCP server.

Since you supplied a static ip address, then the fact that you are
getting an APIPA is a bug. You should file a bug report with the
package (Avahi? Systemd?) that is providing the APIPA.

But backing up... I suspect there's something wrong with your static
ip address assignment. The address is already taken, the netmask is
wrong, or the gateway is wrong.

Looking back through this thread, I did not see where you showed your
static ip configuration. Maybe you should start with that. If it is
bad, then the APIPA is just a symptom of the [static ip address]
problem.

Jeff

[Christoph Brinkhaus]

Am Tue, Feb 21, 2023 at 01:06:01PM -0500 schrieb Jeffrey Walton:
> On Tue, Feb 21, 2023 at 12:45 PM Christoph Brinkhaus
> <c.bri...@t-online.de> wrote:
> > Am Tue, Feb 21, 2023 at 11:00:56PM +0700 schrieb Max Nikulin:
> > > On 20/02/2023 21:44, Christoph Brinkhaus wrote:
> > > > Am Mon, Feb 20, 2023 at 09:59:20AM +0700 schrieb Max > > > > Perhaps to get rid of 169.254.x.y addresses, it is enough to properly
> > > > > configure network interface, either to ensure that DHCP server is available
> > > > > or to assign a static address. After that you may forget about existence of
> > > > > avahi-autoipd.
> > > >
> > > > On my system it did not help. One "issue" might be, that systemd
> > > > starts services in some sequence. But it does not wait for a service
> > > > to complete. At least in case of stuff I have observed on my system.
> > >
> > > Out of curiosity, is link-local IP address assigned during boot or later
> > > when e.g. WiFi connection is temporary lost? How long does it take to get
> > > response from DHCP server? Which way network is configured (ifupdown,
> > > NetworkManager, systemd-networkd) in your case?
> >
> > The 169.254.x.y has been assigned during boot. I have not used DHCP.
> > The configuration has been static. The ping to the router takes about
> > 4ms. I have no idea if it is possible to estimate a DHCP response
> > time. The network has been configured via systemd-networking.
>
> You have to supply a static ip address or a DHCP server.

This is correct.

>
> Since you supplied a static ip address, then the fact that you are
> getting an APIPA is a bug. You should file a bug report with the
> package (Avahi? Systemd?) that is providing the APIPA.

I assume that there might be a timing issue with systemd-networking. A
comparable happened with fetchmail started by systemd. The head of the
description is

[Unit]
Description=A remote mail retrieval and forwarding utility
After=network-online.target opensmtpd.service unbound.service
Requires=opensmtpd.service unbound.service

But fetchmail starts before the dependencies have been finished.
I am not sure if systemd monitors the services to finish or if it just
starts them in a specific order.

> But backing up... I suspect there's something wrong with your static
> ip address assignment. The address is already taken, the netmask is
> wrong, or the gateway is wrong.
>
> Looking back through this thread, I did not see where you showed your
> static ip configuration. Maybe you should start with that. If it is
> bad, then the APIPA is just a symptom of the [static ip address]
> problem.

This is the systemd-networkd configuration:

[Match]
Name=w*

[Network]
DHCP=no
Address=192.168.0.62/24
Gateway=192.168.0.32
DNS=127.0.0.1

I have unbound as a DNS listening at localhost. But with
DNS=192.168.0.32 the behaviour has been similar.

I have not yet checked the address assignment using systemd-networkd.
For doing so I have to reinstall some packages.

[Reco]

Hi.

On Tue, Feb 21, 2023 at 06:44:38PM +0100, Christoph Brinkhaus wrote:
> I have no idea if it is possible to estimate a DHCP response time.

sudo nmap --script broadcast-dhcp-discover

Reco

[Jeffrey Walton]

On Tue, Feb 21, 2023 at 1:26 PM Christoph Brinkhaus
<c.bri...@t-online.de> wrote:
> [...]

> > But backing up... I suspect there's something wrong with your static
> > ip address assignment. The address is already taken, the netmask is
> > wrong, or the gateway is wrong.
> >
> > Looking back through this thread, I did not see where you showed your
> > static ip configuration. Maybe you should start with that. If it is
> > bad, then the APIPA is just a symptom of the [static ip address]
> > problem.
>
> This is the systemd-networkd configuration:
>
> [Match]
> Name=w*
>
> [Network]
> DHCP=no
> Address=192.168.0.62/24
> Gateway=192.168.0.32
> DNS=127.0.0.1
>
> I have unbound as a DNS listening at localhost. But with
> DNS=192.168.0.32 the behaviour has been similar.
>
> I have not yet checked the address assignment using systemd-networkd.
> For doing so I have to reinstall some packages.

I don't know what the Match section does. I am suspicious of it.

192.168.0.0 address block is /16, not /24.

I'm in the US, and I use Verizon for my ISP. Verizon gadgets, like set
top boxes and media centers, use 192.168.0.x addresses. I never put
anything on 192.168.0.x. I start with 192.168.1.x. And on the Verizon
network, I've never seen a 192.168.0.x gateway. Gateways also go on
192.168.1.x. So I'm a bit suspicious of the network assignments.

Jeff

[to...@tuxteam.de]

No, typically it's 24. Traditionally these were 256 /24
nets; these days we have CIDR, so you can do whatever
you like -- you only have to keep it consistent across
your network.

So /16 isn't wrong, but /24 isn't either, meaning in that
case the range 192.168.0.1..192.168.0.254, depending on
what you snip away at top or bottom, that is.

> I'm in the US, and I use Verizon for my ISP. Verizon gadgets, like set
> top boxes and media centers, use 192.168.0.x addresses. I never put
> anything on 192.168.0.x. I start with 192.168.1.x. And on the Verizon
> network, I've never seen a 192.168.0.x gateway. Gateways also go on
> 192.168.1.x. So I'm a bit suspicious of the network assignments.

No, this is perfectly fine.

Cheers
--
t

[Max Nikulin]

On 22/02/2023 01:26, Christoph Brinkhaus wrote:
>>> I have no idea if it is possible to estimate a DHCP response
>>> time.

Since static IP address is assigned, it does not matter. I expected DHCP
configuration and that delay may be noticed in `journalctl -b 0` logs.

> [Unit]
> Description=A remote mail retrieval and forwarding utility
> After=network-online.target opensmtpd.service unbound.service
> Requires=opensmtpd.service unbound.service
>
> But fetchmail starts before the dependencies have been finished.

I can not say that I fully understand interaction of After and
Requires/Wants options. I would try additional Wants=network-online.target

> [Match]
> Name=w*
>
> [Network]
> DHCP=no
> Address=192.168.0.62/24
> Gateway=192.168.0.32
> DNS=127.0.0.1

There are options like RequiredForOnline, see systemd.network(5), but
likely default value is yes. However avahi-autoipd should be started
concurrently with network configuration to assign link-local address in
the case of failure.

[Christoph Brinkhaus]

Am Wed, Feb 22, 2023 at 10:24:59PM +0700 schrieb Max Nikulin:
> On 22/02/2023 01:26, Christoph Brinkhaus wrote:
> > > > I have no idea if it is possible to estimate a DHCP response
> > > > time.
>
> Since static IP address is assigned, it does not matter. I expected DHCP
> configuration and that delay may be noticed in `journalctl -b 0` logs.
>
> > [Unit]
> > Description=A remote mail retrieval and forwarding utility
> > After=network-online.target opensmtpd.service unbound.service
> > Requires=opensmtpd.service unbound.service
> >
> > But fetchmail starts before the dependencies have been finished.
>
> I can not say that I fully understand interaction of After and
> Requires/Wants options. I would try additional Wants=network-online.target

As far as I remeber correctly I have tried the Wants option without
success.

In case of my fetchmail setup the culprit is unbound. At the startup
of unbound it takes some time to exchange keys and so on. During that
period names cannot be resolved. Now I call fetchmail after the
mailserver name can be resolved to an IP. This is done in a tiny
wrapper script. It keeps the log files clean. That workaround is fine
for me.

> > [Match]
> > Name=w*
> >
> > [Network]
> > DHCP=no
> > Address=192.168.0.62/24
> > Gateway=192.168.0.32
> > DNS=127.0.0.1
>
> There are options like RequiredForOnline, see systemd.network(5), but likely
> default value is yes. However avahi-autoipd should be started concurrently
> with network configuration to assign link-local address in the case of
> failure.

In a different thread - it was about IPv6 which has mutated
slightly - several users claimed that the avahi-autoip is useful for
their business. I am only a hobbyist, I trust the guys who do IT in
their regular job. May be it is ok as it is implemented in Debian.

[David Wright]

Might you try systemd-networkd-wait-online.service, whose name
implies that it waits for up to two minutes (configurable default).

> > However avahi-autoipd should be started concurrently
> > with network configuration to assign link-local address in the case of
> > failure.

> In a different thread - it was about IPv6 which has mutated
> slightly - several users claimed that the avahi-autoip is useful for
> their business. I am only a hobbyist, I trust the guys who do IT in
> their regular job. May be it is ok as it is implemented in Debian.

I agree with that. I think the people that report problems on the list
are, with possible exceptions, trying to get their networks into
better shape.

Perhaps one problem is that getting a 169.254.x.y address might be
useful if you're expecting to join an ad hoc network, but if you're
not (like, I suspect, many of us here), it only complicates matters.
For the latter, better surely to get no address, notice the fact,
and fix the networking, rather than to have to do all that /and/
get rid of the 169.254.x.y address.

Cheers,
David.

[David Wright]

On Tue 21 Feb 2023 at 13:48:58 (-0500), Jeffrey Walton wrote:
> On Tue, Feb 21, 2023 at 1:26 PM Christoph Brinkhaus
> <c.bri...@t-online.de> wrote:
> > [...]
> > > But backing up... I suspect there's something wrong with your static
> > > ip address assignment. The address is already taken, the netmask is
> > > wrong, or the gateway is wrong.
> > >
> > > Looking back through this thread, I did not see where you showed your
> > > static ip configuration. Maybe you should start with that. If it is
> > > bad, then the APIPA is just a symptom of the [static ip address]
> > > problem.
> >
> > This is the systemd-networkd configuration:
> >
> > [Match]
> > Name=w*
> >
> > [Network]
> > DHCP=no
> > Address=192.168.0.62/24
> > Gateway=192.168.0.32
> > DNS=127.0.0.1
> >
> > I have unbound as a DNS listening at localhost. But with
> > DNS=192.168.0.32 the behaviour has been similar.
> >
> > I have not yet checked the address assignment using systemd-networkd.
> > For doing so I have to reinstall some packages.
>
> I don't know what the Match section does. I am suspicious of it.

Oh, Match is great. For a typical, simple PC or laptop, you no longer
have to worry about whether your wifi is called wlan0 (kernel, and
iwd), wlo0, wlp365s7 (onboard/slot/path), or wlxf1dd1efadd1e (USB),
it'll get matched nonetheless. Ditto for e* and ethernet.

> 192.168.0.0 address block is /16, not /24.
>
> I'm in the US, and I use Verizon for my ISP. Verizon gadgets, like set
> top boxes and media centers, use 192.168.0.x addresses. I never put
> anything on 192.168.0.x. I start with 192.168.1.x. And on the Verizon
> network, I've never seen a 192.168.0.x gateway. Gateways also go on
> 192.168.1.x. So I'm a bit suspicious of the network assignments.

I don't understand this. If you're actually running two subnets with
255.255.255.0 netmasks, and they intercommunicate with each other
(your computers on subnet 1, and Verizon ISP on subnet 0), then you
must have a gateway on each subnet for them to communicate through.

But backing up… the systemd-networkd configuration above is that of
Christoph, who wrote that their system had been (a) switched to
systemd-networkd from systemd-networking, and (b) purged of avahi
packages to eliminate 169.254.x.y addresses. So I'm not sure what
there is to fix here.

But (a) raises the question of what systemd was running /before/,
which was presumably what was giving rise to 169.254.x.y addresses.

And, while I can add an innocuous 169.254.0.0 route to a system
merely by installing ifupdown and avahi-autoipd, that route looks
like the second line here:

default via 192.168.1.1 dev enp2s2 onlink
169.254.0.0/16 dev enp2s2 scope link metric 1000
192.168.1.0/24 dev enp2s2 proto kernel scope link src 192.168.1.10

and not like the OP's (ie Geert's):

169.254.0.0/16 dev ovs-system scope link src 169.254.201.7 metric 1004

(which has been grepped out of its context).

Cheers,
David.

[Jeffrey Walton]

Thanks David.

Maybe the 'w' is not matching anything.

I thought eth0 and wlan0 went the way of the dinosaurs. I thought with
Consistent Network Device Names and biosdevname, the name will begin
with a 'p' or 'em', not a 'w', and based on the slot number. Also see
https://linux.dell.com/files/whitepapers/consistent_network_device_naming_in_linux.pdf.

Jeff

[Greg Wooledge]

On Wed, Feb 22, 2023 at 02:04:58PM -0500, Jeffrey Walton wrote:

> Maybe the 'w' is not matching anything.
>
> I thought eth0 and wlan0 went the way of the dinosaurs. I thought with
> Consistent Network Device Names and biosdevname, the name will begin
> with a 'p' or 'em', not a 'w', and based on the slot number.

"Predictable" interface names always begin with "e" for ethernet, or "w"
for wireless. "Match w*" should match every wireless interface on the
system.

[Darac Marjal]

It would also match "wan0" if you had a network interface for your Wide
Area Network. You might find this to be a bit more direct (that is, it
mostly has the same effect, but matches directly what you want, rather
than indirectly what you meant)

  [Match]
  Type=wlan

[Max Nikulin]

On 22/02/2023 23:45, Christoph Brinkhaus wrote:
> Am Wed, Feb 22, 2023 at 10:24:59PM +0700 schrieb Max Nikulin:
>> On 22/02/2023 01:26, Christoph Brinkhaus wrote:
>>> [Unit]
>>> Description=A remote mail retrieval and forwarding utility
>>> After=network-online.target opensmtpd.service unbound.service
>>> Requires=opensmtpd.service unbound.service

...

> In case of my fetchmail setup the culprit is unbound. At the startup
> of unbound it takes some time to exchange keys and so on.

I have no experience with unbound and I am not sure at which moment it
notifies systemd that the service is ready. However I have found a
recent bug
https://github.com/NLnetLabs/unbound/issues/773
"When used with systemd-networkd, unbound does not start until
systemd-networkd-wait-online.service times out"

Perhaps the package in Debian has an older version of the
unbound.service file and so is not affected.

...

>> However avahi-autoipd should be started concurrently
>> with network configuration to assign link-local address in the case of
>> failure.
>
> In a different thread - it was about IPv6 which has mutated
> slightly - several users claimed that the avahi-autoip is useful for
> their business.

I mean IPv4 link local addresses 169.254.x.y. My impression is that
avahi-autoipd was created for the cases when there is no point to setup
centralized DHCP server. On the other hand I agree that a router (and so
DHCP out of the box) is more wide spread configuration than connecting a
couple of devices directly or through a switch.

[Christoph Brinkhaus]

Am Fri, Feb 24, 2023 at 10:09:34PM +0700 schrieb Max Nikulin:
> On 22/02/2023 23:45, Christoph Brinkhaus wrote:
> > Am Wed, Feb 22, 2023 at 10:24:59PM +0700 schrieb Max Nikulin:
> > > On 22/02/2023 01:26, Christoph Brinkhaus wrote:
> > > > [Unit]
> > > > Description=A remote mail retrieval and forwarding utility
> > > > After=network-online.target opensmtpd.service unbound.service
> > > > Requires=opensmtpd.service unbound.service
> ...
> > In case of my fetchmail setup the culprit is unbound. At the startup
> > of unbound it takes some time to exchange keys and so on.
>
> I have no experience with unbound and I am not sure at which moment it
> notifies systemd that the service is ready. However I have found a recent
> bug
> https://github.com/NLnetLabs/unbound/issues/773
> "When used with systemd-networkd, unbound does not start until
> systemd-networkd-wait-online.service times out"
>
> Perhaps the package in Debian has an older version of the unbound.service
> file and so is not affected.
>

Hi Max,

I have observed lines below in journald:

Feb 22 15:41:44 lenovo systemd[1]: Reached target Network is Online.
Feb 22 15:41:44 lenovo systemd[1]: Failed to start Wait for Network to be Configured.
Feb 22 15:41:44 lenovo systemd[1]: systemd-networkd-wait-online.service: Failed with result 'exit-code'.
Feb 22 15:41:44 lenovo systemd[1]: systemd-networkd-wait-online.service: Main process exited, code=exited, status=1/FAILURE
Feb 22 15:41:44 lenovo systemd-networkd-wait-online[362]: Event loop failed: Connection timed out
Feb 22 15:41:25 lenovo systemd[1]: anacron.service: Succeeded.
Feb 22 15:41:25 lenovo anacron[3261]: Normal exit (0 jobs run)
Feb 22 15:41:25 lenovo anacron[3261]: Anacron 2.3 started on 2023-02-22
Feb 22 15:41:25 lenovo systemd[1]: Started Run anacron jobs.

This looks related, thank you very much!
I will have a look at the link.

> ...
> > > However avahi-autoipd should be started concurrently
> > > with network configuration to assign link-local address in the case of
> > > failure.
> >
> > In a different thread - it was about IPv6 which has mutated
> > slightly - several users claimed that the avahi-autoip is useful for
> > their business.
>
> I mean IPv4 link local addresses 169.254.x.y. My impression is that
> avahi-autoipd was created for the cases when there is no point to setup
> centralized DHCP server. On the other hand I agree that a router (and so
> DHCP out of the box) is more wide spread configuration than connecting a
> couple of devices directly or through a switch.

I think so, too.

[David Wright]

And does anything start up after wait-online expires? (I've never used it.)

> I will have a look at the link.
> > ...
> > > > However avahi-autoipd should be started concurrently
> > > > with network configuration to assign link-local address in the case of
> > > > failure.
> > >
> > > In a different thread - it was about IPv6 which has mutated
> > > slightly - several users claimed that the avahi-autoip is useful for
> > > their business.
> >
> > I mean IPv4 link local addresses 169.254.x.y. My impression is that
> > avahi-autoipd was created for the cases when there is no point to setup
> > centralized DHCP server. On the other hand I agree that a router (and so
> > DHCP out of the box) is more wide spread configuration than connecting a
> > couple of devices directly or through a switch.
>
> I think so, too.

Well, you typically only get a level of Recommended for avahi-autoipd
when you install on a laptop, which is a reasonable choice for the
debian-installer to make. Otherwise it's either a Suggests, or the
sysadmin has to choose it off their own bat. But I guess their are
a lot of laptops, now they are affordable, that aren't really used
in the way they were intended, but just as more flexible desktops.

Cheers,
David.

[Geert Stappers]

On Fri, Feb 24, 2023 at 01:25:55PM -0600, David Wright wrote:
> On Fri 24 Feb 2023 at 19:41:26 (+0100), Christoph Brinkhaus wrote:
> > Am Fri, Feb 24, 2023 at 10:09:34PM +0700 schrieb Max Nikulin:

....

> > >
> > > I mean IPv4 link local addresses 169.254.x.y. My impression is that
> > > avahi-autoipd was created for the cases when there is no point to setup
> > > centralized DHCP server. On the other hand I agree that a router (and so
> > > DHCP out of the box) is more wide spread configuration than connecting a
> > > couple of devices directly or through a switch.
> >
> > I think so, too.
>
> Well, you typically only get a level of Recommended for avahi-autoipd
> when you install on a laptop, which is a reasonable choice for the
> debian-installer to make. Otherwise it's either a Suggests, or the
> sysadmin has to choose it off their own bat. But I guess their are
> a lot of laptops, now they are affordable, that aren't really used
> in the way they were intended, but just as more flexible desktops.

Having `apt purge avahi-autoipd` still gets me "auto IPv4 address"

Ideas how to avoid it are welcome.


<screenshot>
$ dpkg -l '*avahi*ip*'
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
+++-==============-============-============-=================================
un avahi-autoipd <none> <none> (no description available)
$ uptime
22:45:25 up 1 min, 1 user, load average: 0.02, 0.04, 0.05
$ ip route | grep system

169.254.0.0/16 dev ovs-system scope link src 169.254.201.7 metric 1004

$
</screenshot>


Groeten
Geert Stappers
--
Silence is hard to parse

[Max Nikulin]

On 25/02/2023 04:43, Geert Stappers wrote:
> Having `apt purge avahi-autoipd` still gets me "auto IPv4 address"
>
> Ideas how to avoid it are welcome.

Have you checked "journalctl --boot" for logs which component assigns
169.254.x.y address and for various errors related to network?

I am not familiar with openvswitch (or another package that really
created ovs-system and ovsbr0), so I have no idea how they may be
configured (systemd-networkd, NetworkManager, netplan, ifupdown) in your
case and how to configure them properly. Perhaps it better to ask their
community how to avoid failure of systemd-networkd-wait-online and
assigning of IPv4LL address.

I have realized that your problem may be more general than just
ovs-system, I do not like the following log line and which file is not
found is not clear for me:
> feb 19 18:46:18 trancilo systemd-networkd-wait-online[601]: wlan0: Failed to update link state, ignoring: No such file or directory

[David Wright]

I see you rebooted, and you get the same address. It's ambiguous as
to why: it could have been stored, which makes things more efficient
when a number of machines start up and don't have to renegotiate;
or it could have been recomputed anew by a pseudorandom process on a
host-dependent seed, which would generate the same sequence of tries
each time you boot.

A couple of odd points:

. I notice that certain files in the openvswitch packages seem to
generate 169.254.… addresses,
. There's a long discussion about getting the network to come up
in the right order, which seems to suggest that there's a fair
chance of getting it wrong.

> Silence is hard to parse

It's ironic that this is your signature. AFAICT we've been told a
total of:

. you installed package openvswitch-switch,
. 169.254.0.0/16 dev ovs-system scope link src 169.254.201.7 metric 1004
is in the routing table in the company of ?,
. configured with network-manager? and systemd-networkd?
(not sure how they interact),
. systemd-networkd-wait-online waits for any? interface to be up,
but the tests are flawed, and the order seems to be of no concern
notwithstanding the long discussion mentioned.

Cheers,
David.

[Jeffrey Walton]

On Fri, Feb 24, 2023 at 9:51 PM David Wright <deb...@lionunicorn.co.uk> wrote:
>
> On Fri 24 Feb 2023 at 22:43:49 (+0100), Geert Stappers wrote:

> > [...]

> I see you rebooted, and you get the same address. It's ambiguous as
> to why: it could have been stored, which makes things more efficient
> when a number of machines start up and don't have to renegotiate;
> or it could have been recomputed anew by a pseudorandom process on a
> host-dependent seed, which would generate the same sequence of tries
> each time you boot.

APIPA's use a deterministic process to generate the random host
portion of the address. They will generate the same host portion of
the address across reboots and restarts without the need to save
state.

Jeff

[Christoph Brinkhaus]

Am Fri, Feb 24, 2023 at 07:41:26PM +0100 schrieb Christoph Brinkhaus:

I reply to myself thanking Max.

> Am Fri, Feb 24, 2023 at 10:09:34PM +0700 schrieb Max Nikulin:
> > On 22/02/2023 23:45, Christoph Brinkhaus wrote:
> > > Am Wed, Feb 22, 2023 at 10:24:59PM +0700 schrieb Max Nikulin:
> > > > On 22/02/2023 01:26, Christoph Brinkhaus wrote:

[snip]

> > I have no experience with unbound and I am not sure at which moment it
> > notifies systemd that the service is ready. However I have found a recent
> > bug
> > https://github.com/NLnetLabs/unbound/issues/773
> > "When used with systemd-networkd, unbound does not start until
> > systemd-networkd-wait-online.service times out"
> >
> > Perhaps the package in Debian has an older version of the unbound.service
> > file and so is not affected.
> >
> Hi Max,
>
> I have observed lines below in journald:
>
> Feb 22 15:41:44 lenovo systemd[1]: Reached target Network is Online.
> Feb 22 15:41:44 lenovo systemd[1]: Failed to start Wait for Network to be Configured.
> Feb 22 15:41:44 lenovo systemd[1]: systemd-networkd-wait-online.service: Failed with result 'exit-code'.
> Feb 22 15:41:44 lenovo systemd[1]: systemd-networkd-wait-online.service: Main process exited, code=exited, status=1/FAILURE
> Feb 22 15:41:44 lenovo systemd-networkd-wait-online[362]: Event loop failed: Connection timed out
> Feb 22 15:41:25 lenovo systemd[1]: anacron.service: Succeeded.
> Feb 22 15:41:25 lenovo anacron[3261]: Normal exit (0 jobs run)
> Feb 22 15:41:25 lenovo anacron[3261]: Anacron 2.3 started on 2023-02-22
> Feb 22 15:41:25 lenovo systemd[1]: Started Run anacron jobs.
>
> This looks related, thank you very much!
> I will have a look at the link.

Dear Max, the method descriped in the link above helped to fix the
issue. Now there are no messages reported by journald as above.

Thank you very much for the kind help!

[snip]

[Geert Stappers]

On Sat, Feb 25, 2023 at 09:42:49AM +0700, Max Nikulin wrote:
> On 25/02/2023 04:43, Geert Stappers wrote:
> > Having `apt purge avahi-autoipd` still gets me "auto IPv4 address"
> >
> > Ideas how to avoid it are welcome.
>
> Have you checked "journalctl --boot" for logs which component assigns
> 169.254.x.y address and for various errors related to network?

Just did (checking `journalctl --boot`) and found lines like


Feb 24 22:24:13 trancilo systemd-networkd[455]: ovs-system: Unmanaging interface.
Feb 24 22:24:13 trancilo systemd-networkd[455]: ovs-system: State changed: initialized -> unmanaged
Feb 24 22:24:14 trancilo dhcpcd[1175]: ovs-system: waiting for carrier
Feb 24 22:24:14 trancilo systemd-networkd[455]: ovs-system: IPv6 link-local address generation mode is changed: eui64 -> none
Feb 24 22:24:14 trancilo systemd-networkd[455]: ovs-system: Flags change: +UP +LOWER_UP +RUNNING
Feb 24 22:24:14 trancilo systemd-networkd[455]: ovs-system: Link UP
Feb 24 22:24:14 trancilo systemd-networkd[455]: ovs-system: Gained carrier
...
Feb 24 22:24:14 trancilo NetworkManager[1188]: <info> [1677273854.7167] manager: (ovs-system): new Generic device (/org/freedesktop/NetworkManager/Devices/3)
Feb 24 22:24:15 trancilo dhcpcd[1175]: ovs-system: carrier acquired
Feb 24 22:24:15 trancilo dhcpcd[1175]: ovs-system: IAID cb:93:09:25
Feb 24 22:24:15 trancilo dhcpcd[1175]: ovs-system: adding address fe80::56b2:83e1:5ceb:9d50
...
Feb 24 22:24:16 trancilo dhcpcd[1175]: ovs-system: soliciting a DHCP lease
...
Feb 24 22:24:21 trancilo dhcpcd[1175]: ovs-system: probing for an IPv4LL address
Feb 24 22:24:26 trancilo dhcpcd[1175]: ovs-system: using IPv4LL address 169.254.201.7
Feb 24 22:24:26 trancilo dhcpcd[1175]: ovs-system: adding route to 169.254.0.0/16
Feb 24 22:24:26 trancilo systemd-networkd[455]: ovs-system: Received new foreign address (configured): 169.254.201.7/16 (valid forever, preferred forever), flags: permanent,no-prefixroute, scope: global
Feb 24 22:24:26 trancilo dhcpcd[1175]: ovs-system: adding default route
Feb 24 22:24:26 trancilo systemd-networkd[455]: ovs-system: link_check_ready(): link is in unmanaged state.
Feb 24 22:24:26 trancilo systemd-networkd[455]: ovs-system: Received new foreign route (configured): dst: 169.254.201.7/32, src: n/a, gw: n/a, prefsrc: 169.254.201.7, scope: host, table: local(255), proto: kernel, type: local, nexthop: 0, priority: 0, flags: n/a
Feb 24 22:24:26 trancilo systemd-networkd[455]: ovs-system: Received new foreign route (configured): dst: 169.254.255.255/32, src: n/a, gw: n/a, prefsrc: 169.254.201.7, scope: link, table: local(255), proto: kernel, type: broadcast, nexthop: 0, priority: 0, flags: n/a

> I am not familiar with openvswitch (or another package that really created
> ovs-system and ovsbr0), so I have no idea how they may be configured
> (systemd-networkd, NetworkManager, netplan, ifupdown) in your case and how
> to configure them properly. Perhaps it better to ask their community how to
> avoid failure of systemd-networkd-wait-online and assigning of IPv4LL
> address.

AIUI is systemd-networkd the main player, dhcpcd some helper
and NetworkManager for contact with user.

> I have realized that your problem may be more general than just ovs-system,
> I do not like the following log line and which file is not found is not
> clear for me:
> > feb 19 18:46:18 trancilo systemd-networkd-wait-online[601]: wlan0: Failed to update link state, ignoring: No such file or directory
>

Acknowledge on the "be aware of a problem with wlan0"

[Reco]

Hi.

On Sun, Feb 26, 2023 at 12:18:52PM +0100, Geert Stappers wrote:
> Feb 24 22:24:15 trancilo dhcpcd[1175]: ovs-system: carrier acquired
> Feb 24 22:24:15 trancilo dhcpcd[1175]: ovs-system: IAID cb:93:09:25
> Feb 24 22:24:15 trancilo dhcpcd[1175]: ovs-system: adding address fe80::56b2:83e1:5ceb:9d50
> ...
> Feb 24 22:24:16 trancilo dhcpcd[1175]: ovs-system: soliciting a DHCP lease
> ...
> Feb 24 22:24:21 trancilo dhcpcd[1175]: ovs-system: probing for an IPv4LL address
> Feb 24 22:24:26 trancilo dhcpcd[1175]: ovs-system: using IPv4LL address 169.254.201.7
> Feb 24 22:24:26 trancilo dhcpcd[1175]: ovs-system: adding route to 169.254.0.0/16

Let's try a straightforward approach for starters:

echo denyinterfaces ovs-system >> /etc/dhcpcd.conf

Reco

[Geert Stappers]

Hi.

Yes, now no more route 169.254.0.0/16 for device ovs-system.

And for the record:
* Package avahi-autoipd left removed
* Service avahi-daemon left disabled
* Socket avahi-daemon left disabled


> Reco

Thanks

[Reco]

Hi.

These have nothing to do with your problem.
dhcpcd is the source of your problem, in a way.

dhcpcd can run as a systemwide daemon, which tries to obtain DHCP lease
on any network interface barring "lo".
In stock configuration, dhcpcd will add IPv4LL (169.254/16) IP on a
interface if it fails to obtain a lease after 60 second timeout (IIRC).
And obviously you have no DHCP server on "ovs-system" :)
Debian's packaging of dhcpcd should prevent the daemon to obtain DHCP
lease on any interface that's listed in /etc/network/interfaces, but:

1) OVS bridge should not be listed there, it's dynamic by nature.
2) You're using Network Manager, so it's totally possible that you have
an empty /etc/network/interfaces, or no such file at all.


Long story short, consider running "systemctl mask dhcpcd" unless you
need dhcpcd to work in a way described above.


Another possible workaround is to add "noipv4ll" to dhcpcd.conf, but
this could break something else in your setup.

Reco

[Max Nikulin]

On 26/02/2023 18:18, Geert Stappers wrote:
> AIUI is systemd-networkd the main player, dhcpcd some helper
> and NetworkManager for contact with user.

First of all, I would not touch dhcpcd.conf for a while.

Is it assumed that ovs-system should get its IP address from DHCP?

If I understand it correctly, systemd-networkd may send DHCP request
itself, it does not need dhcpcd helper. NetworkManager is not only UI,
it may manage interfaces. I would not be surprised if more than one tool
tries to manage ovs-system.

Perhaps some of the following command may shed some light on what really
happens:

systemctl --failed
networkctl list
networkctl status ovs-system

Last command should show Network File name if the interface is really
managed by systemd-networkd. Please, post its content

nmcli general status
nmcli device
nmcli -f CONNECTIONS device show ovs-system

ifquery --list

and check if /etc/network/interfaces and /etc/network/interfaces.d for
ovs-system entries

See also
https://wiki.debian.org/NetworkConfiguration

[Max Nikulin]

On 25/02/2023 19:49, Christoph Brinkhaus wrote:
> Now there are no messages reported by journald as above.

I am curious if fixing unbound and so network-online.target helped to
avoid 169.254.x.y address in your case. Can fetchmail work without a
kludge you added to achieve some delay? My expectation is that
unbound.service may be dropped from Requires= and After= in
fetchmail.service, but both fields should have network-online.target.

I forgot that debugging of such issues should be started with "systemctl
--failed".

[Christoph Brinkhaus]

Am Sun, Feb 26, 2023 at 10:33:19PM +0700 schrieb Max Nikulin:
> On 25/02/2023 19:49, Christoph Brinkhaus wrote:
> > Now there are no messages reported by journald as above.
>
> I am curious if fixing unbound and so network-online.target helped to avoid
> 169.254.x.y address in your case.

I am not sure because I have disabled/deinstalled stuff which
triggered the assignment of the 149.254.x.y address.

> Can fetchmail work without a kludge you
> added to achieve some delay? My expectation is that unbound.service may be
> dropped from Requires= and After= in fetchmail.service, but both fields
> should have network-online.target.

You are right, there is no need anymore to check if the mail server
can be resolved before starting fetchmail. Nevertheless I still have
the unbound.service and the opensmtpd.service in the Requires= and
After= sections. The reason is that incoming mails are routed via
opensmtpd because fetchmail runs as an unprivileged user. Additionally
the setup is indemendent of the mail server. Then the mails are sorted
by maildrop. As far as I remember forwarding the mails from an
unprivileged fetchmail to maildrop running as my user did not work.
Now incoming mails appear in /var/log/mail.log, too which is also
nice.

> I forgot that debugging of such issues should be started with "systemctl
> --failed".

I have still a lot to learn.

[David Wright]

On Sun 26 Feb 2023 at 22:11:30 (+0700), Max Nikulin wrote:
> On 26/02/2023 18:18, Geert Stappers wrote:
> > AIUI is systemd-networkd the main player, dhcpcd some helper
> > and NetworkManager for contact with user.
>
> First of all, I would not touch dhcpcd.conf for a while.
>
> Is it assumed that ovs-system should get its IP address from DHCP?
>
> If I understand it correctly, systemd-networkd may send DHCP request
> itself, it does not need dhcpcd helper.

Yes, if you configure it to, eg:

# /etc/systemd/network/80-wifi.network for systemd-networkd last edited 2022-09-30
[Match]
Name=wl*
[Network]
DHCP=ipv4
IgnoreCarrierLoss=true
[DHCPv4]
RouteMetric=20
#

which gave this morning (daemon.log):

avahi-daemon[359]: Joining mDNS multicast group on interface wlp2s4.IPv4 with address 192.168.1.10.
systemd-networkd[216]: wlp2s4: Gained carrier
avahi-daemon[359]: New relevant interface wlp2s4.IPv4 for mDNS.
avahi-daemon[359]: Registering new address record for 192.168.1.10 on wlp2s4.IPv4.
systemd-networkd[216]: wlp2s4: DHCPv4 address 192.168.1.10/24 via 192.168.1.1
systemd[1]: Started Getty on tty1.
systemd[1]: Reached target Login Prompts.

(man 5 systemd.network) and:

$ ip r
default via 192.168.1.1 dev wlp2s4 proto dhcp src 192.168.1.10 metric 20
192.168.1.0/24 dev wlp2s4 proto kernel scope link src 192.168.1.10
192.168.1.1 dev wlp2s4 proto dhcp scope link src 192.168.1.10 metric 20
$

> NetworkManager is not only UI,
> it may manage interfaces. I would not be surprised if more than one
> tool tries to manage ovs-system.
>
> Perhaps some of the following command may shed some light on what
> really happens:
>
> systemctl --failed
> networkctl list
> networkctl status ovs-system

This long thread seems to be turning into a game of 20 Questions.
It would be nice to see some of the OP's configuration, rather
than just a few log extracts and a "How do I get rid of …".

As it is, the OP has said "no more route 169.254.0.0/16 for device
ovs-system", so perhaps all that's left is to leave that as solved,
and tiptoe over to the alternate OP (CB) and see if they decide to
restore the removed and disabled packages (XFCE and avahi-daemon)
to check whether their 169.254.… addresses return.

> Last command should show Network File name if the interface is really
> managed by systemd-networkd. Please, post its content
>
> nmcli general status
> nmcli device
> nmcli -f CONNECTIONS device show ovs-system
>
> ifquery --list
>
> and check if /etc/network/interfaces and /etc/network/interfaces.d for
> ovs-system entries
>
> See also
> https://wiki.debian.org/NetworkConfiguration
>

Cheers,
David.

[Christoph Brinkhaus]

Am Sun, Feb 26, 2023 at 10:33:19PM +0700 schrieb Max Nikulin:

I have tried that and found the next issue.
systemd-networkd-wait-online runs into a time out after the default
timeout of 2 minutes.

# systemctl status systemd-networkd-wait-online
● systemd-networkd-wait-online.service - Wait for Network to be Configured
Loaded: loaded (/lib/systemd/system/systemd-networkd-wait-online.service; enabled; vendor preset: disabled)
Active: failed (Result: exit-code) since Sun 2023-02-26 17:10:28 CET; 1h 47min ago
Docs: man:systemd-networkd-wait-online.service(8)
Process: 472 ExecStart=/lib/systemd/systemd-networkd-wait-online (code=exited, status=1/FAILURE)
Main PID: 472 (code=exited, status=1/FAILURE)
CPU: 25ms

Feb 26 17:08:28 lenovo systemd[1]: Starting Wait for Network to be Configured...
Feb 26 17:10:28 lenovo systemd-networkd-wait-online[472]: Event loop failed: Connection timed out
Feb 26 17:10:28 lenovo systemd[1]: systemd-networkd-wait-online.service: Main process exited, code=exited, status=1/FAILURE
Feb 26 17:10:28 lenovo systemd[1]: systemd-networkd-wait-online.service: Failed with result 'exit-code'.
Feb 26 17:10:28 lenovo systemd[1]: Failed to start Wait for Network to be Configured.

Strange, I will have a look. But I think further discussion would exceed the topic
of the thread. I will have to read a lot of man pages the next days.
You have helped my already a lot :-), thanks for that kind support!

[David Wright]

A couple of pages I turned up were:

https://systemd.io/NETWORK_ONLINE/
https://github.com/NLnetLabs/unbound/issues/773

Without any experience of running unbound, the second was
heavy going and I couldn't really understand much of it.

Cheers,
David.

[Geert Stappers]

Hi.

On Sun, Feb 26, 2023 at 05:25:09PM +0300, Reco wrote:
> On Sun, Feb 26, 2023 at 03:14:22PM +0100, Geert Stappers wrote:
> > On Sun, Feb 26, 2023 at 04:01:06PM +0300, Reco wrote:
> > > On Sun, Feb 26, 2023 at 12:18:52PM +0100, Geert Stappers wrote:

} } } } } Have you tried `journalctl --boot`?

> > > > Feb 24 22:24:21 trancilo dhcpcd[1175]: ovs-system: probing for an IPv4LL address
> > > > Feb 24 22:24:26 trancilo dhcpcd[1175]: ovs-system: using IPv4LL address 169.254.201.7
> > > > Feb 24 22:24:26 trancilo dhcpcd[1175]: ovs-system: adding route to 169.254.0.0/16
> > >
> > > Let's try a straightforward approach for starters:
> > >
> > > echo denyinterfaces ovs-system >> /etc/dhcpcd.conf
> >
> >
> > Yes, now no more route 169.254.0.0/16 for device ovs-system.
> >
> > And for the record:
> > * Package avahi-autoipd left removed
> > * Service avahi-daemon left disabled
> > * Socket avahi-daemon left disabled

As done / adviced earlier in this thread.

> These have nothing to do with your problem.
> dhcpcd is the source of your problem, in a way.

OK, so I checked. And yes, it is true that adding
'denyinterfaces ovs-system ovsbr0' to /etc/dhcpcd.conf
does prevent "route 169.254.0.0/16 dev ovs-system"
and "route 169.254.0.0/16 dev ovsbr0"

> dhcpcd can run as a systemwide daemon, which tries to obtain DHCP lease
> on any network interface barring "lo".
> In stock configuration, dhcpcd will add IPv4LL (169.254/16) IP on a
> interface if it fails to obtain a lease after 60 second timeout (IIRC).
> And obviously you have no DHCP server on "ovs-system" :)
> Debian's packaging of dhcpcd should prevent the daemon to obtain DHCP
> lease on any interface that's listed in /etc/network/interfaces, but:
>
> 1) OVS bridge should not be listed there, it's dynamic by nature.
> 2) You're using Network Manager, so it's totally possible that you have
> an empty /etc/network/interfaces, or no such file at all.
>

I have no /etc/network/interfaces.d/ovs-system,
my /etc/network/interfaces.d/ovsbr0 has
auto ovsbr0
iface ovsbr0 inet static
address 172.24.6.2/24

And there was "route 169.254.0.0/16 dev ovsbr0".

I only reported, until now, only about dev ovs-system.


Thing I trying to say:
Having device in /etc/network/interfaces did
not prevent the unwanted route.

(Meanwhile solved with denyinterface in /etc/dhcpcd.conf)

> Long story short, consider running "systemctl mask dhcpcd" unless you
> need dhcpcd to work in a way described above.

The laptop does need to have DHCP client.

> Another possible workaround is to add "noipv4ll" to dhcpcd.conf,

Not tried.

> but this could break something else in your setup.

Yes "could break", but I don't know what ...
(I'm mostly on computer networks that do have
DHCP and DNServers (I can't tell first hand
the benefits of IPv4LL addresses))


> Reco

[Reco]

Hi.

On Mon, Feb 27, 2023 at 10:53:24PM +0100, Geert Stappers wrote:
> (Meanwhile solved with denyinterface in /etc/dhcpcd.conf)
>
>
> > Long story short, consider running "systemctl mask dhcpcd" unless you
> > need dhcpcd to work in a way described above.
>
> The laptop does need to have DHCP client.

I see. Adding appropriate amount of "allowinterfaces" and
"denyinterfaces" stanzas into dhcpcd.conf should solve it for you.

> > Another possible workaround is to add "noipv4ll" to dhcpcd.conf,
>
> Not tried.

It disallows dhcpcd to add IPv4LL address on any network interface.

Reco

[Christoph Brinkhaus]

Am Sun, Feb 26, 2023 at 01:21:07PM -0600 schrieb David Wright:

Hello David and Max,

> On Sun 26 Feb 2023 at 19:08:01 (+0100), Christoph Brinkhaus wrote:
> > Am Sun, Feb 26, 2023 at 10:33:19PM +0700 schrieb Max Nikulin:
> > > On 25/02/2023 19:49, Christoph Brinkhaus wrote:
> > > > Now there are no messages reported by journald as above.

[snip]

> > I have tried that and found the next issue.
> > systemd-networkd-wait-online runs into a time out after the default
> > timeout of 2 minutes.

[snip]

> A couple of pages I turned up were:
>
> https://systemd.io/NETWORK_ONLINE/
> https://github.com/NLnetLabs/unbound/issues/773

I will just inform about the status. Everything is fine now. A word
about systemd-networkd-wait-online: With this service running there
has been even a delay of 1-2 seconds when switching from one console
to a different one (the consoles when X is not running). I have no
idea about that side effect.

Now I have disabled systemd-networkd-wait-online and I have add a
comment in the last line of /usr/lib/systemd/system//systemd-networkd.service
which is now
# 28.2.2023 Also=systemd-networkd-wait-online.service

The network works as desired and the strange delay when switching the
console is history as well.

Thank you both for all the support,

[Max Nikulin]

On 28/02/2023 17:25, Christoph Brinkhaus wrote:
> I will just inform about the status. Everything is fine now. A word
> about systemd-networkd-wait-online: With this service running there
> has been even a delay of 1-2 seconds when switching from one console
> to a different one (the consoles when X is not running). I have no
> idea about that side effect.

Does it happen each time or it is getty startup time? In the latter case
you may try (for various console numbers)

systemd-analyze critical-chain ge...@tty1.service

> Now I have disabled systemd-networkd-wait-online and I have add a
> comment in the last line of /usr/lib/systemd/system//systemd-networkd.service
> which is now
> # 28.2.2023 Also=systemd-networkd-wait-online.service

Ideally the root cause of strange behavior should be debugged. Perhaps
some dependency should be removed from e.g. multi-user.target or
network-online.target. Probably "systemd-analyze critical-chain" may
give some hints.

Any case I would not touch files in /usr/lib/systemd. It should confuse
tools like systemd-delta. It is possible to override specific properties
by creating of drop-in snippets in
/etc/systemd/system/systemd-networkd.service.d/. See systemd.unit(5),
e.g. run

systemctl edit systemd-networkd.service

[Install]
# Clear
Also=
# Add other values from the original file
Also=systemd-networkd.socket

Check result

systemd-analyze verify systemd-networkd.service

I hope, it is a better way to apply your workaround. I can not suggest a
better solution for tty delay issue, but I think it exists. "Also="
should affect "systemctl enable systemd-networkd.service" and "disable"
commands, so I puzzled why it helps at all.

[Christoph Brinkhaus]

Am Thu, Mar 02, 2023 at 09:26:33PM +0700 schrieb Max Nikulin:
> On 28/02/2023 17:25, Christoph Brinkhaus wrote:
> > I will just inform about the status. Everything is fine now. A word
> > about systemd-networkd-wait-online: With this service running there
> > has been even a delay of 1-2 seconds when switching from one console
> > to a different one (the consoles when X is not running). I have no
> > idea about that side effect.
>
> Does it happen each time or it is getty startup time? In the latter case you
> may try (for various console numbers)
>
> systemd-analyze critical-chain ge...@tty1.service
>

It is happening each time when changing the console.

> > Now I have disabled systemd-networkd-wait-online and I have add a
> > comment in the last line of /usr/lib/systemd/system//systemd-networkd.service
> > which is now
> > # 28.2.2023 Also=systemd-networkd-wait-online.service
>
> Ideally the root cause of strange behavior should be debugged. Perhaps some
> dependency should be removed from e.g. multi-user.target or
> network-online.target. Probably "systemd-analyze critical-chain" may give
> some hints.

Ok, it is no problem to include the service again. It is just strange
that it is not referenced anywhere. But I will try systemd-analyze.
I have not been aware about such a tool before. But it should be worth
to learn how to use it. Thank you for the information!

>
> Any case I would not touch files in /usr/lib/systemd. It should confuse
> tools like systemd-delta. It is possible to override specific properties by
> creating of drop-in snippets in
> /etc/systemd/system/systemd-networkd.service.d/. See systemd.unit(5), e.g.
> run
>
> systemctl edit systemd-networkd.service
>
> [Install]
> # Clear
> Also=
> # Add other values from the original file
> Also=systemd-networkd.socket
>
> Check result
>
> systemd-analyze verify systemd-networkd.service
>
> I hope, it is a better way to apply your workaround. I can not suggest a
> better solution for tty delay issue, but I think it exists. "Also=" should
> affect "systemctl enable systemd-networkd.service" and "disable" commands,
> so I puzzled why it helps at all.

I will try that, too. I have /etc under version control using git.
That makes it easy to get informed about changes.

Kind regards,

[Max Nikulin]

On 02/03/2023 22:27, Christoph Brinkhaus wrote:
> Am Thu, Mar 02, 2023 at 09:26:33PM +0700 schrieb Max Nikulin:
>> On 28/02/2023 17:25, Christoph Brinkhaus wrote:
>>> I will just inform about the status. Everything is fine now. A word
>>> about systemd-networkd-wait-online: With this service running there
>>> has been even a delay of 1-2 seconds when switching from one console
>>> to a different one (the consoles when X is not running). I have no
>>> idea about that side effect.
>> Does it happen each time or it is getty startup time? In the latter case you
>> may try (for various console numbers)
>>

>> systemd-analyze critical-...@tty1.service

>>
> It is happening each time when changing the console.

I have no idea which way it may be related to network configuration in
general and to 169.254.x.y link local addresses in particular. It is
better to start a new thread.

- Does journalctl -f show some messages during such delay?
- Do you mean that each of [Ctrl+Alt+F3], [Ctrl+Alt+F4], [Ctrl+Alt+F3]
hit in sequence cause delay?
- Policy Kit may need to adjust permissions to some devices (video,
audio, etc.), but 2 seconds is unreasonably long delay.

[Christoph Brinkhaus]

Am Fri, Mar 03, 2023 at 10:09:42PM +0700 schrieb Max Nikulin:
> On 02/03/2023 22:27, Christoph Brinkhaus wrote:
> > Am Thu, Mar 02, 2023 at 09:26:33PM +0700 schrieb Max Nikulin:
> > > On 28/02/2023 17:25, Christoph Brinkhaus wrote:
> > > > I will just inform about the status. Everything is fine now. A word
> > > > about systemd-networkd-wait-online: With this service running there
> > > > has been even a delay of 1-2 seconds when switching from one console
> > > > to a different one (the consoles when X is not running). I have no
> > > > idea about that side effect.
> > > Does it happen each time or it is getty startup time? In the latter case you
> > > may try (for various console numbers)
> > >
> > > systemd-analyze critical-...@tty1.service
> > >
> > It is happening each time when changing the console.

I just remember that systemd-networkd-wait-online has been introduced
just by the unbound fix as proposed in
https://github.com/NLnetLabs/unbound/issues/773.
I do now know about any systemd service which make use of that.
But the certainly is at least one.

> I have no idea which way it may be related to network configuration in
> general and to 169.254.x.y link local addresses in particular. It is better
> to start a new thread.
>
> - Does journalctl -f show some messages during such delay?
> - Do you mean that each of [Ctrl+Alt+F3], [Ctrl+Alt+F4], [Ctrl+Alt+F3] hit
> in sequence cause delay?

Here it is [Alt+F1], [ALT+F2]. CTRL is just required when coming from
a X11 screen. But even without X11 this delay happened without any
indication in the log files.

> - Policy Kit may need to adjust permissions to some devices (video, audio,
> etc.), but 2 seconds is unreasonably long delay.

I agree, especially when the trigger as switching the console is
totally unrelated.