VirtualBox

Opened 14 years ago

Closed 9 years ago

Last modified 8 years ago

#5254 closed defect (fixed)

Host-only networking stops working

Reported by: henrik242 Owned by:
Component: network/hostif Version: VirtualBox 3.0.8
Keywords: Cc:
Guest type: Linux Host type: Mac OS X

Description (last modified by vasily Levchenko)

I use two network interfaces: one NAT and one Host-only adapter. The NAT interface works great all the time. The host-only interface, however, usually works as it should for a while after boot, then it becomes extremely slow and/or unresponsive. All adapters (Intel and PCnet) are affected.

A VM reboot might help, but sometimes it must be shut down completely.

This is a Mac OSX 10.6 host with a Debian testing guest (kernel 2.6.30-1).

A similar problem is discussed in the VirtualBox forum, and tickets #1256 and #4870 might be related.

Attachments (1)

VBox.log (38.7 KB ) - added by henrik242 14 years ago.

Download all attachments as: .zip

Change History (24)

by henrik242, 14 years ago

Attachment: VBox.log added

comment:1 by henrik242, 14 years ago

Also, I cannot find anything interesting in the host and guest log files (/var/log/*).

comment:2 by henrik242, 14 years ago

It happened again, appr. 15:01. There were messages in /var/log/messages on the guest a couple of minutes before that might be related:

Nov  3 11:15:51 hnrk-vbox kernel: [  274.472558] device-mapper: uevent: version 1.0.3
Nov  3 11:15:51 hnrk-vbox kernel: [  274.520621] device-mapper: ioctl: 4.14.0-ioctl (2008-04-23) initialised: dm-devel@redhat.com
Nov  3 11:15:51 hnrk-vbox kernel: [  279.700089] eth1: link up, 100Mbps, full-duplex
Nov  3 11:15:51 hnrk-vbox kernel: [  280.966722] eth0: link up, 100Mbps, full-duplex
Nov  3 11:16:26 hnrk-vbox lpd[3801]: restarted
Nov  3 13:25:44 hnrk-vbox kernel: [ 8090.060998] eth1: link down
Nov  3 13:25:44 hnrk-vbox kernel: [ 8091.003071] eth0: link down
Nov  3 13:25:49 hnrk-vbox kernel: [ 8096.002226] eth1: link up, 100Mbps, full-duplex
Nov  3 13:25:50 hnrk-vbox kernel: [ 8097.003697] eth0: link up, 100Mbps, full-duplex
Nov  3 13:39:57 hnrk-vbox kernel: [ 8943.555340] process `sysctl' is using deprecated sysctl (syscall) net.ipv6.neigh.default.retrans_time; Use net.ipv6.neigh.default.retrans_time_ms instead.
Nov  3 14:44:15 hnrk-vbox kernel: [12801.528512] hrtimer: interrupt too slow, forcing clock min delta to 20576772 ns

Anyway, I started pinged the Host-only networking gateway (ping 192.168.56.1) from the guest after the network stopped working. The packages wouldn't go through the first 10-20 seconds, but then suddenly the network was OK again. At least I have a workaround.

Here's the network configuration, by the way:

eth0      Link encap:Ethernet  HWaddr 08:00:27:eb:81:dc  
          inet addr:10.0.2.15  Bcast:10.0.2.255  Mask:255.255.255.0
          inet6 addr: fe80::a00:27ff:feeb:81dc/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:486 errors:0 dropped:0 overruns:0 frame:0
          TX packets:512 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:511179 (499.1 KiB)  TX bytes:46503 (45.4 KiB)
          Interrupt:19 Base address:0xd020 

eth1      Link encap:Ethernet  HWaddr 08:00:27:6a:f2:2e  
          inet addr:192.168.56.3  Bcast:192.168.56.255  Mask:255.255.255.0
          inet6 addr: fe80::a00:27ff:fe6a:f22e/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:53544 errors:321 dropped:0 overruns:0 frame:0
          TX packets:7647 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:73582593 (70.1 MiB)  TX bytes:1941106 (1.8 MiB)
          Interrupt:16 Base address:0xd060 

comment:3 by Licho, 14 years ago

I'm having completely same problem since 2.0 series of virtual box. With different host machines, different guest machine and different network setups (using tun vs using vbox own interface in 3.0). Its always same.

Replicated this in 3.0.10. - ubuntu host, w2k3 guest.

Under heavy load it just stops transmitting data between host and guest, sometimes virtual adapter is completely frozen and you cannot even view its details in guest OS.

Thanks for your tip about pinging gateway, after VRDP to guest machine and pinging gateway adapter started up again!

comment:4 by Licho, 14 years ago

Update: tested it more times, ping gateway trick not always work. Eventually you have to reboot guest machine :(

This bug drives me crazy for ages..

Several reboots/day to keep it online..

comment:5 by Licho, 14 years ago

The issue is strongly related to load. Normal low traffic wont break it.

But game lobby server makes it break every few hours. (100+ TCP connections each of them uploads some 300kb on init + high flux/random disconnects of players).

comment:6 by Licho, 14 years ago

I did several test on my VM suffering from same bug (host ubuntu, guest w2k3).

Opening VRDP often fixes the bug.. not the "ping gateway", but just the act of opening VRDP.

Strange..

comment:7 by henrik242, 14 years ago

I just got this problem again, this time with a CentOS 5.2 guest on a MacOSX 10.6.2 host with VirtualBox 3.1. I can still wake the connection by pinging the host-only gateway from within the guest.

comment:8 by Licho, 14 years ago

Are you sure its pinging and not just connecting to VRDP? In my cases connecting to VRDP fixed it, not the ping gate from guest.

comment:9 by henrik242, 14 years ago

I don't use VRDP at all...

comment:10 by Licho, 14 years ago

I thought that virtio-net solves this problem but it only reduces frequency.. (to about 1x per day on my machine - from 4x per day).

comment:11 by henrik242, 14 years ago

I just noticed that the gateway ping behaves weirdly. It seems to have a 30-second cycle three times before it finally settles to work again:

PING 192.168.56.1 (192.168.56.1) 56(84) bytes of data.
64 bytes from 192.168.56.1: icmp_seq=1 ttl=64 time=28216 ms
64 bytes from 192.168.56.1: icmp_seq=2 ttl=64 time=27207 ms
64 bytes from 192.168.56.1: icmp_seq=3 ttl=64 time=26200 ms
64 bytes from 192.168.56.1: icmp_seq=4 ttl=64 time=25192 ms
64 bytes from 192.168.56.1: icmp_seq=5 ttl=64 time=24183 ms
64 bytes from 192.168.56.1: icmp_seq=6 ttl=64 time=23174 ms
64 bytes from 192.168.56.1: icmp_seq=7 ttl=64 time=22174 ms
64 bytes from 192.168.56.1: icmp_seq=8 ttl=64 time=21174 ms
64 bytes from 192.168.56.1: icmp_seq=9 ttl=64 time=20174 ms
64 bytes from 192.168.56.1: icmp_seq=10 ttl=64 time=19173 ms
64 bytes from 192.168.56.1: icmp_seq=11 ttl=64 time=18174 ms
64 bytes from 192.168.56.1: icmp_seq=12 ttl=64 time=17174 ms
64 bytes from 192.168.56.1: icmp_seq=13 ttl=64 time=16174 ms
64 bytes from 192.168.56.1: icmp_seq=14 ttl=64 time=15174 ms
64 bytes from 192.168.56.1: icmp_seq=15 ttl=64 time=14174 ms
64 bytes from 192.168.56.1: icmp_seq=16 ttl=64 time=13174 ms
64 bytes from 192.168.56.1: icmp_seq=17 ttl=64 time=12173 ms
64 bytes from 192.168.56.1: icmp_seq=18 ttl=64 time=11174 ms
64 bytes from 192.168.56.1: icmp_seq=19 ttl=64 time=10174 ms
64 bytes from 192.168.56.1: icmp_seq=20 ttl=64 time=9174 ms
64 bytes from 192.168.56.1: icmp_seq=21 ttl=64 time=8173 ms
64 bytes from 192.168.56.1: icmp_seq=22 ttl=64 time=7174 ms
64 bytes from 192.168.56.1: icmp_seq=23 ttl=64 time=6174 ms
64 bytes from 192.168.56.1: icmp_seq=24 ttl=64 time=5174 ms
64 bytes from 192.168.56.1: icmp_seq=25 ttl=64 time=4174 ms
64 bytes from 192.168.56.1: icmp_seq=26 ttl=64 time=3174 ms
64 bytes from 192.168.56.1: icmp_seq=27 ttl=64 time=2174 ms
64 bytes from 192.168.56.1: icmp_seq=28 ttl=64 time=1174 ms
64 bytes from 192.168.56.1: icmp_seq=29 ttl=64 time=172 ms
64 bytes from 192.168.56.1: icmp_seq=30 ttl=64 time=30034 ms
64 bytes from 192.168.56.1: icmp_seq=31 ttl=64 time=29035 ms
64 bytes from 192.168.56.1: icmp_seq=32 ttl=64 time=28034 ms
64 bytes from 192.168.56.1: icmp_seq=33 ttl=64 time=27035 ms
64 bytes from 192.168.56.1: icmp_seq=34 ttl=64 time=26034 ms
64 bytes from 192.168.56.1: icmp_seq=35 ttl=64 time=25035 ms
64 bytes from 192.168.56.1: icmp_seq=36 ttl=64 time=24034 ms
64 bytes from 192.168.56.1: icmp_seq=37 ttl=64 time=23034 ms
64 bytes from 192.168.56.1: icmp_seq=38 ttl=64 time=22034 ms
64 bytes from 192.168.56.1: icmp_seq=39 ttl=64 time=21033 ms
64 bytes from 192.168.56.1: icmp_seq=40 ttl=64 time=20023 ms
64 bytes from 192.168.56.1: icmp_seq=41 ttl=64 time=19022 ms
64 bytes from 192.168.56.1: icmp_seq=42 ttl=64 time=18023 ms
64 bytes from 192.168.56.1: icmp_seq=43 ttl=64 time=17022 ms
64 bytes from 192.168.56.1: icmp_seq=44 ttl=64 time=16023 ms
64 bytes from 192.168.56.1: icmp_seq=45 ttl=64 time=15021 ms
64 bytes from 192.168.56.1: icmp_seq=46 ttl=64 time=14022 ms
64 bytes from 192.168.56.1: icmp_seq=47 ttl=64 time=13023 ms
64 bytes from 192.168.56.1: icmp_seq=48 ttl=64 time=12022 ms
64 bytes from 192.168.56.1: icmp_seq=49 ttl=64 time=11022 ms
64 bytes from 192.168.56.1: icmp_seq=50 ttl=64 time=10020 ms
64 bytes from 192.168.56.1: icmp_seq=51 ttl=64 time=9018 ms
64 bytes from 192.168.56.1: icmp_seq=52 ttl=64 time=8018 ms
64 bytes from 192.168.56.1: icmp_seq=53 ttl=64 time=7019 ms
64 bytes from 192.168.56.1: icmp_seq=54 ttl=64 time=6018 ms
64 bytes from 192.168.56.1: icmp_seq=55 ttl=64 time=5008 ms
64 bytes from 192.168.56.1: icmp_seq=56 ttl=64 time=4000 ms
64 bytes from 192.168.56.1: icmp_seq=57 ttl=64 time=2991 ms
64 bytes from 192.168.56.1: icmp_seq=58 ttl=64 time=1991 ms
64 bytes from 192.168.56.1: icmp_seq=59 ttl=64 time=990 ms
64 bytes from 192.168.56.1: icmp_seq=60 ttl=64 time=30851 ms
64 bytes from 192.168.56.1: icmp_seq=61 ttl=64 time=29850 ms
64 bytes from 192.168.56.1: icmp_seq=62 ttl=64 time=28851 ms
64 bytes from 192.168.56.1: icmp_seq=63 ttl=64 time=27850 ms
64 bytes from 192.168.56.1: icmp_seq=64 ttl=64 time=26850 ms
64 bytes from 192.168.56.1: icmp_seq=65 ttl=64 time=25850 ms
64 bytes from 192.168.56.1: icmp_seq=66 ttl=64 time=24851 ms
64 bytes from 192.168.56.1: icmp_seq=67 ttl=64 time=23850 ms
64 bytes from 192.168.56.1: icmp_seq=68 ttl=64 time=22850 ms
64 bytes from 192.168.56.1: icmp_seq=69 ttl=64 time=21850 ms
64 bytes from 192.168.56.1: icmp_seq=70 ttl=64 time=20851 ms
64 bytes from 192.168.56.1: icmp_seq=71 ttl=64 time=19851 ms
64 bytes from 192.168.56.1: icmp_seq=72 ttl=64 time=18850 ms
64 bytes from 192.168.56.1: icmp_seq=73 ttl=64 time=17851 ms
64 bytes from 192.168.56.1: icmp_seq=74 ttl=64 time=16850 ms
64 bytes from 192.168.56.1: icmp_seq=75 ttl=64 time=15851 ms
64 bytes from 192.168.56.1: icmp_seq=76 ttl=64 time=14851 ms
64 bytes from 192.168.56.1: icmp_seq=77 ttl=64 time=13851 ms
64 bytes from 192.168.56.1: icmp_seq=78 ttl=64 time=12849 ms
64 bytes from 192.168.56.1: icmp_seq=79 ttl=64 time=11840 ms
64 bytes from 192.168.56.1: icmp_seq=80 ttl=64 time=10832 ms
64 bytes from 192.168.56.1: icmp_seq=81 ttl=64 time=9823 ms
64 bytes from 192.168.56.1: icmp_seq=82 ttl=64 time=8823 ms
64 bytes from 192.168.56.1: icmp_seq=83 ttl=64 time=7823 ms
64 bytes from 192.168.56.1: icmp_seq=84 ttl=64 time=6822 ms
64 bytes from 192.168.56.1: icmp_seq=85 ttl=64 time=5823 ms
64 bytes from 192.168.56.1: icmp_seq=86 ttl=64 time=4822 ms
64 bytes from 192.168.56.1: icmp_seq=87 ttl=64 time=3823 ms
64 bytes from 192.168.56.1: icmp_seq=88 ttl=64 time=2823 ms
64 bytes from 192.168.56.1: icmp_seq=89 ttl=64 time=1823 ms
64 bytes from 192.168.56.1: icmp_seq=90 ttl=64 time=823 ms
From 192.168.56.3 icmp_seq=117 Destination Host Unreachable
From 192.168.56.3 icmp_seq=118 Destination Host Unreachable
From 192.168.56.3 icmp_seq=119 Destination Host Unreachable
64 bytes from 192.168.56.1: icmp_seq=91 ttl=64 time=30688 ms
64 bytes from 192.168.56.1: icmp_seq=92 ttl=64 time=29688 ms
64 bytes from 192.168.56.1: icmp_seq=93 ttl=64 time=28688 ms
64 bytes from 192.168.56.1: icmp_seq=94 ttl=64 time=27688 ms
64 bytes from 192.168.56.1: icmp_seq=95 ttl=64 time=26688 ms
64 bytes from 192.168.56.1: icmp_seq=96 ttl=64 time=25688 ms
64 bytes from 192.168.56.1: icmp_seq=97 ttl=64 time=24688 ms
64 bytes from 192.168.56.1: icmp_seq=98 ttl=64 time=23688 ms
64 bytes from 192.168.56.1: icmp_seq=99 ttl=64 time=22688 ms
64 bytes from 192.168.56.1: icmp_seq=100 ttl=64 time=21688 ms
64 bytes from 192.168.56.1: icmp_seq=101 ttl=64 time=20688 ms
64 bytes from 192.168.56.1: icmp_seq=102 ttl=64 time=19689 ms
64 bytes from 192.168.56.1: icmp_seq=103 ttl=64 time=18687 ms
64 bytes from 192.168.56.1: icmp_seq=104 ttl=64 time=17688 ms
64 bytes from 192.168.56.1: icmp_seq=105 ttl=64 time=16686 ms
64 bytes from 192.168.56.1: icmp_seq=106 ttl=64 time=15677 ms
64 bytes from 192.168.56.1: icmp_seq=107 ttl=64 time=14670 ms
64 bytes from 192.168.56.1: icmp_seq=108 ttl=64 time=13661 ms
64 bytes from 192.168.56.1: icmp_seq=109 ttl=64 time=12653 ms
64 bytes from 192.168.56.1: icmp_seq=110 ttl=64 time=11641 ms
64 bytes from 192.168.56.1: icmp_seq=111 ttl=64 time=10634 ms
64 bytes from 192.168.56.1: icmp_seq=112 ttl=64 time=9625 ms
64 bytes from 192.168.56.1: icmp_seq=113 ttl=64 time=8618 ms
64 bytes from 192.168.56.1: icmp_seq=114 ttl=64 time=7610 ms
64 bytes from 192.168.56.1: icmp_seq=115 ttl=64 time=6601 ms
64 bytes from 192.168.56.1: icmp_seq=116 ttl=64 time=5594 ms
64 bytes from 192.168.56.1: icmp_seq=120 ttl=64 time=1570 ms
64 bytes from 192.168.56.1: icmp_seq=121 ttl=64 time=562 ms
64 bytes from 192.168.56.1: icmp_seq=122 ttl=64 time=0.684 ms
64 bytes from 192.168.56.1: icmp_seq=123 ttl=64 time=0.345 ms
64 bytes from 192.168.56.1: icmp_seq=124 ttl=64 time=0.396 ms
64 bytes from 192.168.56.1: icmp_seq=125 ttl=64 time=0.542 ms
64 bytes from 192.168.56.1: icmp_seq=126 ttl=64 time=0.482 ms
64 bytes from 192.168.56.1: icmp_seq=127 ttl=64 time=0.559 ms
64 bytes from 192.168.56.1: icmp_seq=128 ttl=64 time=0.613 ms
64 bytes from 192.168.56.1: icmp_seq=129 ttl=64 time=0.550 ms
64 bytes from 192.168.56.1: icmp_seq=130 ttl=64 time=0.576 ms

comment:12 by henrik242, 14 years ago

I just realized that the forum topic link in the issue description somehow lacks a question sign. Here it is again: http://forum.virtualbox.org/viewtopic.php?f=6&t=19457&start=30&sid=d2fa7b3d50bc97a49f596a0df94743ce

comment:13 by Andreas Böckler, 14 years ago

#5871 might be related to it.

comment:14 by jwilliams108, 14 years ago

I am experiencing a similar problem, but it doesn't seem to correlate to load. I also can't solve it by pinging or opening a VRDP connection, but instead need to save the machine state and start it again. Strangely, this problem only shows up on 10.6.3 Server, the same VM runs find with VirtualBox 3.1.6 on 10.6.3 non-server.

comment:15 by Miro Dietiker, 13 years ago

This ist still present in VirtualBox 3.2.12. (Using Mac OS X 10.5.8) I also can't find a load relation.

This bug really makes the internal network useless... What a pity for offline development between host / guest...

comment:16 by Frank Mehnert, 13 years ago

Component: networknetwork/hostif

comment:17 by Frank Mehnert, 13 years ago

Resolution: fixed
Status: newclosed

There were relevant fixes in VBox 4.0.6. Please reopen if still relevant.

comment:18 by vagrant77, 12 years ago

I'm not sure this is fixed, I have a VM I've distributed to a few people this week and they're reporting the network freezing up. Things will start fine but after some time, shells through the forwarded port will freeze and HTTP connections to the host only network will hang. I think there's still a bug here. The configuration for all of them is

Mac OS 10.7 host

Ubuntu 10.10 guest with eth0 a NAT and eth1 hostonly

Vbox 4.1.12

Last edited 12 years ago by vagrant77 (previous) (diff)

in reply to:  18 comment:19 by vasily Levchenko, 12 years ago

Description: modified (diff)

Replying to vagrant77:

Vbox 4.1.12

Please try with 4.1.16 and if the issue still persists please attach log file.

comment:20 by ayotzinapa, 9 years ago

Resolution: fixed
Status: closedreopened

I'm having the same issue with VirtualBox 5.0.2. I followed the instructions in [this tutoria]https://forums.virtualbox.org/viewtopic.php?f=24&t=42385l to assign a static IP to my guest. It was working for a while, then it suddenly stopped and no amount of restarting either the host or guest will bring it back.

This is occurring on a Mac OS X 10.10.5 host with an Ubuntu 14.04.3 guest.

I was able to resolve the issue by choosing a different IP for the nat network - changing the host network config (Preferences > Network > Host Only Networks > vboxnet0) from 192.168.56.1 to 192.168.57.1 and the guest's IP from 192.168.56.10 to 192.168.57.10 I was able to reconnect.

It turns out the WIFI access point that I was connected to was using the 192.168.56.255 subnet.

Last edited 9 years ago by ayotzinapa (previous) (diff)

in reply to:  20 comment:21 by Valery Ushakov, 9 years ago

Resolution: fixed
Status: reopenedclosed

Replying to ayotzinapa:

I was able to resolve the issue by choosing a different IP for the nat network - changing the host network config (Preferences > Network > Host Only Networks > vboxnet0) from 192.168.56.1 to 192.168.57.1 and the guest's IP from 192.168.56.10 to 192.168.57.10 I was able to reconnect.

It turns out the WIFI access point that I was connected to was using the 192.168.56.255 subnet.

Configuration problem, not a bug.

comment:22 by AAAAdrianLi, 8 years ago

I have the same issue. I am using vagrant 1.8.1 and VirtualBox 5.0.14.

I created a VM using "hashicorp/precise64" vagrant box and what I was trying to do is to connect to a large number of VPN endpoints one by one using openvpn, and for each VPN, run various tests (like http, dns, traceroute, etc.) for a list of URLs concurrently (500 URLs).

NAT network would stop working after finishing some endpoints. Tried everything but only reboot could bring up the network.

I have also tried using ubuntu/trusty64 box and different NIC, all have the same problem.

in reply to:  22 comment:23 by Valery Ushakov, 8 years ago

Replying to AAAAdrianLi:

I have the same issue.

This is not same issue as this bug is about host-only network and your problem is with the NAT Network. Please, file a separate bug and provide as much detail as possible. When the NAT network is stuck, try to get a core dump of the VBoxNetNAT process.

Note: See TracTickets for help on using tickets.

© 2023 Oracle
ContactPrivacy policyTerms of Use