Re: unbound and fetchmail (was: Re: Remove route '169.254.0.0/16 dev ovs-system')
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-chaingetty@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. Kind regards, Christoph -- Ist die Katze gesund schmeckt sie dem Hund.
Re: unbound and fetchmail (was: Re: Remove route '169.254.0.0/16 dev ovs-system')
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-chaingetty@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.
Re: unbound and fetchmail (was: Re: Remove route '169.254.0.0/16 dev ovs-system')
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 getty@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, Christoph -- Ist die Katze gesund schmeckt sie dem Hund.
Re: unbound and fetchmail (was: Re: Remove route '169.254.0.0/16 dev ovs-system')
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 getty@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.
Re: unbound and fetchmail (was: Re: Remove route '169.254.0.0/16 dev ovs-system')
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, Christoph -- Ist die Katze gesund schmeckt sie dem Hund.
Re: Remove route '169.254.0.0/16 dev ovs-system'
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
Re: Remove route '169.254.0.0/16 dev ovs-system'
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 Groeten Geert Stappers -- Silence is hard to parse
Re: unbound and fetchmail (was: Re: Remove route '169.254.0.0/16 dev ovs-system')
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. > > > > 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". > > 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! 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.
Re: unbound and fetchmail (was: Re: Remove route '169.254.0.0/16 dev ovs-system')
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. 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". 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! Kind regards, Christoph -- Ist die Katze gesund schmeckt sie dem Hund.
Re: Remove route '169.254.0.0/16 dev ovs-system'
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.
Re: unbound and fetchmail (was: Re: Remove route '169.254.0.0/16 dev ovs-system')
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. Kind regards, Christoph -- Ist die Katze gesund schmeckt sie dem Hund.
unbound and fetchmail (was: Re: Remove route '169.254.0.0/16 dev ovs-system')
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".
Re: Remove route '169.254.0.0/16 dev ovs-system'
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
Re: Remove route '169.254.0.0/16 dev ovs-system'
Hi. On Sun, Feb 26, 2023 at 03:14:22PM +0100, Geert Stappers wrote: > Hi. > > 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: > > > 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 > > > 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 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
Re: Remove route '169.254.0.0/16 dev ovs-system'
Hi. 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: > > 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 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 Groeten Geert Stappers -- Silence is hard to parse
Re: Remove route '169.254.0.0/16 dev ovs-system'
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
Re: Remove route '169.254.0.0/16 dev ovs-system'
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]: [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" Groeten Geert Stappers -- Silence is hard to parse
Re: Remove route '169.254.0.0/16 dev ovs-system'
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] Kind regards, Christoph -- Ist die Katze gesund schmeckt sie dem Hund.
Re: Remove route '169.254.0.0/16 dev ovs-system'
On Fri, Feb 24, 2023 at 9:51 PM David Wright 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
Re: Remove route '169.254.0.0/16 dev ovs-system'
On Fri 24 Feb 2023 at 22:43:49 (+0100), Geert Stappers wrote: > 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. > > > > $ 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(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 > $ > 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.
Re: Remove route '169.254.0.0/16 dev ovs-system'
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
Re: Remove route '169.254.0.0/16 dev ovs-system'
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. $ 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(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 $ Groeten Geert Stappers -- Silence is hard to parse
Re: Remove route '169.254.0.0/16 dev ovs-system'
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: > > 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! 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.
Re: Remove route '169.254.0.0/16 dev ovs-system'
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. Kind regards, Christoph -- Ist die Katze gesund schmeckt sie dem Hund.
Re: Remove route '169.254.0.0/16 dev ovs-system'
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.
Re: Remove route '169.254.0.0/16 dev ovs-system'
On 22/02/2023 19:40, Greg Wooledge wrote: 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. 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 OpenPGP_signature Description: OpenPGP digital signature
Re: Remove route '169.254.0.0/16 dev ovs-system'
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.
Re: Remove route '169.254.0.0/16 dev ovs-system'
On Wed, Feb 22, 2023 at 1:43 PM David Wright wrote: > > On Tue 21 Feb 2023 at 13:48:58 (-0500), Jeffrey Walton wrote: > > On Tue, Feb 21, 2023 at 1:26 PM Christoph Brinkhaus > > 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. 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
Re: Remove route '169.254.0.0/16 dev ovs-system'
On Wed 22 Feb 2023 at 17:45:40 (+0100), 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: > > > > > 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. 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.
Re: Remove route '169.254.0.0/16 dev ovs-system'
On Tue 21 Feb 2023 at 13:48:58 (-0500), Jeffrey Walton wrote: > On Tue, Feb 21, 2023 at 1:26 PM Christoph Brinkhaus > 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.
Re: Remove route '169.254.0.0/16 dev ovs-system'
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. Kind regards, Christoph -- Ist die Katze gesund schmeckt sie dem Hund.
Re: Remove route '169.254.0.0/16 dev ovs-system'
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.
Re: Remove route '169.254.0.0/16 dev ovs-system'
On Tue, Feb 21, 2023 at 01:48:58PM -0500, Jeffrey Walton wrote: > On Tue, Feb 21, 2023 at 1:26 PM Christoph Brinkhaus > 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. 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 signature.asc Description: PGP signature
Re: Remove route '169.254.0.0/16 dev ovs-system'
On Tue, Feb 21, 2023 at 1:26 PM Christoph Brinkhaus 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
Re: Remove route '169.254.0.0/16 dev ovs-system'
Am Tue, Feb 21, 2023 at 01:06:01PM -0500 schrieb Jeffrey Walton: > On Tue, Feb 21, 2023 at 12:45 PM Christoph Brinkhaus > 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. Kind regards, Christoph -- Ist die Katze gesund schmeckt sie dem Hund.
Re: Remove route '169.254.0.0/16 dev ovs-system'
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
Re: Remove route '169.254.0.0/16 dev ovs-system'
On Tue, Feb 21, 2023 at 12:45 PM Christoph Brinkhaus 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
Re: Remove route '169.254.0.0/16 dev ovs-system'
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. Kind regards, Christoph -- Ist die Katze gesund schmeckt sie dem Hund.
Re: Remove route '169.254.0.0/16 dev ovs-system'
On 20/02/2023 21:44, Christoph Brinkhaus wrote: Am Mon, Feb 20, 2023 at 09:59:20AM +0700 schrieb Max Nikulin: 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?
Re: Remove route '169.254.0.0/16 dev ovs-system'
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 signature.asc Description: OpenPGP digital signature
Re: Remove route '169.254.0.0/16 dev ovs-system'
On Mon, Feb 20, 2023 at 9:28 AM wrote: >[...] > -- > 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. ;-) > ' >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.
Re: Remove route '169.254.0.0/16 dev ovs-system'
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. Kind regards, Christoph -- Ist die Katze gesund schmeckt sie dem Hund.
Re: Remove route '169.254.0.0/16 dev ovs-system'
On Monday, February 20, 2023 04:05:19 AM to...@tuxteam.de wrote: > On Mon, Feb 20, 2023 at 02:42:59AM -0500, Jeffrey Walton wrote: > > On Mon, Feb 20, 2023 at 2:27 AM 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 ;-) 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. ;-) '
Re: Remove route '169.254.0.0/16 dev ovs-system'
On Mon, Feb 20, 2023 at 02:42:59AM -0500, Jeffrey Walton wrote: > On Mon, Feb 20, 2023 at 2:27 AM 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 signature.asc Description: PGP signature
Re: Remove route '169.254.0.0/16 dev ovs-system'
On Mon, Feb 20, 2023 at 2:27 AM wrote: > > On Mon, Feb 20, 2023 at 12:53:25AM -0500, Jeffrey Walton wrote: > > On Sun, Feb 19, 2023 at 11:22 AM Geert Stappers > > 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. And Wireshark (https://wiki.wireshark.org/APIPA.md) and Cisco (https://study-ccna.com/apipa-automatic-private-ip-addressing/). Jeff
Re: Remove route '169.254.0.0/16 dev ovs-system'
On Mon, Feb 20, 2023 at 12:53:25AM -0500, Jeffrey Walton wrote: > On Sun, Feb 19, 2023 at 11:22 AM Geert Stappers 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 signature.asc Description: PGP signature
Re: Remove route '169.254.0.0/16 dev ovs-system'
On Sun, Feb 19, 2023 at 11:22 AM Geert Stappers 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
Re: Remove route '169.254.0.0/16 dev ovs-system'
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.
Re: Remove route '169.254.0.0/16 dev ovs-system'
On Mon 20 Feb 2023 at 09:59:20 (+0700), Max Nikulin wrote: > 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. 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: 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: 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: 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.
Re: Remove route '169.254.0.0/16 dev ovs-system'
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.
Re: Remove route '169.254.0.0/16 dev ovs-system'
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. -- Ist die Katze gesund schmeckt sie dem Hund.
Re: Remove route '169.254.0.0/16 dev ovs-system'
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 SUBDESCRIPTION
● 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.
$
--
Silence is hard to parse
Re: Remove route '169.254.0.0/16 dev ovs-system'
>> 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
Re: Remove route '169.254.0.0/16 dev ovs-system'
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.
Remove route '169.254.0.0/16 dev ovs-system'
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
