Network disconnected after waking up from pause

[VBoxer2]

Hi,

my setup is an up-to-date Debian Testing 64 bit VM on an OS X host. I'm accessing the internet from the VM by the Intel 1000/MT Pro NIC, eth0 interface through NAT on the host.
For longer time now I've had issues with the network connection after waking the VM up from a pause. If I remember correctly it started with Virtualbox 5.1.
From the reboot until I pause the VM everything is fine. After waking up the VM and running it a few seconds the Network Manager in the tray shows me that the VM disconnected. Until guest additions 5.1.8 and kernel 4.6.0.1 I could reconnect by the Network Manager. Now with kernel 4.8.0.2 and guest additions 5.1.12 not even this works anymore. Sudo'ing and running 'ifconfig eth0 down && ifconfig eth0 10.0.2.15 up' brings back the connection but I can't browse anymore.
Going back to kernel 4.6.0.1 with newly compiled guest additions 5.1.12 ends up the same now. Below you find the output of ifconfig eth0 and dmesg | grep -i eth0.
I don't have this issue with Fedora 24 (kernel 4.8.15) and Linux Mint 18 (kernel 4.4.0.57) and guest additions 5.1.12.
To me the cause is either in Debian or Virtualbox. Do you have any ideas how to track this issue down and eventually solve it?

Thank you in advance.

Before pause:
The output of ifconfig eth0 is:
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 10.0.2.15 netmask 255.255.255.0 broadcast 10.0.2.255
inet6 fe80::a00fefb:31b6 prefixlen 64 scopeid 0x20<link>
ether 08:00:27:fb:31:b6 txqueuelen 1000 (Ethernet)
RX packets 195 bytes 20084 (19.6 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 220 bytes 20641 (20.1 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

The output of dmesg | grep -i eth0 is:
[ 2.058992] e1000 0000:00:03.0 eth0: (PCI:33MHz:32-bit) 08:00:27:fb:31:b6
[ 2.059000] e1000 0000:00:03.0 eth0: Intel(R) PRO/1000 Network Connection
[ 16.911866] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[ 16.916570] e1000: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX
[ 16.917343] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

After waking up from pause and disconnected:
The output of ifconfig eth0 is:
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet6 fe80::a00fefb:31b6 prefixlen 64 scopeid 0x20<link>
ether 08:00:27:fb:31:b6 txqueuelen 1000 (Ethernet)
RX packets 236 bytes 24346 (23.7 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 277 bytes 26051 (25.4 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

The output of dmesg | grep -i eth0 is:
[ 2.058992] e1000 0000:00:03.0 eth0: (PCI:33MHz:32-bit) 08:00:27:fb:31:b6
[ 2.059000] e1000 0000:00:03.0 eth0: Intel(R) PRO/1000 Network Connection
[ 16.911866] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[ 16.916570] e1000: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX
[ 16.917343] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[ 237.346780] e1000: eth0 NIC Link is Down
[ 239.897346] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[ 241.334376] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[ 243.361374] e1000: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX
[ 243.362635] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

[Perryg]

I don't have this issue with Fedora 24 (kernel 4.8.15) and Linux Mint 18 (kernel 4.4.0.57) and guest additions 5.1.12.
To me the cause is either in Debian or Virtualbox. Do you have any ideas how to track this issue down and eventually solve it?

Seems to me you have eliminated VirtualBox with your statement above. Does running dhclient in the debian guest when this occurs rebind the guests network to a valid IP?

[VBoxer2]

No, running dhclient doesn't rebind it.

dhclient -v returns:
No broadcast interfaces found - exiting.

[Perryg]

I tried my Debian SID which is at 4.8.0-1-amd64 and pausing the guest, waiting 10 minutes, and un-pausing it does not break the network for me. So unless there is an issue with 4.8.0-2 in testing I don't have an idea at this point. How exactly are you pausing the guest? Is it with the machine tab or are you actually hibernating the host?

[VBoxer2]

I click the Close button of the VM window and when I'm asked how to proceed I choose the option to pause the VM.
There's no need to wait for 10 minutes - it happens also when I restart the VM right after pausing it.

[Perryg]

I don't seem to have that option when selecting to red X on the title bar. Maybe it is host related. See Below:

close_VM_choices.png (20.44 KiB) Viewed 3647 times

[VBoxer2]

Sorry, it was my bad to translate it wrong. I choose "Save the machine state".

[Perryg]

That does make a difference. I would see if sysctrl restarting the network helps. I really don't like this whole systemd thing. Never had these issues with init.
Note: It does still works for me with saved state but I build my own version of VirtualBox without some things that I don't use and that could make a huge difference.

[VBoxer2]

Thank you for investigating and suggesting. I followed the advice and tried to make use of sysctrl.
Running

Code: Select all

systemctl restart networking.service

and

Code: Select all

/etc/init.d/networking stop && /etc/init.d/networking start

fail. I also ran journalctl and grepped for eth0, e1000 and network, but there is nothing obvious to see. Could there be any other source of information on my system which told me what causes the issue?

[Perryg]

I feel your pain, but that is what happens when running pre-released OSes. Other than the normal investigation on the guest I really wouldn't know what to tell you. Do you have an older kernel you could test and see if that has a different result? I did a quick search and found others that have this kind of issue on metal.

[Perryg]

I do have one more suggestion to see what happens. When I am investigating an issue like this with a single guest, I install a test of the same OS and see if it behaves the same. This usually gives me an indication of where the first one may have broken.

[VBoxer2]

Do you have an older kernel you could test and see if that has a different result?

I already rolled back and checked with older kernels. As long as the GA 5.1.12 are not involved it's fine.

I did a quick search and found others that have this kind of issue on metal.

I searched and found nothing where it happens on a bare metal machine. Could you please provide the link? Thank you.

[Perryg]

As long as the GA 5.1.12 are not involved it's fine.

Really? Try purging those and install this one http://download.virtualbox.org/virtualb ... 4.3.30.iso . If that works then you should post a ticket at bugtracker as a possible regression. Of course it may be that any GAs trigger this and in which case the test would tell you the same thing which should be posted as well. I suspect this has to do with the host side code as I can not reproduce your error at all on Linux.

[VBoxer2]

This seems indeed to be a regression. The error doesn't occur with VB 4.3.30 (host and GA), but is also in version 5.0.30.
I'll check whether the error occurs on a freshly installed Debian and report back.
Anyway, have a happy new year!

[VBoxer2]

I've set up a new instance and the error is gone, even with VB 5.1.12.