[Pkg-utopia-maintainers] Bug#755202: network-manager: keeps creating and using new connection "eth0" that does not work

[Michael Biebl]

Talked to upstream about this problem.
Attached is the IRC log.

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
-------------- next part --------------
<mbiebl> dcbw: this bug report is a mess: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=755202
<mbiebl> do you have any idea what this could be about?
<dcbw> mbiebl: what creates eth0:avahi?
<dcbw> mbiebl: and why does it not just add the address as a secondary...
<dcbw> mbiebl: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=755202#136 looks like an accurate description of the problem
<dcbw> mbiebl: something is assigning an address to the interface before NM starts up (possibly the kernel with IPv6LL) and NM respects that configuration on boot
<dcbw> mbiebl: it will name that generated+assumed connection the same as the interface name, so I guess everyone on the bug isn't using systemd/udev network renaming becuase they all talk about 'eth0'
<mbiebl> dcbw: the new udev persistent network interface naming is opt-in in Debian
<mbiebl> eth0:avahi is a link-local fallback created by avahi-autopid
<mbiebl> if e.g. dhclient times out
<mbiebl> dcbw: but I have no idea really what's going on there
<dcbw> mbiebl: the question is, why is it using address labels and not just adding it to the interface, but that's not your problem
<dcbw> mbiebl: I think that #136 is the basic issue
<dcbw> mbiebl: the "eth0" things are in-memory connections generated from the existing interface state when NM starts, so that it doesn't disrupt the existing interface configuration
<dcbw> mbiebl: and it won't work, because it's link-local so you don't get anywhere
<mbiebl> apparently this is not debian specific
<mbiebl> but I wasn't able yet, to distill the exact reproducer
<dcbw> no, it's not debian specific
<dcbw> mbiebl: it will only occur if (a) something brings the interface up before NetworkManager starts, and (b) the kernel has had enough time to run DAD on the IPv6LL address that it adds because the interface is IFF_UP already
<dcbw> mbiebl: a reproducer would be something like
<dcbw> 1) stop NM
<dcbw> 2) ip addr flush all
<dcbw> 3) ifconfig eth0 down
<dcbw> 4) ifconfig eth0 up
<dcbw> 5) wait until the kernel has assigned an IPv6LL address
<dcbw> 6) start NetworkManager
<dcbw> and you'll see NM "assume" the connection on eth0 that is ipv4.method=disabled, ipv6.method=link-local
<dcbw> that's essentially intended but sub-optimal behavior, as a side-effect of NM attempting not to touch already configured interfacs
<mbiebl> so if the user has a valid connection config for eth0 this is not applied?
<dcbw> in the case of IPv6LL-only, it's less than helpful
<dcbw> mbiebl: existing interface configuration trumps *all*, because if the configuration already exists on the interface, something put it there, and NM tries not to interfere
<dcbw> mbiebl: int he case of IPv6LL, well, that is usually not intended by the user
<dcbw> so we probably do want to adjust NM behavior in the IPv6LL-only case
<mbiebl> same for an avahi created IPv4LL
<dcbw> well, that's intended because somebody installed the dhclient script or whatever
<dcbw> plus, avahi-autoipd is going do to die pretty soon, according to upstream
<dcbw> I have no idea why that avahi behavior is useful
<mbiebl> will that be folded into networkd?
<dcbw> there's already replacement code in networkd, and NM does IPv4LL itself too, and so does connman
<dcbw> so basically, since it's a network management daemon task and not really a standalone thing, I guess they decided it should be done in management daemons
<mbiebl> yeah, it was probably just useful for basic tools like ifupdown
<mbiebl> (it's hooked into it via if-up.d hooks and a dhclient hook)
<dcbw> mbiebl: for the IPv4LL side of things, if the user wants IPv4LL, then they can (a) create a config in NM for it that they can use when they want, and/or (b) we can explore ways to achieve whatever behavior they want within NM, like potential fallback to IPv4LL when DHCP fails or whatever
<dcbw> mbiebl: so two results from that thread; #1 NM's IPv6LL-only assume behavior should be changed, and #2 avahi-autoipd probably shouldn't be called from the hooks to add an address
<dcbw> at least when NM is being used...
<mbiebl> oh, I still have an avahi-autoipd suggests in the NM package 
<mbiebl> probably from old times...
<mbiebl> suggests don't pull in the package automatically thankfully
<dcbw> mbiebl: well, complicated
<dcbw> mbiebl: it's required currently for NM's IPv4LL behavior, but NM spawns it manually
<dcbw> mbiebl: we're going to remove that dependency soon thouh
<mbiebl> or, well, it actually still has code for IPv4LL using avahi
<dcbw> mbiebl: so you would still want avahi-autoipd, but you don't want the hooks running when NM is running
<dcbw> at least the ones that add addresses
<mbiebl> the if-up.d hooks (which are called by the NM dispatcher)
<mbiebl> only add routes
<mbiebl> it's the dhclient hook, which adds the avahi interface
<mbiebl> since we don't call the dhclient hook scripts
<mbiebl> this probably only happens if the user manages eth0 via ifupdown
<mbiebl> but also has managed=true
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-utopia-maintainers/attachments/20150331/991696e5/attachment.sig>