#13839 closed defect (fixed)
ethernet frequently disconnecting / reconnecting after upgrade to 4.3.22 => Fixed in SVN
Reported by: | Geof | Owned by: | |
---|---|---|---|
Component: | network/NAT | Version: | VirtualBox 4.3.22 |
Keywords: | network disconnecting | Cc: | |
Guest type: | Linux | Host type: | Windows |
Description
Here's part of my syslog (hopefully that helps). I had to rollback to my previous version of VirtualBox, 2.3.20 (problem went away).
Attachments (23)
Change History (153)
by , 10 years ago
Attachment: | syslog.tgz added |
---|
comment:1 by , 10 years ago
Same issue for me after upgrading to 4.3.22 this morning, same config (win 7 64 bits host and ubuntu 14.10 6A bits guest, using NAT).
Disconnections occur every 2-3 minutes.
by , 10 years ago
Attachment: | syslog.txt added |
---|
comment:2 by , 10 years ago
I second that this issue exists. I use NAT and both with virtio and with Intel 82545EM cards I can reproduce it.
Host: Win7 x64
Guest: openSUSE 13.2 x64 3.16.7-7-desktop
Here is a quick ping log:
64 bytes from test_srv (181.10.10.xx): icmp_seq=1 ttl=51 time=31.4 ms 64 bytes from test_srv (181.10.10.xx): icmp_seq=2 ttl=51 time=49.6 ms 64 bytes from test_srv (181.10.10.xx): icmp_seq=3 ttl=51 time=35.4 ms 64 bytes from test_srv (181.10.10.xx): icmp_seq=4 ttl=51 time=30.7 ms 64 bytes from test_srv (181.10.10.xx): icmp_seq=5 ttl=51 time=35.0 ms 64 bytes from test_srv (181.10.10.xx): icmp_seq=6 ttl=51 time=33.7 ms 64 bytes from test_srv (181.10.10.xx): icmp_seq=7 ttl=51 time=37.1 ms 64 bytes from test_srv (181.10.10.xx): icmp_seq=8 ttl=51 time=30.1 ms 64 bytes from test_srv (181.10.10.xx): icmp_seq=9 ttl=51 time=36.2 ms 64 bytes from test_srv (181.10.10.xx): icmp_seq=10 ttl=51 time=57.2 ms 64 bytes from test_srv (181.10.10.xx): icmp_seq=11 ttl=51 time=35.2 ms 64 bytes from test_srv (181.10.10.xx): icmp_seq=12 ttl=51 time=30.1 ms 64 bytes from test_srv (181.10.10.xx): icmp_seq=13 ttl=51 time=44.1 ms 64 bytes from test_srv (181.10.10.xx): icmp_seq=14 ttl=51 time=32.7 ms 64 bytes from test_srv (181.10.10.xx): icmp_seq=15 ttl=51 time=35.1 ms 64 bytes from test_srv (181.10.10.xx): icmp_seq=16 ttl=51 time=31.8 ms 64 bytes from test_srv (181.10.10.xx): icmp_seq=17 ttl=51 time=45.5 ms 64 bytes from test_srv (181.10.10.xx): icmp_seq=18 ttl=51 time=37.0 ms 64 bytes from test_srv (181.10.10.xx): icmp_seq=19 ttl=51 time=37.0 ms 64 bytes from test_srv (181.10.10.xx): icmp_seq=20 ttl=51 time=86.5 ms 64 bytes from test_srv (181.10.10.xx): icmp_seq=21 ttl=51 time=39.9 ms ping: sendmsg: Network is unreachable ping: sendmsg: Network is unreachable ping: sendmsg: Network is unreachable ping: sendmsg: Network is unreachable ping: sendmsg: Network is unreachable ping: sendmsg: Network is unreachable ping: sendmsg: Network is unreachable 64 bytes from test_srv (181.10.10.xx): icmp_seq=34 ttl=51 time=38.1 ms 64 bytes from test_srv (181.10.10.xx): icmp_seq=35 ttl=51 time=31.2 ms 64 bytes from test_srv (181.10.10.xx): icmp_seq=36 ttl=51 time=53.9 ms 64 bytes from test_srv (181.10.10.xx): icmp_seq=37 ttl=51 time=177 ms 64 bytes from test_srv (181.10.10.xx): icmp_seq=38 ttl=51 time=86.9 ms 64 bytes from test_srv (181.10.10.xx): icmp_seq=39 ttl=51 time=94.7 ms 64 bytes from test_srv (181.10.10.xx): icmp_seq=40 ttl=51 time=75.8 ms 64 bytes from test_srv (181.10.10.xx): icmp_seq=41 ttl=51 time=93.8 ms 64 bytes from test_srv (181.10.10.xx): icmp_seq=42 ttl=51 time=116 ms 64 bytes from test_srv (181.10.10.xx): icmp_seq=43 ttl=51 time=253 ms 64 bytes from test_srv (181.10.10.xx): icmp_seq=44 ttl=51 time=258 ms 64 bytes from test_srv (181.10.10.xx): icmp_seq=45 ttl=51 time=210 ms 64 bytes from test_srv (181.10.10.xx): icmp_seq=46 ttl=51 time=82.7 ms
This issue appeared after upgrading from .21 to .22.
follow-up: 8 comment:3 by , 10 years ago
A side issue: could you please fix the link to Windows downloads to be able to revert? Page https://www.virtualbox.org/wiki/Download_Old_Builds_4_3 which links to Win 4.3.20, has a broken link. Thank you!
comment:4 by , 10 years ago
Same issue with Win7 host and Win7 guest, also with XP guest and FreeBSD guest. Tickets 13838 and 13839 are probably duplicates.
comment:5 by , 10 years ago
I have the same problem: VirtualBox running on Windows 7 64bit, Linux Mint 64bit VM, unstable ethernet connection.
comment:6 by , 10 years ago
I have the same problem with Windows 7 64bit as host and CentOS 5.11 as guest using NAT.
comment:7 by , 10 years ago
Similar issue, win7-64b. nat networking.
It is manifesting as TCP RST to guest. Host normally closes the connection by FIN with the other endpoint.
comment:8 by , 10 years ago
Replying to bmn:
A side issue: could you please fix the link to Windows downloads to be able to revert? Page https://www.virtualbox.org/wiki/Download_Old_Builds_4_3 which links to Win 4.3.20, has a broken link. Thank you!
I found another build number there: VirtualBox-4.3.20-96997-Win.exe
comment:9 by , 10 years ago
Same issue here. Running Windows 7 64bit and after upgrade to VirtualBox 4.3.22, my network interface is constantly getting reset. This bug is quite annoying, since I'm being disconnected at least once every 10 minutes.
[ 3378.273244] e1000: enp0s3 NIC Link is Down
[ 3378.273372] e1000 0000:00:03.0 enp0s3: Reset adapter
[ 3384.350630] e1000: enp0s3 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX
Will revert my installation to 4.3.20 while a patch is not released.
comment:11 by , 10 years ago
I have the same problem here, with a Windows 7 64 bit host and Kali Linux and Fedora 21 as guest. When i change the network settings in VirtualBox to 'NAT-Network' everything works fine. When using 'NAT' I get a lot of 'link down' events.
comment:12 by , 10 years ago
Following up with yagonna workaround. That change worked for me too. No more adapter resets after changing from NAT to Nat Network interface.
Thanks for the heads up.
comment:13 by , 10 years ago
Quite frankly, behavior is better with "NAT Network", but I still suffer connection drops. It seems that the underlying problem still manifests.
comment:15 by , 10 years ago
Not Found
The requested URL /download/testcase/VirtualBox-4.3.21-98406-Win.exe was not found.
:-(
comment:16 by , 10 years ago
comment:18 by , 10 years ago
Summary: | ethernet frequently disconnecting / reconnecting after upgrade to 4.3.22 → ethernet frequently disconnecting / reconnecting after upgrade to 4.3.22 => Fixed in SVN |
---|
comment:21 by , 10 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
Thanks for the feedback! The fix is part of the VBox 4.3.24 release.
follow-up: 23 comment:22 by , 10 years ago
This problem appears again in 4.3.26. It was fine with 4.3.23 and 4.3.24.
I'm using 64 Bit Win7 as host with Ubuntu 14.04 32 as guest.
by , 10 years ago
Attachment: | syslog-4.3.26-98988.txt added |
---|
comment:23 by , 10 years ago
Replying to athalis:
This problem appears again in 4.3.26. It was fine with 4.3.23 and 4.3.24.
Please, can you attach .VirtualBox/VBoxSVC.log
by , 10 years ago
by , 10 years ago
Attachment: | VBoxSVC.log added |
---|
comment:24 by , 10 years ago
I also added VBox.log
I think the relevant entry is:
03:59:09.355679 dns-monitor HostDnsMonitorProxy::notify
comment:25 by , 10 years ago
Resolution: | fixed |
---|---|
Status: | closed → reopened |
by , 10 years ago
Attachment: | VBoxSVC_copy_4.3.24.log added |
---|
4.3.24 VBoxSVC.log for comparison to the 4.3.26 log
comment:26 by , 10 years ago
Please, can you get revision 99022 (with a bit of extra logging) from the Testbuilds page and attach VBoxSVC.log
from that? Thanks in advance.
by , 10 years ago
Attachment: | VBoxSVC-99022.log added |
---|
comment:27 by , 10 years ago
Regarding the two search strings: the host has joined the domain of $company but I am currently at home and not connected via VPN. Speedport_W_722V_Typ_B is my DSL modem.
comment:28 by , 10 years ago
Thanks. You seems to have very short dhcp lease time for the host (about 10 minutes, so renewal every 5), and apparently Windows doesn't update search strings atomically. So after the renewal it first reports a state without search strings set (which triggers link flap) and then immediately the same state with search strings in place, but the harm has been done already.
comment:29 by , 10 years ago
I was having the same problem with 4.3.26. Went ahead and tried 4.3.27 r99022. The issue continues. Basically it disconnects so frequent that it makes this unusable.
My VB host is Windows 7 and my guest VM is Ubuntu Linux (mint).
Having happened to me at least twice in the past month or so, this is definitely making me think I should stop upgrading VirtualBox as long as it is working. Sot the new features. :)
comment:31 by , 10 years ago
I can confirm that I'm also having this problem (again) with 4.3.26 with Windows 7 host and Ubuntu 14.04 guest. It did seem to be fixed before this update.
by , 10 years ago
Attachment: | VBoxSVC.2.log added |
---|
comment:32 by , 10 years ago
I'm also having this problem with a Windows 7 host and a Ubuntu 14.04 LTS guest. I have a single ethernet adapter plugged in and have no networking issues on the host OS, but the guest network connection flaps frequently. I'm using VirtualBox 4.3.26r98988. My network card is NATed and this happens regardless of the type of hardware I set my card to emulate, including virtio. I do have the latest version of the guest additions installed as well.
dmesg shows:
[12853.913069] e1000: eth0 NIC Link is Down [12858.205962] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready [12859.925161] e1000: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX [12859.925436] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready [13094.393332] e1000: eth0 NIC Link is Down [13099.207787] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready [13100.404508] e1000: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX [13100.404750] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready [13334.872249] e1000: eth0 NIC Link is Down [13339.208895] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready [13340.884546] e1000: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX [13340.884870] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready [14176.552231] e1000: eth0 NIC Link is Down [14180.560572] e1000: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX [14537.272247] e1000: eth0 NIC Link is Down [14541.281013] e1000: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX
comment:33 by , 10 years ago
This is not fun anymore. After one day of usage (win7+Xubuntu 10.04):
$ dmesg | grep -c "NIC Link is Down"
158
For example:
[ 3207.640248] e1000: eth29 NIC Link is Down [ 3212.649747] e1000: eth29 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX [ 3375.493681] e1000: eth29 NIC Link is Down [ 3380.503569] e1000: eth29 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX [ 3451.396221] e1000: eth29 NIC Link is Down [ 3456.406194] e1000: eth29 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX [ 3758.537242] e1000: eth29 NIC Link is Down [ 3763.547896] e1000: eth29 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX
...
VirtualBox version is r99022
Edit: For me, the network was ok in 4.3.22, but broken in 4.3.24 and 4.3.26.
follow-up: 35 comment:34 by , 10 years ago
I have the same symptoms in 4.3.26 I had in 4.3.22, that were corrected in 4.3.24
https://forums.virtualbox.org/viewtopic.php?f=6&t=66086#p312985
Note that changing the network adapter to a non Intel one, as described below, still work as an easy temporary fix! This may be useful for other people, till we get an official fix and we can revert to the default Intel adapter
https://forums.virtualbox.org/viewtopic.php?f=6&t=66086#p313103
comment:35 by , 10 years ago
Replying to JYP:
Note that changing the network adapter to a non Intel one, as described below, still work as an easy temporary fix! This may be useful for other people, till we get an official fix and we can revert to the default Intel adapter
No. Changing adapter does not solve the problem for me. The symptoms are the same regardless of the adapter model.
comment:36 by , 10 years ago
I have the same problem with 4.3.26 and switched back to 4.3.24, which works fine.
I am using VirtualBox on a Lenoveo T440s with Windows7(64bit) as host Linux Mint 17 as guest. I have installed the guest addons for the guest.
Thanks for this great software ... it makes live with multiple operating systems much easier. (.. but please make sure an update is not that "dangerous" anymore :) )
Best, Jens
comment:37 by , 10 years ago
For me the mentioned workaround works. I am running
Virtualbox 4.3.26 Host - Windows 7 (64-bit) Guest - Ubuntu 14.04 LTS (64-bit)
Network distruptions stopped when I changed adapter from "Intel PRO/1000 MT Desktop (82540EM)" to "PCnet-FAST III (Am79C973)"
Best Regards,
Antti
comment:38 by , 10 years ago
I was experiencing the same issue with VirtualBox 4.3.26 on a Windows 7 64-bit host running Linux Mint 16 64-bit in the VM (Ubuntu based).
The suggested workaround to use "PCnet-FAST III (Am79C973)" did not work for me, the issue still occurred quite frequently. I had to switch it to "PCnet-FAST II (Am79C970A)" to get it working. Out of curiosity I also tried all the other Intel adapters and they all showed the same issue.
comment:40 by , 10 years ago
I can confirm this problem has returned for Windows hosting Windows as well. I currently run a Windows 7 x64 PC running a Windows 7 x64 Guest and the network frequently drops. I have the same problem on running a Windows XP 32bit guest as well. I have tested this on both AMD and Intel platforms. I have resorted back to the hot-fix VirtualBox-4.3.24-98716-Win from the 4.3.22 thread. This seems to be working. Connecting a windows dial-up PPP via shared COM/Modem on Host also refuses to connect. not sure if this is related.
comment:41 by , 10 years ago
Problem is there on guest windows 7, and virtual box 4.2.6r98988
Mar 31 16:36:22 rac2 kernel: e1000: eth0 NIC Link is Down Mar 31 16:36:22 rac2 NetworkManager[1795]: <info> (eth0): carrier now OFF (device state 8, deferring action for 4 seconds) Mar 31 16:36:26 rac2 NetworkManager[1795]: <info> (eth0): carrier now ON (device state 8) Mar 31 16:36:26 rac2 kernel: e1000: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX
follow-up: 43 comment:42 by , 10 years ago
Please, can you give a recent Windows testbuild a try, revision 99378 (or higher).
If you still experience problem with the test build, please, provide VBoxSVC.log
.
follow-ups: 44 45 49 comment:43 by , 10 years ago
Replying to vushakov:
Please, can you give a recent Windows testbuild a try, revision 99378 (or higher).
Happy to help out. I did just install revision 99378 (shows up as 4.3.26). I am running a Ubuntu guest on a Windows 7 machine. The network problem persists:
kernel: [ 303.404228] e1000: eth0 NIC Link is Down kernel: [ 307.412524] e1000: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX kernel: [ 447.756206] e1000: eth0 NIC Link is Down kernel: [ 453.768549] e1000: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX
About every 15 seconds or so.
Prior to this, I had just updated to 4.3.26 and the problem appeared. I had not seen the problem in earlier versions, but had not updated for the past month or two.
comment:44 by , 10 years ago
Replying to jice:
Replying to vushakov:
Please, can you give a recent Windows testbuild a try, revision 99378 (or higher).
Happy to help out. I did just install revision 99378 (shows up as 4.3.26). I am running a Ubuntu guest on a Windows 7 machine. The network problem persists:
As was suggested earlier in this bug report, I did also test with alternate network adapter types. I had similar failures with PCnet-FAST III and success with PCnet-FAST II. Again, this is with revision 99378.
Two questions:
- Is this a return of the bug that was supposed to have been fixed in 4.3.24?
- What are the consequences, if any, of switching from the Intel PRO/1000 MT Desktop adapter to PCnet-FAST II?
Thank you in advance.
follow-up: 47 comment:45 by , 10 years ago
Replying to jice:
Replying to vushakov:
Please, can you give a recent Windows testbuild a try, revision 99378 (or higher).
Happy to help out. I did just install revision 99378 (shows up as 4.3.26). I am running a Ubuntu guest on a Windows 7 machine. The network problem persists:
kernel: [ 303.404228] e1000: eth0 NIC Link is Down kernel: [ 307.412524] e1000: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX kernel: [ 447.756206] e1000: eth0 NIC Link is Down kernel: [ 453.768549] e1000: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RXAbout every 15 seconds or so.
Thanks for testing. Please, can you provide VBoxSVC.log
?
447 - 303 != 15 by my count, btw :)
comment:46 by , 10 years ago
[12429.440215] e1000: enp0s3 NIC Link is Down [12433.448486] e1000: enp0s3 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX [12934.513327] e1000: enp0s3 NIC Link is Down [12940.528457] e1000: enp0s3 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX
Fedora 21 guest on Windows 7 Pro host running VirtualBox 4.3.26
follow-up: 48 comment:47 by , 10 years ago
Replying to vushakov:
Replying to jice:
Replying to vushakov:
Please, can you give a recent Windows testbuild a try, revision 99378 (or higher).
Happy to help out. I did just install revision 99378 (shows up as 4.3.26). I am running a Ubuntu guest on a Windows 7 machine. The network problem persists:
kernel: [ 303.404228] e1000: eth0 NIC Link is Down kernel: [ 307.412524] e1000: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX kernel: [ 447.756206] e1000: eth0 NIC Link is Down kernel: [ 453.768549] e1000: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RXAbout every 15 seconds or so.
Thanks for testing. Please, can you provide
VBoxSVC.log
?447 - 303 != 15 by my count, btw :)
Thanks for the attention. I am just back today.
Can you tell me what you are looking for; I see that virtualbox has generated a few of these log files and I wanted to know which to send. Also, I need to verify that they contain no confidential information before uploading.
You are right, the time seems to vary, but is never Up for very long:
kernel: [ 680.220942] e1000: eth0 NIC Link is Down kernel: [ 686.233552] e1000: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX kernel: [ 710.280200] e1000: eth0 NIC Link is Down kernel: [ 714.288525] e1000: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX kernel: [ 760.380195] e1000: eth0 NIC Link is Down kernel: [ 764.388999] e1000: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX kernel: [ 778.416225] e1000: eth0 NIC Link is Down kernel: [ 784.428514] e1000: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX kernel: [ 836.532183] e1000: eth0 NIC Link is Down kernel: [ 840.540539] e1000: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX kernel: [ 844.548894] e1000: eth0 NIC Link is Down kernel: [ 850.560485] e1000: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX
follow-up: 51 comment:48 by , 10 years ago
Replying to jice:
Can you tell me what you are looking for; I see that virtualbox has generated a few of these log files and I wanted to know which to send. Also, I need to verify that they contain no confidential information before uploading.
VBoxSVC.log
is located in C:\Users\jice\.VirtualBox\VBoxSVC.log
(assuming jice
as your username for the purpose of this example).
follow-up: 50 comment:49 by , 10 years ago
Replying to jice:
I did just install revision 99378 (shows up as 4.3.26).
How exactly does 99378 show up as 4.3.26 for you? It both shows up as 4.3.27 and resolves the issue for me. I'm running LMDE guests on a 64-bit Windows 7 host.
comment:50 by , 10 years ago
follow-up: 52 comment:51 by , 10 years ago
Replying to vushakov:
Replying to jice:
Can you tell me what you are looking for; I see that virtualbox has generated a few of these log files and I wanted to know which to send. Also, I need to verify that they contain no confidential information before uploading.
VBoxSVC.log
is located inC:\Users\jice\.VirtualBox\VBoxSVC.log
(assumingjice
as your username for the purpose of this example).
See newly attached log file VBoxSVC.log.5
follow-up: 53 comment:52 by , 10 years ago
Replying to jice:
See newly attached log file VBoxSVC.log.5
That file says
VirtualBox COM Server 4.3.26 r98988 win.amd64 (Mar 16 2015 17:35:35) release log 00:00:00.045002 main Log opened 2015-04-04T00:12:41.794474400Z
Are you sure you are testing the right version? Also, you've attached one of the old log files (.5
), not the latest, which doesn't have numeric suffix.
follow-up: 54 comment:53 by , 10 years ago
Replying to vushakov:
Replying to jice:
See newly attached log file VBoxSVC.log.5
That file says
VirtualBox COM Server 4.3.26 r98988 win.amd64 (Mar 16 2015 17:35:35) release log 00:00:00.045002 main Log opened 2015-04-04T00:12:41.794474400ZAre you sure you are testing the right version? Also, you've attached one of the old log files (
.5
), not the latest, which doesn't have numeric suffix.
I didn't think that you needed one from the test build; but makes sense that you do. I'm currently running with an alternate adapter, so I assumed that would not be interesting to you. When I have some time, I will swap to the default adapter and generate a log file.
by , 10 years ago
Attachment: | VBoxSVC.3.log added |
---|
follow-up: 55 comment:54 by , 10 years ago
I have uploaded a copy of the log. This one uses the version you ask about and it continues to disconnect.
follow-up: 56 comment:55 by , 10 years ago
Replying to jice:
I have uploaded a copy of the log. This one uses the version you ask about and it continues to disconnect.
Thanks. It's interesting that the intervals are rather irregular, so it doesn't look like DHCP's T1 renewal timer. I'll try to provide a test build with extra logging tomorrow.
Does the "os
" suffix rings the bell for you? What can be configuring it?
follow-up: 57 comment:56 by , 10 years ago
Replying to vushakov:
Replying to jice:
I have uploaded a copy of the log. This one uses the version you ask about and it continues to disconnect.
Thanks. It's interesting that the intervals are rather irregular, so it doesn't look like DHCP's T1 renewal timer. I'll try to provide a test build with extra logging tomorrow.
Does the "
os
" suffix rings the bell for you? What can be configuring it?
.os is used internally for some of our private cloud infrastructure. The host machine where VirtualBox accessing machines in that domain via OpenVPN.
follow-up: 58 comment:57 by , 10 years ago
Replying to jice:
Replying to vushakov:
It's interesting that the intervals are rather irregular, so it doesn't look like DHCP's T1 renewal timer. I'll try to provide a test build with extra logging tomorrow.
Does the "
os
" suffix rings the bell for you? What can be configuring it?
.os
is used internally for some of our private cloud infrastructure. The host machine where VirtualBox accessing machines in that domain via OpenVPN.
Meanwhile, please, can you provide output from ipconfig /all
follow-up: 59 comment:58 by , 10 years ago
Meanwhile, please, can you provide output from
ipconfig /all
Please provide an email address for direct communication. I will verify what is safe to send for security reasons.
follow-up: 60 comment:59 by , 10 years ago
Replying to jice:
Meanwhile, please, can you provide output from
ipconfig /all
Please provide an email address for direct communication. I will verify what is safe to send for security reasons.
I'm primarily interested in lease times and DNS suffix info. You can whiteout addresses.
follow-up: 61 comment:60 by , 10 years ago
Replying to vushakov:
Replying to jice:
Meanwhile, please, can you provide output from
ipconfig /all
Please provide an email address for direct communication. I will verify what is safe to send for security reasons.
I'm primarily interested in lease times and DNS suffix info. You can whiteout addresses.
OK. Can I email it to you?
follow-up: 62 comment:61 by , 10 years ago
Replying to jice:
Replying to vushakov:
Replying to jice:
Meanwhile, please, can you provide output from
ipconfig /all
Please provide an email address for direct communication. I will verify what is safe to send for security reasons.
I'm primarily interested in lease times and DNS suffix info. You can whiteout addresses.
OK. Can I email it to you?
BASIC INFO:
Ethernet adapter Local Area Connection 4: Connection-specific DNS Suffix . : os Description . . . . . . . . . . . : TAP-Windows Adapter V9 DHCP Enabled. . . . . . . . . . . : Yes Lease Obtained. . . . . . . . . . : Tuesday, April 14, 2015 12:23:53 PM Lease Expires . . . . . . . . . . : Wednesday, April 13, 2016 12:23:52 PM Ethernet adapter Local Area Connection: Connection-specific DNS Suffix . : rd.foobar.fr Description . . . . . . . . . . . : Intel(R) 82579LM Gigabit Network Connection DHCP Enabled. . . . . . . . . . . : Yes Autoconfiguration Enabled . . . . : Yes Lease Obtained. . . . . . . . . . : Tuesday, April 14, 2015 12:21:17 PM Lease Expires . . . . . . . . . . : Tuesday, April 14, 2015 1:21:17 PM Ethernet adapter VirtualBox Host-Only Network: Connection-specific DNS Suffix . : Description . . . . . . . . . . . : VirtualBox Host-Only Ethernet Adapter Physical Address. . . . . . . . . : 08-00-27-00-A8-42 DHCP Enabled. . . . . . . . . . . : No Autoconfiguration Enabled . . . . : Yes Link-local IPv6 Address . . . . . : XXXXXXXXXXXXXXXXXXXXXXXXX(Preferred) IPv4 Address. . . . . . . . . . . : XXXXXXXXXXXXXXXXXXXXXXXXX(Preferred) Subnet Mask . . . . . . . . . . . : 255.255.255.0 Default Gateway . . . . . . . . . : DHCPv6 IAID . . . . . . . . . . . : 570949671 DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-15-9A-B7-A6-5C-26-0A-5D-B7-DD DNS Servers . . . . . . . . . . . : fec0:0:0:ffff::1%1 fec0:0:0:ffff::2%1 fec0:0:0:ffff::3%1 NetBIOS over Tcpip. . . . . . . . : Enabled
comment:62 by , 10 years ago
Replying to jice:
As I expected, you have sufficiently long DHCP leases. The original problem was triggered during DHCP renewals of existing leases and was very visible for people with very short - a few minutes - lease times.
Your problem seems to be triggered by something else. As can be seen from the log you posted, something keeps adding and removing .os
suffix to your search list at seemingly random intervals. Were there any corresponding changes to the VPN connectivity?
comment:63 by , 9 years ago
Hello,
I've installed VBox v4.3.26-98988 yesterday, with Win7 as Host OS and XUvuntu as guest OS, and I'm unable to have a stable network connection, as described in this thread.
The log I get in VBoxSVC is: 00:15:32.254514 dns-monitor HostDnsMonitorProxy::notify
It makes it unusable, as I get a deconnection every 2 or 5 minutes...
Any idea how to resolve this, or what could be the root cause?
Note:
- the host laptop is connected to internet network through its wifi adapter, and the ethernet adapter is connected to a switch for local network.
- I see no network deconnection outside from VirtualBox, meaning that when using a tool like mobaxterm to ssh to another linux device, the connection is stable.
Thanks and regards
follow-up: 65 comment:64 by , 9 years ago
As said in comment:42, please, can you give a recent Windows testbuild a try, revision 99378 (or higher).
If you still experience problem with the test build, please, provide VBoxSVC.log.
comment:65 by , 9 years ago
Hello vushakov,
It seems more stable with latest windows test build. Do you know what was the issue with previous release?
I'll let you know if I face the issue again.
Thanks!
Replying to vushakov:
As said in comment:42, please, can you give a recent Windows testbuild a try, revision 99378 (or higher).
If you still experience problem with the test build, please, provide VBoxSVC.log.
follow-up: 67 comment:66 by , 9 years ago
Latest test build still has the same issue for me however, the disconnect and re-connect is much faster. Almost like a flicker. The device disconnect/reconnect bubble in windows pops up like a LED flashing however, it is still a problem. VPN connections with encryption drop, Citrix access is aborted.
Windows 7 x64 Host running a Windows 7 x64 Guest Symptoms are worse under Windows 7 Host running Windows XP Guest.
VirtualBox VM 4.3.27 r99378 win.amd64 (Apr 2 2015 02:36:01) release log 00:00:03.791831 Log opened 2015-04-21T23:32:46.198847800Z 00:00:03.791832 Build Type: release 00:00:03.791834 OS Product: Windows 7 00:00:03.791835 OS Release: 6.1.7601 00:00:03.791835 OS Service Pack: 1 00:00:03.822668 DMI Product Name: To be filled by O.E.M. 00:00:03.824851 DMI Product Version: To be filled by O.E.M. 00:00:03.824854 Host RAM: 16343MB total, 10534MB available 00:00:03.824856 Executable: C:\Program Files\Oracle\VirtualBox\VirtualBox.exe 00:00:03.824856 Process ID: 595176 00:00:03.824857 Package type: WINDOWS_64BITS_GENERIC 00:00:03.835512 Installed Extension Packs: 00:00:03.835552 Oracle VM VirtualBox Extension Pack (Version: 4.3.26 r98988; VRDE Module: VBoxVRDP) ............... 00:00:18.623254 UIFrameBufferQImage::resizeEvent: Format=843204434, BitsPerPixel=32, BytesPerLine=7680, Size=1920x1016 00:00:18.623275 UIFrameBufferQImage::resizeEvent: Resizing to directly use VGA device content.. 00:00:18.866410 NAT: IPv6 not supported 00:00:20.101931 UIMachineLogicNormal::sltCheckForRequestedVisualStateType: Requested-state=0, Machine-state=5 00:00:20.107029 UIMachineLogicNormal::sltCheckForRequestedVisualStateType: Requested-state=0, Machine-state=5 00:00:20.980566 NAT: DHCP offered IP address 10.0.2.15 00:00:22.395214 NAT: link up 00:00:29.579652 EHCI: USB Suspended 00:01:22.821526 NAT: DHCP offered IP address 10.0.2.15 00:01:26.857606 NAT: link down 00:01:31.922552 NAT: link up 00:01:31.928713 NAT: DNS#0: 125.213.163.248 00:01:31.928726 NAT: DNS#1: 202.177.197.1 00:01:31.929567 NAT: DHCP offered IP address 10.0.2.15 00:01:34.906662 NAT: DHCP offered IP address 10.0.2.15 00:01:37.861090 NAT: link down 00:01:42.945973 NAT: link up 00:01:42.949211 NAT: DNS#0: 125.213.163.248 00:01:42.949229 NAT: DNS#1: 202.177.197.1 00:01:42.952252 NAT: DHCP offered IP address 10.0.2.15 00:02:05.618962 NAT: DHCP offered IP address 10.0.2.15 00:02:06.762515 UIMachineLogicNormal::sltCheckForRequestedVisualStateType: Requested-state=0, Machine-state=5 00:02:06.787094 Guest Additions capability report: (0x0 -> 0x1) seamless: yes, hostWindowMapping: no, graphics: no 00:02:06.787191 UIMachineLogicNormal::sltCheckForRequestedVisualStateType: Requested-state=0, Machine-state=5 00:02:06.821491 UIMachineLogicNormal::sltCheckForRequestedVisualStateType: Requested-state=0, Machine-state=5 00:02:06.821534 Guest Additions capability report: (0x1 -> 0x5) seamless: yes, hostWindowMapping: no, graphics: yes 00:02:06.821592 UIMachineLogicNormal::sltCheckForRequestedVisualStateType: Requested-state=0, Machine-state=5 00:03:11.319045 NAT: DHCP offered IP address 10.0.2.15 00:04:05.143634 NAT: DHCP offered IP address 10.0.2.15 00:05:19.756706 NAT: DHCP offered IP address 10.0.2.15 00:06:19.813082 NAT: link down 00:06:24.816271 NAT: link up 00:06:24.819798 NAT: DNS#0: 125.213.163.248 00:06:24.819813 NAT: DNS#1: 202.177.197.1 00:06:24.828280 NAT: DHCP offered IP address 10.0.2.15 00:06:28.247196 NAT: DHCP offered IP address 10.0.2.15 00:09:19.657361 NAT: link down 00:09:24.715089 NAT: link up 00:09:24.718147 NAT: DNS#0: 125.213.163.248 00:09:24.718162 NAT: DNS#1: 202.177.197.1 00:09:24.722591 NAT: DHCP offered IP address 10.0.2.15 00:09:28.045053 NAT: DHCP offered IP address 10.0.2.15 00:10:42.799554 NAT: link down 00:10:47.985249 NAT: link up 00:10:47.988479 NAT: DNS#0: 125.213.163.248 00:10:47.988498 NAT: DNS#1: 202.177.197.1 00:10:47.990711 NAT: DHCP offered IP address 10.0.2.15 00:10:51.575282 NAT: DHCP offered IP address 10.0.2.15 00:13:10.640830 NAT: DHCP offered IP address 10.0.2.15 00:13:58.807682 NAT: link down 00:14:03.841666 NAT: link up 00:14:03.845737 NAT: DNS#0: 125.213.163.248 00:14:03.845757 NAT: DNS#1: 202.177.197.1 00:14:03.850420 NAT: DHCP offered IP address 10.0.2.15 00:14:07.087044 NAT: DHCP offered IP address 10.0.2.15 00:15:12.622185 NAT: DHCP offered IP address 10.0.2.15 00:15:27.441526 NAT: link down 00:15:32.459800 NAT: link up 00:15:32.466886 NAT: DNS#0: 125.213.163.248 00:15:32.466905 NAT: DNS#1: 202.177.197.1 00:15:32.474333 NAT: DHCP offered IP address 10.0.2.15 00:15:38.034501 NAT: DHCP offered IP address 10.0.2.15 00:16:51.048260 NAT: DHCP offered IP address 10.0.2.15 00:18:20.035646 NAT: link down 00:18:25.040210 NAT: link up 00:18:25.042758 NAT: DNS#0: 125.213.163.248 00:18:25.042772 NAT: DNS#1: 202.177.197.1 00:18:25.091706 NAT: DHCP offered IP address 10.0.2.15 00:18:30.262559 NAT: DHCP offered IP address 10.0.2.15 00:20:01.282768 NAT: link down 00:20:06.286154 NAT: link up 00:20:06.291379 NAT: DNS#0: 125.213.163.248 00:20:06.291400 NAT: DNS#1: 202.177.197.1 00:20:06.292170 NAT: DHCP offered IP address 10.0.2.15 00:20:11.933582 NAT: DHCP offered IP address 10.0.2.15 00:21:30.920897 NAT: link down 00:21:35.932493 NAT: link up 00:21:35.941678 NAT: DNS#0: 125.213.163.248 00:21:35.941699 NAT: DNS#1: 202.177.197.1 00:21:35.945921 NAT: DHCP offered IP address 10.0.2.15 00:21:41.761267 NAT: DHCP offered IP address 10.0.2.15 00:22:45.721614 NAT: DHCP offered IP address 10.0.2.15 00:23:50.985475 NAT: DHCP offered IP address 10.0.2.15 00:25:08.925252 NAT: link down 00:25:13.939781 NAT: link up 00:25:13.942460 NAT: DNS#0: 125.213.163.248 00:25:13.942478 NAT: DNS#1: 202.177.197.1 00:25:13.951623 NAT: DHCP offered IP address 10.0.2.15 00:25:17.362897 NAT: DHCP offered IP address 10.0.2.15 00:26:12.924094 NAT: link down 00:26:17.930307 NAT: link up 00:26:17.936445 NAT: DNS#0: 125.213.163.248 00:26:17.936464 NAT: DNS#1: 202.177.197.1 00:26:17.938591 NAT: DHCP offered IP address 10.0.2.15 00:26:21.745292 NAT: DHCP offered IP address 10.0.2.15 00:27:43.673536 NAT: link down 00:27:48.675375 NAT: link up 00:27:48.678190 NAT: DNS#0: 125.213.163.248 00:27:48.678207 NAT: DNS#1: 202.177.197.1 00:27:48.681001 NAT: DHCP offered IP address 10.0.2.15 00:27:52.115415 NAT: DHCP offered IP address 10.0.2.15 00:28:57.358498 NAT: DHCP offered IP address 10.0.2.15 00:29:13.256088 NAT: link down 00:29:18.279827 NAT: link up 00:29:18.283875 NAT: DNS#0: 125.213.163.248 00:29:18.283894 NAT: DNS#1: 202.177.197.1 00:29:18.286593 NAT: DHCP offered IP address 10.0.2.15 00:29:21.470003 NAT: DHCP offered IP address 10.0.2.15 00:30:08.970686 NAT: link down 00:30:14.001412 NAT: link up 00:30:14.011726 NAT: DNS#0: 125.213.163.248 00:30:14.011747 NAT: DNS#1: 202.177.197.1 00:30:14.013990 NAT: DHCP offered IP address 10.0.2.15 00:30:17.844466 NAT: DHCP offered IP address 10.0.2.15 00:30:32.940343 UIMediumEnumerator: Medium-enumeration started... 00:30:33.084974 UIMediumEnumerator: Medium-enumeration finished! 00:31:40.431180 NAT: DHCP offered IP address 10.0.2.15 00:32:05.074755 UIMediumEnumerator: Machine (or snapshot) event received, ID = c9331fae-5341-497e-a949-80f0e6b2c8c1 00:32:05.074795 UIMediumEnumerator: Old usage: 53a74183-311e-4bdb-8a43-06def4069867, 749516d8-c575-4cc7-839f-176c510fc6af 00:32:05.076555 UIMediumEnumerator: New usage: 53a74183-311e-4bdb-8a43-06def4069867, 749516d8-c575-4cc7-839f-176c510fc6af 00:32:05.076575 UIMediumEnumerator: Machine (or snapshot) event processed, ID = c9331fae-5341-497e-a949-80f0e6b2c8c1 00:33:30.075254 NAT: DHCP offered IP address 10.0.2.15 00:33:43.235871 NAT: link down 00:33:48.241256 NAT: link up 00:33:48.247538 NAT: DNS#0: 125.213.163.248 00:33:48.247551 NAT: DNS#1: 202.177.197.1 00:33:48.251441 NAT: DHCP offered IP address 10.0.2.15 00:33:51.517276 NAT: DHCP offered IP address 10.0.2.15 00:34:59.493671 NAT: DHCP offered IP address 10.0.2.15 00:35:14.946232 NAT: link down 00:35:19.954633 NAT: link up 00:35:19.962721 NAT: DNS#0: 125.213.163.248 00:35:19.962742 NAT: DNS#1: 202.177.197.1 00:35:19.971090 NAT: DHCP offered IP address 10.0.2.15 00:35:23.931050 NAT: DHCP offered IP address 10.0.2.15 00:36:44.338062 NAT: DHCP offered IP address 10.0.2.15 00:36:46.676878 NAT: link down 00:36:51.686544 NAT: link up 00:36:51.696204 NAT: DNS#0: 125.213.163.248 00:36:51.696226 NAT: DNS#1: 202.177.197.1 00:36:51.702572 NAT: DHCP offered IP address 10.0.2.15 00:36:54.767025 NAT: DHCP offered IP address 10.0.2.15 00:38:17.354321 NAT: DHCP offered IP address 10.0.2.15
comment:67 by , 9 years ago
Replying to ads_aus:
Latest test build still has the same issue for me however, the disconnect and re-connect is much faster. Almost like a flicker. The device disconnect/reconnect bubble in windows pops up like a LED flashing however, it is still a problem. VPN connections with encryption drop, Citrix access is aborted.
Please, as requested, provide VBoxSVC.log
.
comment:69 by , 9 years ago
Component: | network → network/NAT |
---|
comment:70 by , 9 years ago
I'm seeing similar problems between win 7 virtualbox, and a centos 7 guest. Tried the other ethernet cards mentioned but system didn't seem to be able to bind to them. So, I'm back to the original Intel card that drops after a period of time. Let me know if I can assist in collecting data on my system. I'm using 4.3.26r98988
comment:71 by , 9 years ago
Please, give a recent Windows testbuild a try.
If you still experience problem with the test build, please, provide VBoxSVC.log.
comment:72 by , 9 years ago
Only one drop connection since installing testbuild 4.3.27 r99897 with guest 4.3.27 r 99864. Thanks. Let me know if there is anything else, I can do to help test.
follow-up: 74 comment:73 by , 9 years ago
I've just tried the testbuild, but the issue still exists. Windows 7 x64 Host, Windows 7 x86 guest, Ubuntu 12.04 guest, both guests are affected.
comment:74 by , 9 years ago
Replying to roemer2201:
I've just tried the testbuild, but the issue still exists. Windows 7 x64 Host, Windows 7 x86 guest, Ubuntu 12.04 guest, both guests are affected.
As repeatedly requested, please, if the test build doesn't fix it for you, provide VBoxSVC.log
(NB: not VBox.log
!).
by , 9 years ago
Attachment: | VBoxSVC_roemer2201_v4.3.27_.log added |
---|
VBoxSVC.log as requestet from roemer2201 for 4.3.27 r100091
comment:75 by , 9 years ago
Thank you. It's only the second actual VBoxSVC.log
and as with the first one (comment:56) VPN seems to be involved.
Please, can you also provide output of ipconfig /all
? I'm primarily interested in lease times and dns suffixes, so you can whiteout any addresses.
by , 9 years ago
Attachment: | ipconfig_all_roemer2201_20150508.txt added |
---|
comment:77 by , 9 years ago
I have the same problem - my NAT connection constantly bounces. I've attached above the full logs from my ssh client (networkbounce.txt) (bitvise) and from vbox (VBox.3.log). (The problem also happens with putty.)
- Host OS is windows 7 fully updated.
- Guest OS is CentOS 6.6, yum update as of yesterday.
- Vbox is 4.3.26 r98988
Setup is NAT
- using adapter type Intel PRO/1000 MT Desktop
- Port Forward rule has HOST and GUEST IP blank
The ssh client error is
The SSH2 session has terminated with error. Reason: Error class: LocalSshDisconn, code: ConnectionLost, message: FlowSshTransport: received EOF.
The log error indication is
00:00:31.957819 NAT: link up 00:00:31.961262 NAT: DNS#0: 75.75.75.75 00:00:31.961271 NAT: DNS#1: 75.75.75.76 00:00:31.961273 NAT: DNS#2: 10.16.1.1 00:00:31.961276 NAT: set redirect TCP host 0.0.0.0:20022 => guest 10.0.2.15:22 00:00:37.944648 NAT: link down 00:00:42.945019 NAT: link up 00:00:42.947653 NAT: DNS#0: 75.75.75.75 00:00:42.947661 NAT: DNS#1: 75.75.75.76 00:00:42.947663 NAT: DNS#2: 10.16.1.1 00:00:42.947665 NAT: set redirect TCP host 0.0.0.0:20022 => guest 10.0.2.15:22 00:01:52.260485 NAT: link down
and so on.
I should add I have multiple boxes, all NATed. They have different mac addresses, but each come up with the same default private network ip (10.0.2.15). I don't know how virtual box keeps the multiple private networks separate; and wonder if that's an issue. (I would expect not, as I have seen nothing in the documentation indicating it's something that requires special configuration.)
Further information: /var/log/messages shows a curious error from vminfo
vminfo Error: Unable to connect to system D-Bus (1/3): Failed to connect to socket /var/run/dbus/system_bus_socket: No such file or directory
(It fails 2 more times and appears to give up.)
comment:78 by , 9 years ago
Replying to roemer2201:
My computer is connected to a VPN provided by OpenVPN.
Note how in your log the domain name is switching back and forth between lan
and vpn.domain.com
. Since 10.10.0.1
remains listed as your nameserver, I assume you remain connected to the vpn, though.
The other user who provided the necessary log also uses vpn and for him the domain remains his local one, but the vpn dns suffix is likewise added and removed to the search list.
Unfortunately I don't know much about that corner of Windows networking (since it involves local policies and what not), but note that if I interpret your logs correctly, for both of you there are time intervals where you are connected to the vpn, but the vpn suffix is not used to search domain names. You should be able to see this by doing ipconfig /all
right after NAT link flaps and checking "DNS Suffix Search List". What causes your link flap is precisely this change in DNS configuration. Link is flapped to cause DHCP renewal so that new DNS information is passed to the client.
This is probably a local misconfiguration - I wouldn't expect that kind of domain or search list changes while you connectivity is not changing. If you can figure out the cause of those changes and fix it, the NAT link flap will not happen. Anyway, I think it makes sense for virtualbox to provide a discreet knob to ignore changes in dns suffix search list. Corporate Windows installs are not infrequently pre-configured with, uhm, interesting settings and then locked down.
Meanwhile, I would be interested to hear whether my hypothesis about dns suffixes is correct, whether you cannot always use short names to refer to machines in your vpn domain.
by , 9 years ago
Attachment: | VBoxSVC.4.log added |
---|
by , 9 years ago
Attachment: | VBoxSVC.5.log added |
---|
comment:79 by , 9 years ago
Just uploaded vboxsvc.5.log for version 4.3.28 of Virtualbox. Still got the same issues as reported earlier.! 4.3.20 does not have these problems. Rolling back.
comment:80 by , 9 years ago
As mentioned in comment:78 I've added a kludge in 4.3.28
to ignore these changes. You can use
VBoxManage setextradata global VBoxInternal2/HostDNSSuffixesIgnore 1
to enable it. Set to 0
or empty string ""
to disable.
follow-up: 82 comment:81 by , 9 years ago
This works for me - I was able to upgrade to 4.3.28 and it works quite nicely - thanks!
comment:82 by , 9 years ago
Replying to Derek D:
This works for me - I was able to upgrade to 4.3.28 and it works quite nicely - thanks!
Without the kludge for the problem that so far only seems to manifest for VPN? Or do you use the VPN, still had the problem with the test builds and now it works with 4.3.28 and the kludge?
comment:83 by , 9 years ago
4.3.28 (still) does not work for me.
@Derek D: I did not understand what "ignoring these changes" meant and, failing to clearly understand "the kludge" have not tried it.
Rolled back to 4.3.20 and all works well.
comment:84 by , 9 years ago
Stephen, please, as repeatedly requested, the log file that is relevant for the problem in 4.3.28 (or earlier 4.3.27 test builds) is VBox
SVC
.log
. Attaching VBox.log
or ssh logs does not help.
The "kludge" command is given in the same comment:80 right on the next line after the one you quote.
comment:85 by , 9 years ago
I am seeing this with VirtualBox 4.3.28 on a Windows 7 64-bit host.
The host has two network adapters connected to two different wired DHCP enabled networks. One DHCP network is a domain network with normal long lease time and other network is a development network that has a 30 minute lease time.
The guest has one enabled adapter attached to NAT as paravirtualized network (virtio-net).
%USERPROFILE%\.VirtualBox\VBoxSVC.log
shows this kind of entries switching back and forth between the two information. (I hide the real domain name with domain.example.org)
95:43:12.743192 dns-monitor HostDnsMonitorProxy::notify 95:48:20.805311 dns-monitor HostDnsMonitor: old information 95:48:20.805311 dns-monitor server 1: 192.168.1.239 95:48:20.805311 dns-monitor server 2: 10.11.12.12 95:48:20.805311 dns-monitor server 3: 10.11.12.13 95:48:20.805311 dns-monitor search string 1: domain.example.org 95:48:20.805311 dns-monitor search string 2: local 95:48:20.805311 dns-monitor domain: domain.example.org 95:48:20.805811 dns-monitor HostDnsMonitor: new information 95:48:20.805811 dns-monitor server 1: 192.168.1.239 95:48:20.805811 dns-monitor server 2: 10.11.12.12 95:48:20.805811 dns-monitor server 3: 10.11.12.13 95:48:20.805811 dns-monitor no search string entries 95:48:20.805811 dns-monitor domain: domain.example.org 95:48:20.805811 dns-monitor HostDnsMonitorProxy::notify 95:52:10.854523 dns-monitor HostDnsMonitor: old information
The period of change seems random from about 15 seconds to nearly 30 minutes.
ipconfig /all
shows the DNS Suffix Search List the same regardless which information is the latest.
follow-up: 93 comment:86 by , 9 years ago
As mentioned earlier in version 4.3.28 the following vboxmanage option was added to manually workaround the problems caused by multiple networks on the host:
VBoxManage setextradata global VBoxInternal2/HostDNSSuffixesIgnore 1
comment:87 by , 9 years ago
I install the VBox Version 4.3.28 and I'm using Linux Mint 17.1. In a VM Ware Machine it works fine, but in VBox it seems that the machine is disconnected randomly. I'm using a single wired connection and the WiFi is off.
I execute the VBoxManage command but the problem persist.
What else I need to do in order to get Linux Mint works in VBox?
Thanks in advance.
comment:88 by , 9 years ago
Experiencing this with 4.3.26 r98988 and Windows 7 host with Ubuntu 14.0.4 VM.
Have not seen this in RHEL 6.4 VM.
comment:89 by , 9 years ago
Ok, I'm testing another Linux Distribution...
In fact I've tested: Linux Mint 17.1, Linux Ubuntu 14 LTE and now Linux Elementary OS Frya.
And the problem remains. The internet connection goes away and sometimes never returns.
My OS is Win7 Ultimate 64Bits.
VBox Version 4.2.30 r100415
What a shame that this amazing tool is not working as it's means that should.
follow-up: 94 comment:90 by , 9 years ago
I am using a Lenovo W520 (enterprise-based) laptop with Windows 7 and a Fedora 20 guest. I need to use a NAT connection with this guest and it frequently drops and reconnects. I have tried the setextradata command above (and confirmed that it took) and it made no difference whatsoever.
This problem seems to occur very intermittently, but is fairly frequent and will happen at least several times per day, if not many more. This same behavior happened to me initially with 4.3.22 and was corrected for me in 4.3.24. It was then broken again in BOTH 4.3.26 & 4.3.28. I am having to leave this system on the old 4.3.24 version, as this is the latest that works properly for me.
I will attach some logs (from the various versions) for this system that illustrate this problem shortly...
comment:91 by , 9 years ago
Please check comment:86 and try setting the mentioned option.
Can somebody please change the state of this ticket?
comment:92 by , 9 years ago
As stated in my previous comment, I have tried the solution presented in comment 86 and it did NOT work. This is still an issue.
comment:93 by , 9 years ago
Replying to roemer2201:
As mentioned earlier in version 4.3.28 the following vboxmanage option was added to manually workaround the problems caused by multiple networks on the host:
VBoxManage setextradata global VBoxInternal2/HostDNSSuffixesIgnore 1
My experience is that after setting this global, I am able to maintain a connection to the VB guest instance using the Intel PRO/1000 MT Desktop (82540EM) adapter while also connected to a VPN as previously. Seems like an effective work around.
What side effect does setting HostDNSSufficesIgnore have? Does it limit ability of my VM to look up hosts on one or both domains?
comment:94 by , 9 years ago
Replying to mongorian:
I am using a Lenovo W520 (enterprise-based) laptop with Windows 7 and a Fedora 20 guest. I need to use a NAT connection with this guest and it frequently drops and reconnects. I have tried the setextradata command above (and confirmed that it took) and it made no difference whatsoever.
I'm sorry for skipping your statement about the setextradata statement.
Does your host have multiple Ethernet connections to different networks (Ethernet+VPN or WiFi+VPN or even Ethernet+WiFi)? Please attach the output of "ipconfig /cmd", this will help to understand your hosts network connections.
I will attach some logs (from the various versions) for this system that illustrate this problem shortly...
Some people here asked for VBoxSVC logs, but I could not find them in your zip file. Can you please attach them?
comment:95 by , 9 years ago
Attaching the VBoxSVC logs and output from ipconfig /all.
This system has both a LAN & WiFi connection; however, one of the two is always disabled via an automated solution. If a LAN connection is detected, then the wifi connection is automatically disabled. This system is always connected via a LAN cable so you will not even see the wifi connection in the ipconfig output. You will see a BlackBerry connection in there though, which was created by the BB software for tethering capabilities (I believe), but that is _never_ used.
There is a VPN connection involved here though, which you'll see in the ipconfig output (as Juniper Network Connect). This connection is _always_ in use, as I work full time remote.
FYI - I am back on 4.3.24 now, since I need this system functional to work with. I run a great deal of long running, critical commands against remote servers from this virtualbox installation. If need be though, I can try reinstalling 4.3.28 again if another specific test is needed.
comment:96 by , 9 years ago
FYI... I have disabled the BlackBerry network adapter AND system services (which I had to do in order to get the net adapter to stay disabled) and then I upgraded my VBox installation back to 4.3.28. The only network adapters showing up now are the wired LAN & the VPN.
I went ahead and started the guest WITHOUT the setextradata command to see if the problems still persist without the BlackBerry net adapter present. If it does persist then I will try that command again. Question about that...
It appears that the BlackBerry adapter MAY be needed by the BB Link software, used to manage files on the BB device from the computer. If it does end up being the BlackBerry net adapter causing problems, is there a different version of the setextradata command that I should run, that would make it specific to that adapter (so that I wouldn't have to disable it entirely)?
Thanks for your help on this!
comment:97 by , 9 years ago
Update on my previous comment... Disabling the BlackBerry net adapter (and system services) seems to have corrected this issue for me.
Any ideas why the setextradata command provided in comment 86 didn't help with this particular adapter type?
comment:98 by , 9 years ago
The BlackBerry net adapter shouldn't affect this. If you re-enable it, does the problem come back? If it does, please provide VBox.log
and VBoxSVC.log
that contains pertinent logs.
comment:99 by , 9 years ago
Initially the "VBoxManage setextradata global VBoxInternal2/HostDNSSuffixesIgnore 1" appeared to fix this issue for me, but today the issue came back. I check to see that the setting was still 1 (VBoxManage getextradata global VBoxInternal2/HostDNSSuffixesIgnore) and it was, so now I'm not sure what to do other than rollback to a previous version, which I really don't want to do.
The issue for me is that the internet intermittently disconnects from the virtual box even though my internet connection is fine.
follow-up: 107 comment:100 by , 9 years ago
I'm having this problem too--but only on Windows 7 x64. Windows 8.1 VBox 4.3.26 and 4.3.28 work just fine--same VM no issues. Only on Windows 7 x64, running 4.3.26 right now.
My test case is to log in on the VM and download a large file. 80MB for today's test, and on neither VM could it complete. I have one VM on Linux (Ubuntu) and one on Solaris (OpenIndiana). Both show the same issue.
I've attached a zip with the VBox.log for each VM, the VBoxSVC.log, dmesg output for each VM, and ipconfig /all output. I'm running plugged into my home router, wired ethernet, and no VPN or other interesting or corporate stuff. I don't think it is a flap of any sort from my router as it has no need to change and my DHCP lease is 12h.
This issue makes my VMs unusable. I hope the logs help shed some light on the issue.
by , 9 years ago
Attachment: | vbox_13839_disconnect.zip added |
---|
assorted log files, including vbox.log and dmesg for each vm and vboxsvc.log
comment:101 by , 9 years ago
Same problem on Windows 7 x64. Last working version 4.3.24. Especially also 5.0 is broken.
follow-up: 106 comment:103 by , 9 years ago
Hi i will try option in comment 86 tnx guys.
My issue with NatNetwork dropping connection is whit host W7 64bit and Server 2003 guest. It's dropping connection every 2 days.
Very important for me, will post results after i check it tomorrow.
comment:105 by , 9 years ago
I did and connection is fixed not need doing reboot of VM anymore. Another problem i have after this fix is we getting disconnections short one, but now we can login back straight away. That what i find in logs from that day and time i think, only this two files
NatNetwork:
<?xml version="1.0"?> <Leases version="1.0">
<Lease mac="08:00:27:5a:3c:17" network="0.0.0.0">
<Address value="10.0.2.4"/> <Time issued="138946601" expiration="1200"/>
</Lease>
</Leases>
NatNetwork.leases-prev:
<?xml version="1.0"?> <Leases version="1.0">
<Lease mac="08:00:27:5a:3c:17" network="0.0.0.0">
<Address value="10.0.2.4"/> <Time issued="138346587" expiration="1200"/>
</Lease>
</Leases>
What that can means?
comment:106 by , 9 years ago
comment:107 by , 9 years ago
Replying to AntepenultimateMan:
I'm having this problem too--but only on Windows 7 x64. Windows 8.1 VBox 4.3.26 and 4.3.28 work just fine--same VM no issues. Only on Windows 7 x64, running 4.3.26 right now.
Same Windows 7 x64 system, same VMs, upgraded to VBox 5.0.0 in order to have the option listed in comment 86. Once I upgraded to VBox 5.0.0, my problem with the network flaking on and off went away. It now works regardless of the setting in comment 86; for both 0 and 1 my VMs now have a steady network connection. So, I'm not sure what changed with version 5.0.0 and Windows 7 x64, but it is working for me now!
comment:108 by , 9 years ago
I'm having the same issue. Conditions:
- host: windows 10 64b
- vbox: Version 5.0.10 r104061
- vm: ubuntu 15.10 64b (proper guest add installed)
- network mode: nat
- My host also run an SNX VPN (which my VM needs).
comment:109 by , 9 years ago
I'm having this issue as well. VB: 5.0.10 r104061. Host: Windows 7 x64. VM: Fedora 22 VPN: Yes -- I'm connected to a VPN on the host.
service log seems to be saying the dns-monitor seems to be responsible. I have used the comment 86 workaround and it *seems* to be working for now. At least I haven't seen it since setting it. I will provide the logs if it would help.
comment:110 by , 9 years ago
Same issue here.
Config for host is Windows 7 Enterprise, VirtualBox 5.0.10 r104061, and the guest is an Xubuntu x64 15.10.
Keeps disconnecting/reconnecting every some minute.
Please note on the same host I also have an Xubuntu x64 14.04, and it works like a charm without ever disconnecting.
Very annoying.
comment:111 by , 9 years ago
I'm seeing the same issue, Win 7 x64 host, Ubuntu 14.04 guest, Virtual Box 5.0.10 r104061. I have a local wired LAN with an assigned domain name, and when I connect to a remote LAN with OpenVPN I see the following bouncing in the log, and my Nic going up and down in Ubuntu:
00:20:17.791803 dns-monitor HostDnsMonitor: old information 00:20:17.791803 dns-monitor server 1: 10.0.0.1 00:20:17.791803 dns-monitor server 2: 192.168.0.1 00:20:17.791803 dns-monitor server 3: 8.8.8.8 00:20:17.791803 dns-monitor no search string entries 00:20:17.791803 dns-monitor domain: local.domain.org 00:20:17.791803 dns-monitor HostDnsMonitor: new information 00:20:17.791803 dns-monitor server 1: 10.0.0.1 00:20:17.791803 dns-monitor server 2: 192.168.0.1 00:20:17.791803 dns-monitor server 3: 8.8.8.8 00:20:17.791803 dns-monitor no search string entries 00:20:17.791803 dns-monitor domain: remote.domain.org
And in my ubuntu dmesg:
[ 951.279637] e1000: eth2 NIC Link is Down [ 955.293171] e1000: eth2 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX [ 1003.454885] e1000: eth2 NIC Link is Down [ 1007.468284] e1000: eth2 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX
The command:
VBoxManage setextradata global VBoxInternal2/HostDNSSuffixesIgnore 1
seems to be resolving it, as I no longer see the disconnects in my guest, and see instead the following new log line in the messages:
00:20:05.794279 dns-monitor HostDnsMonitor: lax comparison 0x2, not notifying
I'd prefer to have both domains pushed through to my guest, in the order they are specified in windows.
comment:112 by , 8 years ago
Same problem with version 5.0.20 r106931, host Windows 10, guest Windows 7.
Replying to vushakov:
You should be able to see this by doing
ipconfig /all
right after NAT link flaps and checking "DNS Suffix Search List". What causes your link flap is precisely this change in DNS configuration. Link is flapped to cause DHCP renewal so that new DNS information is passed to the client.
It seems to be a problem of VirtualBox. I've logged ipconfig /all
permanently and didn't have any change on the host for "DNS Suffix Search List".
comment:113 by , 8 years ago
Same problem with version 5.0.20 r106931, host Windows 7, guest Ubuntu 14.04 LTS. Disconnecticting network every minute. VB has NAT connection, host connected to network via VPN. Ethernet card IntelPRO/1000MT desktop. Connection of host is without problems. My previous version of VirtualBox 4.2.. worked fine, but after upgrade to 5.0 I experince this annoying issue.
comment:114 by , 8 years ago
Same here with version 5.0.20 r106931 in guest Ubuntu 16.04 in host Windows 7. Before Upgrade to 5.0.20 I had no problems with guest Ubuntu 14.04.
Sometimes I see messages like these in syslog of guest:
May 12 12:30:37 tom-ubuntu kernel: [332305.389185] e1000: enp0s3 NIC Link is Down May 12 12:30:37 tom-ubuntu kernel: [332305.389260] e1000 0000:00:03.0 enp0s3: Reset adapter May 12 12:30:39 tom-ubuntu ntpd[686]: Deleting interface #3 enp0s3, 10.0.2.15#123, interface stats: received=3, sent=8, dropped=0, active_time=5 secs
Most times everything is working fine for hours and then sometimes my network connection is flickering on and off:
May 10 07:51:15 tom-ubuntu kernel: [142739.774565] e1000: enp0s3 NIC Link is Down May 10 08:45:06 tom-ubuntu kernel: [145972.253786] e1000: enp0s3 NIC Link is Down May 10 10:28:28 tom-ubuntu kernel: [152173.688011] e1000: enp0s3 NIC Link is Down May 10 11:29:05 tom-ubuntu kernel: [155810.281035] e1000: enp0s3 NIC Link is Down May 10 11:29:15 tom-ubuntu kernel: [155820.365609] e1000: enp0s3 NIC Link is Down May 10 12:16:22 tom-ubuntu kernel: [158648.090590] e1000: enp0s3 NIC Link is Down May 10 12:16:34 tom-ubuntu kernel: [158660.114607] e1000: enp0s3 NIC Link is Down May 10 12:17:36 tom-ubuntu kernel: [158722.267930] e1000: enp0s3 NIC Link is Down May 10 12:17:48 tom-ubuntu kernel: [158734.295444] e1000: enp0s3 NIC Link is Down May 10 12:37:25 tom-ubuntu kernel: [159910.757784] e1000: enp0s3 NIC Link is Down May 10 12:37:37 tom-ubuntu kernel: [159922.783309] e1000: enp0s3 NIC Link is Down May 10 17:28:40 tom-ubuntu kernel: [177385.891477] e1000: enp0s3 NIC Link is Down May 10 17:28:52 tom-ubuntu kernel: [177397.970644] e1000: enp0s3 NIC Link is Down May 10 19:22:08 tom-ubuntu kernel: [184193.951249] e1000: enp0s3 NIC Link is Down May 10 19:51:12 tom-ubuntu kernel: [185937.834796] e1000: enp0s3 NIC Link is Down May 10 21:55:54 tom-ubuntu kernel: [193420.496557] e1000: enp0s3 NIC Link is Down May 10 22:29:10 tom-ubuntu kernel: [195416.695265] e1000: enp0s3 NIC Link is Down May 10 22:29:22 tom-ubuntu kernel: [195428.718777] e1000: enp0s3 NIC Link is Down May 11 03:28:51 tom-ubuntu kernel: [213397.779379] e1000: enp0s3 NIC Link is Down May 11 03:29:01 tom-ubuntu kernel: [213407.861470] e1000: enp0s3 NIC Link is Down May 11 03:33:22 tom-ubuntu kernel: [213668.504507] e1000: enp0s3 NIC Link is Down May 11 03:33:32 tom-ubuntu kernel: [213678.583218] e1000: enp0s3 NIC Link is Down May 11 03:34:36 tom-ubuntu kernel: [213742.744609] e1000: enp0s3 NIC Link is Down May 11 03:34:46 tom-ubuntu kernel: [213752.820298] e1000: enp0s3 NIC Link is Down May 11 03:39:15 tom-ubuntu kernel: [214021.375715] e1000: enp0s3 NIC Link is Down May 11 03:39:27 tom-ubuntu kernel: [214033.454260] e1000: enp0s3 NIC Link is Down May 11 04:43:15 tom-ubuntu kernel: [217861.446929] e1000: enp0s3 NIC Link is Down May 11 04:43:27 tom-ubuntu kernel: [217873.475804] e1000: enp0s3 NIC Link is Down May 11 04:44:29 tom-ubuntu kernel: [217935.616004] e1000: enp0s3 NIC Link is Down May 11 04:44:41 tom-ubuntu kernel: [217947.691574] e1000: enp0s3 NIC Link is Down May 11 04:50:28 tom-ubuntu kernel: [218294.460668] e1000: enp0s3 NIC Link is Down May 11 04:50:38 tom-ubuntu kernel: [218304.546098] e1000: enp0s3 NIC Link is Down May 11 06:23:07 tom-ubuntu kernel: [223853.513478] e1000: enp0s3 NIC Link is Down May 11 07:04:07 tom-ubuntu kernel: [226313.722937] e1000: enp0s3 NIC Link is Down May 11 07:05:05 tom-ubuntu kernel: [226371.883332] e1000: enp0s3 NIC Link is Down May 11 07:05:19 tom-ubuntu kernel: [226385.910918] e1000: enp0s3 NIC Link is Down May 11 07:06:57 tom-ubuntu kernel: [226484.168056] e1000: enp0s3 NIC Link is Down May 11 07:07:09 tom-ubuntu kernel: [226496.251486] e1000: enp0s3 NIC Link is Down May 11 07:08:44 tom-ubuntu kernel: [226590.502963] e1000: enp0s3 NIC Link is Down May 11 07:08:56 tom-ubuntu kernel: [226602.525509] e1000: enp0s3 NIC Link is Down May 11 07:10:32 tom-ubuntu kernel: [226698.778274] e1000: enp0s3 NIC Link is Down May 11 07:10:44 tom-ubuntu kernel: [226710.859911] e1000: enp0s3 NIC Link is Down May 11 07:35:29 tom-ubuntu kernel: [228195.722761] e1000: enp0s3 NIC Link is Down May 11 07:35:41 tom-ubuntu kernel: [228207.742343] e1000: enp0s3 NIC Link is Down May 11 08:39:43 tom-ubuntu kernel: [232049.525630] e1000: enp0s3 NIC Link is Down May 11 08:39:55 tom-ubuntu kernel: [232061.546885] e1000: enp0s3 NIC Link is Down May 11 09:25:56 tom-ubuntu kernel: [234823.109323] e1000: enp0s3 NIC Link is Down May 11 09:26:14 tom-ubuntu kernel: [234841.205820] e1000: enp0s3 NIC Link is Down May 11 12:16:25 tom-ubuntu kernel: [245051.374562] e1000: enp0s3 NIC Link is Down May 11 12:16:36 tom-ubuntu kernel: [245063.451654] e1000: enp0s3 NIC Link is Down May 11 12:17:39 tom-ubuntu kernel: [245125.619505] e1000: enp0s3 NIC Link is Down May 11 12:17:51 tom-ubuntu kernel: [245137.700144] e1000: enp0s3 NIC Link is Down May 11 13:39:59 tom-ubuntu kernel: [250065.840038] e1000: enp0s3 NIC Link is Down May 11 13:40:11 tom-ubuntu kernel: [250077.882961] e1000: enp0s3 NIC Link is Down May 11 17:35:04 tom-ubuntu kernel: [264171.241954] e1000: enp0s3 NIC Link is Down May 11 18:39:55 tom-ubuntu kernel: [268062.120856] e1000: enp0s3 NIC Link is Down May 11 21:26:14 tom-ubuntu kernel: [278041.800208] e1000: enp0s3 NIC Link is Down May 12 09:10:41 tom-ubuntu kernel: [320309.587683] e1000: enp0s3 NIC Link is Down May 12 09:39:54 tom-ubuntu kernel: [322061.928498] e1000: enp0s3 NIC Link is Down May 12 09:40:06 tom-ubuntu kernel: [322074.018524] e1000: enp0s3 NIC Link is Down May 12 09:57:00 tom-ubuntu kernel: [323088.439210] e1000: enp0s3 NIC Link is Down May 12 09:57:12 tom-ubuntu kernel: [323100.467603] e1000: enp0s3 NIC Link is Down May 12 09:58:14 tom-ubuntu kernel: [323162.658357] e1000: enp0s3 NIC Link is Down May 12 09:58:25 tom-ubuntu kernel: [323172.741597] e1000: enp0s3 NIC Link is Down May 12 10:13:41 tom-ubuntu kernel: [324089.355655] e1000: enp0s3 NIC Link is Down May 12 10:13:53 tom-ubuntu kernel: [324101.384599] e1000: enp0s3 NIC Link is Down May 12 12:16:06 tom-ubuntu kernel: [331434.654669] e1000: enp0s3 NIC Link is Down May 12 12:16:16 tom-ubuntu kernel: [331444.730923] e1000: enp0s3 NIC Link is Down May 12 12:17:55 tom-ubuntu kernel: [331542.981939] e1000: enp0s3 NIC Link is Down May 12 12:18:05 tom-ubuntu kernel: [331553.061610] e1000: enp0s3 NIC Link is Down May 12 12:19:41 tom-ubuntu kernel: [331649.331519] e1000: enp0s3 NIC Link is Down May 12 12:19:53 tom-ubuntu kernel: [331661.359652] e1000: enp0s3 NIC Link is Down May 12 12:21:29 tom-ubuntu kernel: [331757.617899] e1000: enp0s3 NIC Link is Down May 12 12:21:43 tom-ubuntu kernel: [331771.706156] e1000: enp0s3 NIC Link is Down May 12 12:23:18 tom-ubuntu kernel: [331865.956480] e1000: enp0s3 NIC Link is Down May 12 12:23:30 tom-ubuntu kernel: [331878.040007] e1000: enp0s3 NIC Link is Down May 12 12:25:04 tom-ubuntu kernel: [331972.295489] e1000: enp0s3 NIC Link is Down May 12 12:25:16 tom-ubuntu kernel: [331984.379934] e1000: enp0s3 NIC Link is Down May 12 12:26:52 tom-ubuntu kernel: [332080.641089] e1000: enp0s3 NIC Link is Down May 12 12:27:04 tom-ubuntu kernel: [332092.723080] e1000: enp0s3 NIC Link is Down May 12 12:28:41 tom-ubuntu kernel: [332188.978984] e1000: enp0s3 NIC Link is Down May 12 12:28:51 tom-ubuntu kernel: [332199.059424] e1000: enp0s3 NIC Link is Down May 12 12:30:27 tom-ubuntu kernel: [332295.309113] e1000: enp0s3 NIC Link is Down May 12 12:30:37 tom-ubuntu kernel: [332305.389185] e1000: enp0s3 NIC Link is Down May 12 12:32:13 tom-ubuntu kernel: [332401.638553] e1000: enp0s3 NIC Link is Down May 12 12:32:25 tom-ubuntu kernel: [332413.755104] e1000: enp0s3 NIC Link is Down May 12 12:34:02 tom-ubuntu kernel: [332510.012719] e1000: enp0s3 NIC Link is Down May 12 12:34:14 tom-ubuntu kernel: [332522.100599] e1000: enp0s3 NIC Link is Down
Any ideas what the problem could be?
follow-up: 116 comment:115 by , 8 years ago
I have the same issue as tstiefel. I also run VirtualBox 5.0.20 r106931 on Windows 7 (6.1 Build 7601: SP1) with a guest os Ubuntu 16.04. The connection intermittently drops and reconnects, very frustrating. Any help appreciated.
VBox.log
25:53:43.888286 NAT: DHCP offered IP address 10.0.2.15 25:53:56.272333 NAT: Link down 25:54:01.272630 NAT: Link up 25:54:01.961147 NAT: DHCP offered IP address 10.0.2.15 25:55:30.079187 NAT: Link down 25:55:35.080021 NAT: Link up 25:55:36.372069 NAT: DHCP offered IP address 10.0.2.15
Output of dmesg:
[34291.787690] e1000: enp0s3 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX [34335.853363] e1000: enp0s3 NIC Link is Down [34339.859420] e1000: enp0s3 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX [34353.880078] e1000: enp0s3 NIC Link is Down [34357.886245] e1000: enp0s3 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX [34446.018106] e1000: enp0s3 NIC Link is Down [34452.027269] e1000: enp0s3 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX
comment:116 by , 8 years ago
I just wanted to state that i have the exact same issue and it is indeed very annoying. I hope it can be fixed soon or ill need to downgrade. Anyone knows what was the last Version without this issue?
comment:117 by , 8 years ago
I have the same issue running VirtualBox (5.0.20 r106931) on Windows 7 (6.1 Build 7601 SP1) with a guest os Ubuntu (14.04.4 LTS).
follow-up: 119 comment:118 by , 8 years ago
Have you tried the workaround from version 4.3.28?
VBoxManage setextradata global VBoxInternal2/HostDNSSuffixesIgnore 1
I do not know, if this setting still works in version 5.0.x, but you can give it a try. Check comment ~70-90 for more information.
comment:119 by , 8 years ago
Replying to roemer2201:
Have you tried the workaround from version 4.3.28?
VBoxManage setextradata global VBoxInternal2/HostDNSSuffixesIgnore 1I do not know, if this setting still works in version 5.0.x, but you can give it a try. Check comment ~70-90 for more information.
Thank you for pointing this out. This workaround solved my issue.
follow-ups: 121 122 comment:120 by , 8 years ago
Please, can you give a Windows test build 107647
+ a try with VBoxInternal2/HostDNSSuffixesIgnore
workaround disabled.
comment:121 by , 8 years ago
Replying to vushakov:
Please, can you give a Windows test build
107647
+ a try withVBoxInternal2/HostDNSSuffixesIgnore
workaround disabled.
If anybody does not know how to disable this workaround: Please do
VBoxManage setextradata global VBoxInternal2/HostDNSSuffixesIgnore
or
VBoxManage setextradata global VBoxInternal2/HostDNSSuffixesIgnore 0
comment:122 by , 8 years ago
Replying to vushakov:
Please, can you give a Windows test build
107647
+ a try withVBoxInternal2/HostDNSSuffixesIgnore
workaround disabled.
I disabled the workaround and saw that issue reappeared. Multiple disconnect/connects when VPN is active on the Host. I Downloaded and installed test build 5.0.x revision 107750. Now I can see that there aren't disconnect/reconnect when VPN is active on the host, but whatever this fix does, it has at least one disadvantage that the workaround has.
In my setup I have to use 2 VPN connections on the Host machine and switch between them occasionally. Let's say the VPN connections are called VPN1 and VPN2. Whenever I disconnect from VPN1 and connect to VPN2, I have to manually disable/enable networking in the Guest machine in order to get dns working with VPN2 connection instead of VPN1 connection. I had to do the same with the workaround.
comment:123 by , 8 years ago
I know this sounds repetitive, but, please, can you provide the VBoxSVC.log
that demonstrates the problem.
What do you mean by disabling/enabling networking in the guest? Flapping the link manually by pulling and inserting the virtual cable of the vbox adapter? Doing DHCP renew in the guest?
comment:124 by , 8 years ago
I haven't been able to reproduce this problem after the initial testing, so no logs.
By disabling/enabling networking in the quest, I mean that I use VirtualBox UI to do it (Devices -> Network).
comment:125 by , 8 years ago
To provide another data point that might potentially help someone
Windows 7 host, Centos 6 and Centos 7 guest, the sequence of events in my case was:
- host was broadcasting "DHCP inform" every few minutes. It was getting DHCP responses from servers, but in some cases the DNS config in the response was different so it was updating host's network configuration.
- change in dns config of the host was picked up by dns-monitor (VirtualBox component), which was showing up in the logs
- this in turn caused a restart of network in the guest (the first event in the guest logs was e1000 kernel module being unloaded) causing a loss of connectivity for a few seconds
The problem was caused by Windows' dhcp client trying to get proxy config from DHCP server and DHCP server not providing one (google "windows dhcp inform"). Setting host's dns config to manual prevented dns-monitor from resetting guest network. Setting dhcp option 252 on the server to an empty url stopped the client from flooding network (none of the other solutions helped). Probably the latter would be sufficient, but wanted to put all diagnostics in this comment
comment:126 by , 8 years ago
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
VirtualBox used to retrieve DNS information from a wrong place that was not stable w.r.t. dhcp inform updates that didn't actually change the host's search list. With the fixes referred to in comment:120 this should have been addressed. (Unfortunately, there seems to be no standard API to retrieve this, relevant parts of DnsQueryConfig
are marked as not implemented). If dhcp inform causes a genuine change in the domain/search list, this has to be reported to the guest.
I'm inclined to close this bug now. Please don't reopen without VBoxSVC.log and corresponding output from ipconfig /all
that demonstrates that VBoxSVC dns monitor picked up a bogus change that is not shown by ipconfig
.
comment:127 by , 8 years ago
Please can you give an easy and detailed description about how to get the logs you need:
- How can I create a VBoxSVC.log
- When shall I run ipconfig /all and what part of the output do you need exactly
It's a very annoying problem and VBoxInternal2/HostDNSSuffixesIgnore doesn't help anymore.
01:36:02.193650 NAT: Link down 01:36:07.193837 NAT: Link up 01:36:07.202883 NAT: DNS#0: 192.168.1.1 01:36:07.202936 NAT: DNS#1: 192.168.163.1 01:36:07.202952 NAT: DNS#2: 192.168.179.2 01:36:07.243088 NAT: DHCP offered IP address 10.0.2.15 01:37:59.459822 NAT: Link down 01:38:04.459968 NAT: Link up 01:38:04.468711 NAT: DNS#0: 192.168.1.1 01:38:04.468753 NAT: DNS#1: 192.168.179.2 01:38:04.505659 NAT: DHCP offered IP address 10.0.2.15 01:38:09.507192 NAT: Link down 01:38:14.507492 NAT: Link up 01:38:14.515663 NAT: DNS#0: 192.168.1.1 01:38:14.552638 NAT: DHCP offered IP address 10.0.2.15 01:51:42.226109 NAT: Link down 01:51:47.226320 NAT: Link up 01:51:47.235457 NAT: DNS#0: 192.168.1.1 01:51:47.235511 NAT: DNS#1: 192.168.163.1 01:51:47.235526 NAT: DNS#2: 192.168.179.2 01:51:47.280377 NAT: DHCP offered IP address 10.0.2.15 01:52:59.548919 NAT: Link down 01:53:04.549170 NAT: Link up 01:53:04.558593 NAT: DNS#0: 192.168.1.1 01:53:04.558644 NAT: DNS#1: 192.168.179.2 01:53:04.595777 NAT: DHCP offered IP address 10.0.2.15 01:53:09.595968 NAT: Link down 01:53:14.596284 NAT: Link up 01:53:14.604725 NAT: DNS#0: 192.168.1.1 01:53:14.652252 NAT: DHCP offered IP address 10.0.2.15
comment:128 by , 8 years ago
In your case you have the list of nameservers that is actually changing constantly. The link is flapped to propagate that list to the guest. If you want to avoid that, you can enable dns proxy with
VBoxManage modifyvm "VM Name" --natdnsproxy1 on
follow-up: 130 comment:129 by , 4 years ago
Virtualbxox 6.14 problem not resolved. Intel cards not working. Virtio driver makes the virtual machine stucks very often. So we have no other gigabit option for virtualbox ?
my daily syslog