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
signature.asc
Description: OpenPGP digital signature
