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

Daniel Reichelt debian at nachtgeist.net
Fri May 5 01:21:45 UTC 2017


Hi folks,

here are some more insights into this mystery:

My "victim" box:

- kvm-guest: jessie, task-xfce-desktop, sysvinit instead of systemd
- running with -net nic,model=rtl8139 -net tap
- connected to br0 of the kvm host which also contains the host's eth0
- the guest's /etc/network/interfaces or NM-config were left unchanged
after jessie-netinstall


In the guest, I did:

# touch /etc/.legacy-bootordering

and tweaked /etc/init.d/rc to display `ip addr list` and a debug login
shell after the execution of every single init script. Now, after
/etc/rcS.d/S03udev got executed, udev modprobe'd 8139too/8139cp for the
virtual Realtec nic.

What *really* surprised me: The output of `ip addr list` after S03udev
finished showed different link states across different boot processes.
AFAICT the Realtek's link state after modprobing is determined by fair
dice roll. I couldn't infer any relation between the link state after
modprobing and

- a freshly invoked kvm guest
- shutdown -r from within the guest
- echo b >/proc/sysrq-trigger from within the guest
- "system_reset" sent to the qemu_system-x86_64 process's control socket

- the link state prior to any of these four variants to reboot



As a consequence I could observe:

- When the link state was DOWN after modprobing, of course no v6 SLAAC
happened and NM configured eth0 just fine with both v4 and v6.

- When the link state was UP after modprobing, SLAAC happened which
triggered NM's "undesired behavior" to "connection-assume" eth0.
(This case then easily becomes a race-condition with concurrent
execution of the init scripts.)



Judging whether this is an error in this specific driver or in the Linux
networking layer goes way over my head. At the very least I can say that
I'm completely baffled by this observation.



Cheers

Daniel

-------------- 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/20170505/14596418/attachment.sig>


More information about the Pkg-utopia-maintainers mailing list