#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 )
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)
Change History (24)
by , 15 years ago
comment:1 by , 15 years ago
comment:2 by , 15 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: [email protected] 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 , 15 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 , 15 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 , 15 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 , 15 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 , 15 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 , 15 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:10 by , 15 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 , 15 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 , 15 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:14 by , 15 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 , 14 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 , 14 years ago
| Component: | network → network/hostif |
|---|
comment:17 by , 14 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
There were relevant fixes in VBox 4.0.6. Please reopen if still relevant.
follow-up: 19 comment:18 by , 13 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
comment:19 by , 13 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.
follow-up: 21 comment:20 by , 9 years ago
| Resolution: | fixed |
|---|---|
| Status: | closed → reopened |
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.
comment:21 by , 9 years ago
| Resolution: | → fixed |
|---|---|
| Status: | reopened → closed |
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.
follow-up: 23 comment:22 by , 9 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.
comment:23 by , 9 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.
Also, I cannot find anything interesting in the host and guest log files (/var/log/*).