[Solved] VirtualBox 5.1.28 introduces intermittent network connectivity issues (timeouts, refusals)

[cbj4074]

UPDATE: Downgrading to 5.1.26 (without changing anything else on the system) solves the problem, unequivocally, so something in 5.1.28 causes the issue.

I upgraded to VirtualBox 5.1.28 as soon as it was advertised through the VBox Manager GUI, and the upgrade appears to have had adverse consequences for networking.

My host is Windows 7 x64, with two NICs configured in VirtualBox: 1) NAT with Intel PRO/1000 MT Desktop; 2) Host-only with the same adapter. ifconfig output in the guest is as follows:

Code: Select all

# ifconfig
enp0s3    Link encap:Ethernet  HWaddr 08:00:27:a8:df:8b
          inet addr:10.0.2.15  Bcast:10.0.2.255  Mask:255.255.255.0
          inet6 addr: fe80::a00:27ff:fea8:df8b/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1724 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1321 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:187315 (187.3 KB)  TX bytes:158633 (158.6 KB)

enp0s8    Link encap:Ethernet  HWaddr 08:00:27:28:f7:a4
          inet addr:192.168.10.10  Bcast:192.168.10.255  Mask:255.255.255.0
          inet6 addr: fe80::a00:27ff:fe28:f7a4/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:14317 errors:0 dropped:0 overruns:0 frame:0
          TX packets:9754 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:10176377 (10.1 MB)  TX bytes:4913975 (4.9 MB)

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:1438 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1438 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1
          RX bytes:513836 (513.8 KB)  TX bytes:513836 (513.8 KB)

Speaking broadly, I am now seeing huge delays in networking functions. For example, if I make an HTTP request to a service running on the VM, it takes about 30 seconds for the request to timeout.

What's most peculiar is that if I make the same request again, immediately thereafter, the response comes back normally (within a second or two). So, it seems that once a connection is established, subsequent connections can be established successfully, until some period of time elapses (I have no idea how long, but it seems to be around 3 minutes). Maybe it's a DNS-related problem?

I'm seeing the same behavior with all services, not just HTTP. Similarly affected are SSH, native database protocols (PostgreSQL, MySQL, etc.), and just about anything I've tried.

It's interesting that once I'm connected, I'm able to maintain an active SSH connection indefinitely, despite the networking problems.

For example, at the moment, I'm connected to the VM via SSH, and have been for several hours. Yet, I can't even ping the VM currently (nor can I connect to any other services). So, it's not as though networking is "broken" completely.

The ping output looks like this (three attempts, several minutes apart):

Code: Select all

Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation.  All rights reserved.

U:\>ping 192.168.10.10

Pinging 192.168.10.10 with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 192.168.10.10:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

U:\>ping 192.168.10.10

Pinging 192.168.10.10 with 32 bytes of data:
Reply from 192.168.10.9: Destination host unreachable.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 192.168.10.10:
    Packets: Sent = 4, Received = 1, Lost = 3 (75% loss),

U:\>ping 192.168.10.10

Pinging 192.168.10.10 with 32 bytes of data:
Reply from 192.168.10.10: bytes=32 time<1ms TTL=64
Reply from 192.168.10.10: bytes=32 time<1ms TTL=64
Reply from 192.168.10.10: bytes=32 time<1ms TTL=64
Reply from 192.168.10.10: bytes=32 time<1ms TTL=64

Ping statistics for 192.168.10.10:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 0ms, Average = 0ms

(Hmm, quite odd that 192.168.10.9 appears in the ping out from the second attempt when the target is 192.168.10.10...)

I notice that there are several network-related changes in 5.1.28, and I can't help but wonder if one of them is causing the observed behavior.

Has anybody else noticed this?

I'll work to collect more information and to create a reproducible test-case. I realize that, at this stage, my experience is purely anecdotal.

Thanks in advance!

[cbj4074]

I can confirm that v5.1.30 fixes whatever caused this issue.

[socratis]

Yours was one of the two posts that I was holding on to, until there was a clear pattern appearing. There was another poster that had mysteriously developed a delay of 30 sec during the printing of the 1st page (only) on a network printer. I thought that the 30 sec was really strange for both cases, but there were not enough "data points" to make it evident.

Thanks for the feedback. Marking as [Solved].