Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.user > #255176 > unrolled thread
| Started by | Geert Stappers <stappers@stappers.nl> |
|---|---|
| First post | 2023-02-19 17:30 +0100 |
| Last post | 2023-02-20 16:20 +0100 |
| Articles | 20 on this page of 55 — 13 participants |
Back to article view | Back to linux.debian.user
Remove route '169.254.0.0/16 dev ovs-system' Geert Stappers <stappers@stappers.nl> - 2023-02-19 17:30 +0100
Re: Remove route '169.254.0.0/16 dev ovs-system' Christoph Brinkhaus <c.brinkhaus@t-online.de> - 2023-02-19 17:40 +0100
Re: Remove route '169.254.0.0/16 dev ovs-system' Stefan Monnier <monnier@iro.umontreal.ca> - 2023-02-19 18:30 +0100
Re: Remove route '169.254.0.0/16 dev ovs-system' Geert Stappers <stappers@stappers.nl> - 2023-02-19 20:00 +0100
Re: Remove route '169.254.0.0/16 dev ovs-system' Christoph Brinkhaus <c.brinkhaus@t-online.de> - 2023-02-19 20:20 +0100
Re: Remove route '169.254.0.0/16 dev ovs-system' Max Nikulin <manikulin@gmail.com> - 2023-02-20 05:40 +0100
Re: Remove route '169.254.0.0/16 dev ovs-system' Max Nikulin <manikulin@gmail.com> - 2023-02-20 04:00 +0100
Re: Remove route '169.254.0.0/16 dev ovs-system' David Wright <deblis@lionunicorn.co.uk> - 2023-02-20 05:20 +0100
Re: Remove route '169.254.0.0/16 dev ovs-system' Christoph Brinkhaus <c.brinkhaus@t-online.de> - 2023-02-20 15:50 +0100
Re: Remove route '169.254.0.0/16 dev ovs-system' Max Nikulin <manikulin@gmail.com> - 2023-02-21 17:10 +0100
Re: Remove route '169.254.0.0/16 dev ovs-system' Christoph Brinkhaus <c.brinkhaus@t-online.de> - 2023-02-21 18:50 +0100
Re: Remove route '169.254.0.0/16 dev ovs-system' Jeffrey Walton <noloader@gmail.com> - 2023-02-21 19:10 +0100
Re: Remove route '169.254.0.0/16 dev ovs-system' Christoph Brinkhaus <c.brinkhaus@t-online.de> - 2023-02-21 19:30 +0100
Re: Remove route '169.254.0.0/16 dev ovs-system' Jeffrey Walton <noloader@gmail.com> - 2023-02-21 19:50 +0100
Re: Remove route '169.254.0.0/16 dev ovs-system' <tomas@tuxteam.de> - 2023-02-21 20:10 +0100
Re: Remove route '169.254.0.0/16 dev ovs-system' David Wright <deblis@lionunicorn.co.uk> - 2023-02-22 19:50 +0100
Re: Remove route '169.254.0.0/16 dev ovs-system' Jeffrey Walton <noloader@gmail.com> - 2023-02-22 20:10 +0100
Re: Remove route '169.254.0.0/16 dev ovs-system' Greg Wooledge <greg@wooledge.org> - 2023-02-22 20:50 +0100
Re: Remove route '169.254.0.0/16 dev ovs-system' Darac Marjal <mailinglist@darac.org.uk> - 2023-02-22 21:10 +0100
Re: Remove route '169.254.0.0/16 dev ovs-system' Max Nikulin <manikulin@gmail.com> - 2023-02-22 16:30 +0100
Re: Remove route '169.254.0.0/16 dev ovs-system' Christoph Brinkhaus <c.brinkhaus@t-online.de> - 2023-02-22 17:50 +0100
Re: Remove route '169.254.0.0/16 dev ovs-system' David Wright <deblis@lionunicorn.co.uk> - 2023-02-22 19:50 +0100
Re: Remove route '169.254.0.0/16 dev ovs-system' Max Nikulin <manikulin@gmail.com> - 2023-02-24 16:20 +0100
Re: Remove route '169.254.0.0/16 dev ovs-system' Christoph Brinkhaus <c.brinkhaus@t-online.de> - 2023-02-24 19:50 +0100
Re: Remove route '169.254.0.0/16 dev ovs-system' David Wright <deblis@lionunicorn.co.uk> - 2023-02-24 20:30 +0100
Re: Remove route '169.254.0.0/16 dev ovs-system' Geert Stappers <stappers@stappers.nl> - 2023-02-24 22:50 +0100
Re: Remove route '169.254.0.0/16 dev ovs-system' Max Nikulin <manikulin@gmail.com> - 2023-02-25 03:50 +0100
Re: Remove route '169.254.0.0/16 dev ovs-system' Geert Stappers <stappers@stappers.nl> - 2023-02-26 12:20 +0100
Re: Remove route '169.254.0.0/16 dev ovs-system' Reco <recoverym4n@enotuniq.net> - 2023-02-26 14:20 +0100
Re: Remove route '169.254.0.0/16 dev ovs-system' Geert Stappers <stappers@stappers.nl> - 2023-02-26 15:20 +0100
Re: Remove route '169.254.0.0/16 dev ovs-system' Reco <recoverym4n@enotuniq.net> - 2023-02-26 15:50 +0100
Re: Remove route '169.254.0.0/16 dev ovs-system' Geert Stappers <stappers@stappers.nl> - 2023-02-27 23:00 +0100
Re: Remove route '169.254.0.0/16 dev ovs-system' Reco <recoverym4n@enotuniq.net> - 2023-02-28 07:10 +0100
Re: Remove route '169.254.0.0/16 dev ovs-system' Max Nikulin <manikulin@gmail.com> - 2023-02-26 16:20 +0100
Re: Remove route '169.254.0.0/16 dev ovs-system' David Wright <deblis@lionunicorn.co.uk> - 2023-02-26 18:10 +0100
Re: Remove route '169.254.0.0/16 dev ovs-system' David Wright <deblis@lionunicorn.co.uk> - 2023-02-25 04:00 +0100
Re: Remove route '169.254.0.0/16 dev ovs-system' Jeffrey Walton <noloader@gmail.com> - 2023-02-25 04:40 +0100
Re: Remove route '169.254.0.0/16 dev ovs-system' Christoph Brinkhaus <c.brinkhaus@t-online.de> - 2023-02-25 13:50 +0100
unbound and fetchmail (was: Re: Remove route '169.254.0.0/16 dev ovs-system') Max Nikulin <manikulin@gmail.com> - 2023-02-26 16:40 +0100
Re: unbound and fetchmail (was: Re: Remove route '169.254.0.0/16 dev ovs-system') Christoph Brinkhaus <c.brinkhaus@t-online.de> - 2023-02-26 17:30 +0100
Re: unbound and fetchmail (was: Re: Remove route '169.254.0.0/16 dev ovs-system') Christoph Brinkhaus <c.brinkhaus@t-online.de> - 2023-02-26 19:10 +0100
Re: unbound and fetchmail (was: Re: Remove route '169.254.0.0/16 dev ovs-system') David Wright <deblis@lionunicorn.co.uk> - 2023-02-26 20:30 +0100
Re: unbound and fetchmail (was: Re: Remove route '169.254.0.0/16 dev ovs-system') Christoph Brinkhaus <c.brinkhaus@t-online.de> - 2023-02-28 11:30 +0100
Re: unbound and fetchmail (was: Re: Remove route '169.254.0.0/16 dev ovs-system') Max Nikulin <manikulin@gmail.com> - 2023-03-02 15:30 +0100
Re: unbound and fetchmail (was: Re: Remove route '169.254.0.0/16 dev ovs-system') Christoph Brinkhaus <c.brinkhaus@t-online.de> - 2023-03-02 16:30 +0100
Re: unbound and fetchmail (was: Re: Remove route '169.254.0.0/16 dev ovs-system') Max Nikulin <manikulin@gmail.com> - 2023-03-03 16:20 +0100
Re: unbound and fetchmail (was: Re: Remove route '169.254.0.0/16 dev ovs-system') Christoph Brinkhaus <c.brinkhaus@t-online.de> - 2023-03-03 16:30 +0100
Re: Remove route '169.254.0.0/16 dev ovs-system' Reco <recoverym4n@enotuniq.net> - 2023-02-21 19:30 +0100
Re: Remove route '169.254.0.0/16 dev ovs-system' Jeffrey Walton <noloader@gmail.com> - 2023-02-20 07:00 +0100
Re: Remove route '169.254.0.0/16 dev ovs-system' <tomas@tuxteam.de> - 2023-02-20 08:30 +0100
Re: Remove route '169.254.0.0/16 dev ovs-system' Jeffrey Walton <noloader@gmail.com> - 2023-02-20 08:50 +0100
Re: Remove route '169.254.0.0/16 dev ovs-system' tomas@tuxteam.de - 2023-02-20 10:10 +0100
Re: Remove route '169.254.0.0/16 dev ovs-system' rhkramer@gmail.com - 2023-02-20 15:30 +0100
Re: Remove route '169.254.0.0/16 dev ovs-system' Jeffrey Walton <noloader@gmail.com> - 2023-02-20 16:10 +0100
Re: Remove route '169.254.0.0/16 dev ovs-system' The Wanderer <wanderer@fastmail.fm> - 2023-02-20 16:20 +0100
Page 1 of 3 [1] 2 3 Next page →
| From | Geert Stappers <stappers@stappers.nl> |
|---|---|
| Date | 2023-02-19 17:30 +0100 |
| Subject | Remove route '169.254.0.0/16 dev ovs-system' |
| Message-ID | <G0UJz-72MN-3@gated-at.bofh.it> |
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
[toc] | [next] | [standalone]
| From | Christoph Brinkhaus <c.brinkhaus@t-online.de> |
|---|---|
| Date | 2023-02-19 17:40 +0100 |
| Message-ID | <G0UTf-72PX-3@gated-at.bofh.it> |
| In reply to | #255176 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Stefan Monnier <monnier@iro.umontreal.ca> |
|---|---|
| Date | 2023-02-19 18:30 +0100 |
| Message-ID | <G0VFD-73m2-9@gated-at.bofh.it> |
| In reply to | #255177 |
>> 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
[toc] | [prev] | [next] | [standalone]
| From | Geert Stappers <stappers@stappers.nl> |
|---|---|
| Date | 2023-02-19 20:00 +0100 |
| Message-ID | <G0X4J-747i-31@gated-at.bofh.it> |
| In reply to | #255178 |
On Sun, Feb 19, 2023 at 12:21:36PM -0500, Stefan Monnier wrote:
> >> Having installed package openvswitch-switch and doing `ip route` I do get
> >> 169.254.0.0/16 dev ovs-system scope link src 169.254.201.7 metric 1004
> >>
> >> What can be done to prevent that "zeroconf"
> >> configures interface `ovs-system`?
> >
> > Please have a look at https://wiki.debian.org/Avahi.
> > According to the section "Disabling avahi-daemon" the following
> > commands should work:
> >
> > For permenant disablement (surviving a machine reboot):
> > systemctl mask avahi-daemon.service avahi-daemon.socket
> > systemctl disable avahi-daemon.service avahi-daemon.socket
> > systemctl stop avahi-daemon.service avahi-daemon.socket
>
> But Avahi provides more functionality (e.g. mdns) than merely
> configuring network interfaces,
> so disabling it altogether may be undesired.
Yes, may. And by disabling it I will find out what I miss :-)
> So hopefully there's a way to keep Avahi and still avoid that interface
> being configured in such a dummy way.
> [ I thought Avahi only did such configuration as a "last recourse", so
> there's a chance that you're only seeing the effect of another problem
> which prevents the interface from being configured properly and
> there's just no need to worry about preventing this dummy config:
> just find and fix the other problem, and then Avahi won't kick in. ]
Disabling avahi did not prevent route set on device ovs-system.
My guess is that other compoments ( network-manager, systemd-networkd )
are involved.
Regards Geert Stappers
screenshot:
$ systemctl status avahi-daemon{,.socket}
○ avahi-daemon.service
Loaded: masked (Reason: Unit avahi-daemon.service is masked.)
Active: inactive (dead)
○ avahi-daemon.socket
Loaded: masked (Reason: Unit avahi-daemon.socket is masked.)
Active: inactive (dead)
$ ip route | grep ovs-system
169.254.0.0/16 dev ovs-system scope link src 169.254.201.7 metric 1004
$ systemctl --failed
UNIT LOAD ACTIVE SUB DESCRIPTION
● systemd-networkd-wait-online.service loaded failed failed Wait for
Network to be Configured
LOAD = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of
SUB.
SUB = The low-level unit activation state, values depend on unit
type.
1 loaded unit listed.
$ systemctl status systemd-networkd-wait-online
× systemd-networkd-wait-online.service - Wait for Network to be Configured
Loaded: loaded (/lib/systemd/system/systemd-networkd-wait-online.service; enabled; preset: disabled)
Active: failed (Result: exit-code) since Sun 2023-02-19 18:48:17 CET; 10min ago
Docs: man:systemd-networkd-wait-online.service(8)
Process: 601 ExecStart=/lib/systemd/systemd-networkd-wait-online (code=exited, status=1/FAILURE)
Main PID: 601 (code=exited, status=1/FAILURE)
CPU: 32ms
feb 19 18:46:18 trancilo systemd-networkd-wait-online[601]: wlan0: Failed to update link state, ignoring: No such file or directory
feb 19 18:46:18 trancilo systemd-networkd-wait-online[601]: ovs-system: Failed to update link state, ignoring: No such file or directory
feb 19 18:46:18 trancilo systemd-networkd-wait-online[601]: ovs-system: Failed to update link state, ignoring: No such file or directory
feb 19 18:46:18 trancilo systemd-networkd-wait-online[601]: ovsbr0: Failed to update link state, ignoring: No such file or directory
feb 19 18:46:18 trancilo systemd-networkd-wait-online[601]: ovsbr0: Failed to update link state, ignoring: No such file or directory
feb 19 18:46:18 trancilo systemd-networkd-wait-online[601]: ovsbr0: Failed to update link state, ignoring: No such file or directory
feb 19 18:48:17 trancilo systemd-networkd-wait-online[601]: Timeout occurred while waiting for network connectivity.
feb 19 18:48:17 trancilo systemd[1]: systemd-networkd-wait-online.service: Main process exited, code=exited, status=1/FAILURE
feb 19 18:48:17 trancilo systemd[1]: systemd-networkd-wait-online.service: Failed with result 'exit-code'.
feb 19 18:48:17 trancilo systemd[1]: Failed to start systemd-networkd-wait-online.service - Wait for Network to be Configured.
$
--
Silence is hard to parse
[toc] | [prev] | [next] | [standalone]
| From | Christoph Brinkhaus <c.brinkhaus@t-online.de> |
|---|---|
| Date | 2023-02-19 20:20 +0100 |
| Message-ID | <G0Xo5-74tr-1@gated-at.bofh.it> |
| In reply to | #255182 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Max Nikulin <manikulin@gmail.com> |
|---|---|
| Date | 2023-02-20 05:40 +0100 |
| Subject | Re: Remove route '169.254.0.0/16 dev ovs-system' |
| Message-ID | <G1681-79RE-1@gated-at.bofh.it> |
| In reply to | #255182 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Max Nikulin <manikulin@gmail.com> |
|---|---|
| Date | 2023-02-20 04:00 +0100 |
| Subject | Re: Remove route '169.254.0.0/16 dev ovs-system' |
| Message-ID | <G14zf-78J5-5@gated-at.bofh.it> |
| In reply to | #255177 |
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.
[toc] | [prev] | [next] | [standalone]
| From | David Wright <deblis@lionunicorn.co.uk> |
|---|---|
| Date | 2023-02-20 05:20 +0100 |
| Subject | Re: Remove route '169.254.0.0/16 dev ovs-system' |
| Message-ID | <G15OF-79Le-1@gated-at.bofh.it> |
| In reply to | #255190 |
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: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: enp2s2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 00:98:76:54:32:10 brd ff:ff:ff:ff:ff:ff
3: wlp2s4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 00:0e:12:34:56:78 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.10/24 brd 192.168.1.255 scope global dynamic wlp2s4
valid_lft 80846sec preferred_lft 80846sec
inet6 fe80::20e:12ff:fe34:5678/64 scope link
valid_lft forever preferred_lft forever
$
I don't recall ever seeing a 169.254.0.0 route generated in the
absence of avahi-autoipd.
I use avahi-daemon for driverless printing on systems that have
no 169.254.… addresses, routes, etc. The entire LAN is given its
IP addresses by a DHCP server in my primary router.
Cheers,
David.
[toc] | [prev] | [next] | [standalone]
| From | Christoph Brinkhaus <c.brinkhaus@t-online.de> |
|---|---|
| Date | 2023-02-20 15:50 +0100 |
| Subject | Re: Remove route '169.254.0.0/16 dev ovs-system' |
| Message-ID | <G1fEl-7gkd-15@gated-at.bofh.it> |
| In reply to | #255190 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Max Nikulin <manikulin@gmail.com> |
|---|---|
| Date | 2023-02-21 17:10 +0100 |
| Subject | Re: Remove route '169.254.0.0/16 dev ovs-system' |
| Message-ID | <G1Dnj-7v4O-3@gated-at.bofh.it> |
| In reply to | #255216 |
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?
[toc] | [prev] | [next] | [standalone]
| From | Christoph Brinkhaus <c.brinkhaus@t-online.de> |
|---|---|
| Date | 2023-02-21 18:50 +0100 |
| Subject | Re: Remove route '169.254.0.0/16 dev ovs-system' |
| Message-ID | <G1EW5-7vPC-3@gated-at.bofh.it> |
| In reply to | #255248 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Jeffrey Walton <noloader@gmail.com> |
|---|---|
| Date | 2023-02-21 19:10 +0100 |
| Subject | Re: Remove route '169.254.0.0/16 dev ovs-system' |
| Message-ID | <G1Ffs-7wbB-9@gated-at.bofh.it> |
| In reply to | #255249 |
On Tue, Feb 21, 2023 at 12:45 PM Christoph Brinkhaus <c.brinkhaus@t-online.de> wrote: > Am Tue, Feb 21, 2023 at 11:00:56PM +0700 schrieb Max Nikulin: > > On 20/02/2023 21:44, Christoph Brinkhaus wrote: > > > Am Mon, Feb 20, 2023 at 09:59:20AM +0700 schrieb Max > > > > Perhaps to get rid of 169.254.x.y addresses, it is enough to properly > > > > configure network interface, either to ensure that DHCP server is available > > > > or to assign a static address. After that you may forget about existence of > > > > avahi-autoipd. > > > > > > On my system it did not help. One "issue" might be, that systemd > > > starts services in some sequence. But it does not wait for a service > > > to complete. At least in case of stuff I have observed on my system. > > > > Out of curiosity, is link-local IP address assigned during boot or later > > when e.g. WiFi connection is temporary lost? How long does it take to get > > response from DHCP server? Which way network is configured (ifupdown, > > NetworkManager, systemd-networkd) in your case? > > The 169.254.x.y has been assigned during boot. I have not used DHCP. > The configuration has been static. The ping to the router takes about > 4ms. I have no idea if it is possible to estimate a DHCP response > time. The network has been configured via systemd-networking. You have to supply a static ip address or a DHCP server. Since you supplied a static ip address, then the fact that you are getting an APIPA is a bug. You should file a bug report with the package (Avahi? Systemd?) that is providing the APIPA. But backing up... I suspect there's something wrong with your static ip address assignment. The address is already taken, the netmask is wrong, or the gateway is wrong. Looking back through this thread, I did not see where you showed your static ip configuration. Maybe you should start with that. If it is bad, then the APIPA is just a symptom of the [static ip address] problem. Jeff
[toc] | [prev] | [next] | [standalone]
| From | Christoph Brinkhaus <c.brinkhaus@t-online.de> |
|---|---|
| Date | 2023-02-21 19:30 +0100 |
| Subject | Re: Remove route '169.254.0.0/16 dev ovs-system' |
| Message-ID | <G1FyN-7whV-3@gated-at.bofh.it> |
| In reply to | #255250 |
Am Tue, Feb 21, 2023 at 01:06:01PM -0500 schrieb Jeffrey Walton: > On Tue, Feb 21, 2023 at 12:45 PM Christoph Brinkhaus > <c.brinkhaus@t-online.de> wrote: > > Am Tue, Feb 21, 2023 at 11:00:56PM +0700 schrieb Max Nikulin: > > > On 20/02/2023 21:44, Christoph Brinkhaus wrote: > > > > Am Mon, Feb 20, 2023 at 09:59:20AM +0700 schrieb Max > > > > Perhaps to get rid of 169.254.x.y addresses, it is enough to properly > > > > > configure network interface, either to ensure that DHCP server is available > > > > > or to assign a static address. After that you may forget about existence of > > > > > avahi-autoipd. > > > > > > > > On my system it did not help. One "issue" might be, that systemd > > > > starts services in some sequence. But it does not wait for a service > > > > to complete. At least in case of stuff I have observed on my system. > > > > > > Out of curiosity, is link-local IP address assigned during boot or later > > > when e.g. WiFi connection is temporary lost? How long does it take to get > > > response from DHCP server? Which way network is configured (ifupdown, > > > NetworkManager, systemd-networkd) in your case? > > > > The 169.254.x.y has been assigned during boot. I have not used DHCP. > > The configuration has been static. The ping to the router takes about > > 4ms. I have no idea if it is possible to estimate a DHCP response > > time. The network has been configured via systemd-networking. > > You have to supply a static ip address or a DHCP server. This is correct. > > Since you supplied a static ip address, then the fact that you are > getting an APIPA is a bug. You should file a bug report with the > package (Avahi? Systemd?) that is providing the APIPA. I assume that there might be a timing issue with systemd-networking. A comparable happened with fetchmail started by systemd. The head of the description is [Unit] Description=A remote mail retrieval and forwarding utility After=network-online.target opensmtpd.service unbound.service Requires=opensmtpd.service unbound.service But fetchmail starts before the dependencies have been finished. I am not sure if systemd monitors the services to finish or if it just starts them in a specific order. > But backing up... I suspect there's something wrong with your static > ip address assignment. The address is already taken, the netmask is > wrong, or the gateway is wrong. > > Looking back through this thread, I did not see where you showed your > static ip configuration. Maybe you should start with that. If it is > bad, then the APIPA is just a symptom of the [static ip address] > problem. This is the systemd-networkd configuration: [Match] Name=w* [Network] DHCP=no Address=192.168.0.62/24 Gateway=192.168.0.32 DNS=127.0.0.1 I have unbound as a DNS listening at localhost. But with DNS=192.168.0.32 the behaviour has been similar. I have not yet checked the address assignment using systemd-networkd. For doing so I have to reinstall some packages. Kind regards, Christoph -- Ist die Katze gesund schmeckt sie dem Hund.
[toc] | [prev] | [next] | [standalone]
| From | Jeffrey Walton <noloader@gmail.com> |
|---|---|
| Date | 2023-02-21 19:50 +0100 |
| Subject | Re: Remove route '169.254.0.0/16 dev ovs-system' |
| Message-ID | <G1FS9-7wo1-1@gated-at.bofh.it> |
| In reply to | #255251 |
On Tue, Feb 21, 2023 at 1:26 PM Christoph Brinkhaus <c.brinkhaus@t-online.de> wrote: > [...] > > But backing up... I suspect there's something wrong with your static > > ip address assignment. The address is already taken, the netmask is > > wrong, or the gateway is wrong. > > > > Looking back through this thread, I did not see where you showed your > > static ip configuration. Maybe you should start with that. If it is > > bad, then the APIPA is just a symptom of the [static ip address] > > problem. > > This is the systemd-networkd configuration: > > [Match] > Name=w* > > [Network] > DHCP=no > Address=192.168.0.62/24 > Gateway=192.168.0.32 > DNS=127.0.0.1 > > I have unbound as a DNS listening at localhost. But with > DNS=192.168.0.32 the behaviour has been similar. > > I have not yet checked the address assignment using systemd-networkd. > For doing so I have to reinstall some packages. I don't know what the Match section does. I am suspicious of it. 192.168.0.0 address block is /16, not /24. I'm in the US, and I use Verizon for my ISP. Verizon gadgets, like set top boxes and media centers, use 192.168.0.x addresses. I never put anything on 192.168.0.x. I start with 192.168.1.x. And on the Verizon network, I've never seen a 192.168.0.x gateway. Gateways also go on 192.168.1.x. So I'm a bit suspicious of the network assignments. Jeff
[toc] | [prev] | [next] | [standalone]
| From | <tomas@tuxteam.de> |
|---|---|
| Date | 2023-02-21 20:10 +0100 |
| Subject | Re: Remove route '169.254.0.0/16 dev ovs-system' |
| Message-ID | <G1Gbv-7wN5-3@gated-at.bofh.it> |
| In reply to | #255253 |
[Multipart message — attachments visible in raw view] — view raw
On Tue, Feb 21, 2023 at 01:48:58PM -0500, Jeffrey Walton wrote: > On Tue, Feb 21, 2023 at 1:26 PM Christoph Brinkhaus > <c.brinkhaus@t-online.de> wrote: > > [...] > > > But backing up... I suspect there's something wrong with your static > > > ip address assignment. The address is already taken, the netmask is > > > wrong, or the gateway is wrong. > > > > > > Looking back through this thread, I did not see where you showed your > > > static ip configuration. Maybe you should start with that. If it is > > > bad, then the APIPA is just a symptom of the [static ip address] > > > problem. > > > > This is the systemd-networkd configuration: > > > > [Match] > > Name=w* > > > > [Network] > > DHCP=no > > Address=192.168.0.62/24 > > Gateway=192.168.0.32 > > DNS=127.0.0.1 > > > > I have unbound as a DNS listening at localhost. But with > > DNS=192.168.0.32 the behaviour has been similar. > > > > I have not yet checked the address assignment using systemd-networkd. > > For doing so I have to reinstall some packages. > > I don't know what the Match section does. I am suspicious of it. > > 192.168.0.0 address block is /16, not /24. 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
[toc] | [prev] | [next] | [standalone]
| From | David Wright <deblis@lionunicorn.co.uk> |
|---|---|
| Date | 2023-02-22 19:50 +0100 |
| Subject | Re: Remove route '169.254.0.0/16 dev ovs-system' |
| Message-ID | <G22lH-7KDI-3@gated-at.bofh.it> |
| In reply to | #255253 |
On Tue 21 Feb 2023 at 13:48:58 (-0500), Jeffrey Walton wrote: > On Tue, Feb 21, 2023 at 1:26 PM Christoph Brinkhaus > <c.brinkhaus@t-online.de> wrote: > > [...] > > > But backing up... I suspect there's something wrong with your static > > > ip address assignment. The address is already taken, the netmask is > > > wrong, or the gateway is wrong. > > > > > > Looking back through this thread, I did not see where you showed your > > > static ip configuration. Maybe you should start with that. If it is > > > bad, then the APIPA is just a symptom of the [static ip address] > > > problem. > > > > This is the systemd-networkd configuration: > > > > [Match] > > Name=w* > > > > [Network] > > DHCP=no > > Address=192.168.0.62/24 > > Gateway=192.168.0.32 > > DNS=127.0.0.1 > > > > I have unbound as a DNS listening at localhost. But with > > DNS=192.168.0.32 the behaviour has been similar. > > > > I have not yet checked the address assignment using systemd-networkd. > > For doing so I have to reinstall some packages. > > I don't know what the Match section does. I am suspicious of it. Oh, Match is great. For a typical, simple PC or laptop, you no longer have to worry about whether your wifi is called wlan0 (kernel, and iwd), wlo0, wlp365s7 (onboard/slot/path), or wlxf1dd1efadd1e (USB), it'll get matched nonetheless. Ditto for e* and ethernet. > 192.168.0.0 address block is /16, not /24. > > I'm in the US, and I use Verizon for my ISP. Verizon gadgets, like set > top boxes and media centers, use 192.168.0.x addresses. I never put > anything on 192.168.0.x. I start with 192.168.1.x. And on the Verizon > network, I've never seen a 192.168.0.x gateway. Gateways also go on > 192.168.1.x. So I'm a bit suspicious of the network assignments. I don't understand this. If you're actually running two subnets with 255.255.255.0 netmasks, and they intercommunicate with each other (your computers on subnet 1, and Verizon ISP on subnet 0), then you must have a gateway on each subnet for them to communicate through. But backing up… the systemd-networkd configuration above is that of Christoph, who wrote that their system had been (a) switched to systemd-networkd from systemd-networking, and (b) purged of avahi packages to eliminate 169.254.x.y addresses. So I'm not sure what there is to fix here. But (a) raises the question of what systemd was running /before/, which was presumably what was giving rise to 169.254.x.y addresses. And, while I can add an innocuous 169.254.0.0 route to a system merely by installing ifupdown and avahi-autoipd, that route looks like the second line here: default via 192.168.1.1 dev enp2s2 onlink 169.254.0.0/16 dev enp2s2 scope link metric 1000 192.168.1.0/24 dev enp2s2 proto kernel scope link src 192.168.1.10 and not like the OP's (ie Geert's): 169.254.0.0/16 dev ovs-system scope link src 169.254.201.7 metric 1004 (which has been grepped out of its context). Cheers, David.
[toc] | [prev] | [next] | [standalone]
| From | Jeffrey Walton <noloader@gmail.com> |
|---|---|
| Date | 2023-02-22 20:10 +0100 |
| Subject | Re: Remove route '169.254.0.0/16 dev ovs-system' |
| Message-ID | <G22F3-7L0f-9@gated-at.bofh.it> |
| In reply to | #255294 |
On Wed, Feb 22, 2023 at 1:43 PM David Wright <deblis@lionunicorn.co.uk> 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 > > <c.brinkhaus@t-online.de> wrote: > > > [...] > > > > But backing up... I suspect there's something wrong with your static > > > > ip address assignment. The address is already taken, the netmask is > > > > wrong, or the gateway is wrong. > > > > > > > > Looking back through this thread, I did not see where you showed your > > > > static ip configuration. Maybe you should start with that. If it is > > > > bad, then the APIPA is just a symptom of the [static ip address] > > > > problem. > > > > > > This is the systemd-networkd configuration: > > > > > > [Match] > > > Name=w* > > > > > > [Network] > > > DHCP=no > > > Address=192.168.0.62/24 > > > Gateway=192.168.0.32 > > > DNS=127.0.0.1 > > > > > > I have unbound as a DNS listening at localhost. But with > > > DNS=192.168.0.32 the behaviour has been similar. > > > > > > I have not yet checked the address assignment using systemd-networkd. > > > For doing so I have to reinstall some packages. > > > > I don't know what the Match section does. I am suspicious of it. > > Oh, Match is great. For a typical, simple PC or laptop, you no longer > have to worry about whether your wifi is called wlan0 (kernel, and > iwd), wlo0, wlp365s7 (onboard/slot/path), or wlxf1dd1efadd1e (USB), > it'll get matched nonetheless. Ditto for e* and ethernet. 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
[toc] | [prev] | [next] | [standalone]
| From | Greg Wooledge <greg@wooledge.org> |
|---|---|
| Date | 2023-02-22 20:50 +0100 |
| Subject | Re: Remove route '169.254.0.0/16 dev ovs-system' |
| Message-ID | <G23hL-7LcV-9@gated-at.bofh.it> |
| In reply to | #255297 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Darac Marjal <mailinglist@darac.org.uk> |
|---|---|
| Date | 2023-02-22 21:10 +0100 |
| Subject | Re: Remove route '169.254.0.0/16 dev ovs-system' |
| Message-ID | <G23B7-7Lzp-15@gated-at.bofh.it> |
| In reply to | #255298 |
[Multipart message — attachments visible in raw view] — view raw
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
[toc] | [prev] | [next] | [standalone]
| From | Max Nikulin <manikulin@gmail.com> |
|---|---|
| Date | 2023-02-22 16:30 +0100 |
| Subject | Re: Remove route '169.254.0.0/16 dev ovs-system' |
| Message-ID | <G1Ze9-7IMf-15@gated-at.bofh.it> |
| In reply to | #255251 |
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.
[toc] | [prev] | [next] | [standalone]
Page 1 of 3 [1] 2 3 Next page →
Back to top | Article view | linux.debian.user
csiph-web