NAT broken since VirtualBox 4.3 => Fixed in SVN

[wzyboy]

I first reported this bug to Arch Linux, here is the original link: ​https://bugs.archlinux.org/task/37575

Since this bug exists in both OSE (compiled by Arch Linux community) and binary version (compiled by Oracle), IMHO this is a "upstream bug", so I re-post the bug report here.

Here is a copy-and-paste of the original bug report:

---

Description: VirtualBox NAT function does not work any more after version 4.3. Instead, it just results in CPU 100% usage in host machine and the whole Qt interface becomes unreponsive. I've tested this on a 2011 HP laptop and a 2013 ThinkPad. The latter one was bought yesterday and had a fresh new installation of Arch Linux + VirtualBox. However, this problem exists regardless of host machine (different laptops) and guest machine (CentOS, Windows XP, Windows 8, etc).

Additional info:

• package version(s): community/virtualbox 4.3.0-3
• config and/or log files etc: VBox.log (Windows XP as guest machine)

Steps to reproduce:

1. Fresh installation of Arch Linux. (Or use existing installation)
2. Install community/virtualbox, community/virtualbox-guest-iso, community/virtualbox-host-modules, aur/virtualbox-ext-oracle.
3. Install any guest OS. (CentOS, Windows XP, Windows 8) Enable "NAT" access. (This is default)
4. Launch guest machine and try to use DHCP to get networking address.
5. CPU 100% usage on host machine and the whole VirtualBox Qt interface become unresponsive.

My (in vain) attempt to debug:

1. Try different guest OS -- not working.
2. Try different host machine -- not working.
3. Disable network interface for guest machine -- working but apprantly guest machine has no networking access.
4. Uncheck "cable connected" for guest machine -- working but apprantly guest machine has no networking access.
5. Use "Bridged network" instead of "NAT" for guest machine -- working
6. Try aur/virtualbox-bin -- not working

I am not very sure if this is a Arch Linux bug or an upstream bug. The changelog of VirtualBox 4.3 *did* mention something about new "NAT Network" function. Maybe the new function broke something...

VBox.log (80.4 KiB)

---

Please refer to the original bug report for VBox.log download and see also its comments for follow-up information.

I've selected "VirtualBox 4.3.0" in "Version" field, but this bug still exists in 4.3.2.

[Frank Mehnert]

Does the same happen if you use one of the .run packages provided on this server?

[wzyboy]

@frank Yes, I've already tried the pre-compiled binary version (.run) provided by virtualbox.org. The same bug exists.

By the way, yesterday I compiled Linux 3.12 and corresponding virtualbox modules but the bug still exists.

[cszeto]

May be related as the subject (NAT) and symptom (100% CPU utilization) are the same or very similar:

Guests can not be saved when configured for NAT and there is no active network connection on the host (e.g. notebook-type system where no connectivity is available). The guests can be started and/or launched from a saved state, but cannot be saved. Any attempt to save the guest while there is no active network connection on the host will result in a very slow save attempt which eventually times out to an abort while spiking the CPU to 100%.

The same situation exists with 4.3 as well as 4.3.2 on 64-bit Ubuntu 10.04 with all current patches.

[dimich]

I also had the same symptoms on one of two computers running VirtualBox 4.3.2 under Arch Linux. I compared logs and configurations and found that computer with non-working VirtualBox had error in /etc/resolv.conf file. It contained 'server 127.0.0.1' line instead of 'nameserver 127.0.0.1'. After fixing /etc/resolv.conf VirtualBox started to work properly. I don't know now does it affect but it works for me now. Hope it can be usefull for you.

[wzyboy]

Replying to dimich:

I also had the same symptoms on one of two computers running VirtualBox 4.3.2 under Arch Linux. I compared logs and configurations and found that computer with non-working VirtualBox had error in /etc/resolv.conf file. It contained 'server 127.0.0.1' line instead of 'nameserver 127.0.0.1'. After fixing /etc/resolv.conf VirtualBox started to work properly. I don't know now does it affect but it works for me now. Hope it can be usefull for you.

You are a life saver! My /etc/resolv.conf was always "nameserver ::1" before, and it worked perfectly, but since VirtualBox 4.3 the NAT is broken as described above. However, when I change it to "nameserver 127.0.0.1" the bug exists no more! I am able to reproduce the bug by setting "nameserver ::1" again...

[wzyboy]

Further information: According to resolv.conf(5), if there is no "nameserver" present in /etc/resolv.conf, the default is to use the name server on the local machine. However, if I comment out the "nameserver" line, this bug still exists. Only "nameserver 127.0.0.1" will do the trick.

[galitsyn]

We localized the problem. The fix will be available in the next maintenance release.

Currently, could you please check if the fix work for you? ​http://www.virtualbox.org/download/testcase/VirtualBox-4.3.3-90530-Linux_x86.run ​http://www.virtualbox.org/download/testcase/VirtualBox-4.3.3-90530-Linux_amd64.run

Thank you for reporting and pointing our attention to the issue!

[cszeto]

Replying to galitsyn:

We localized the problem. The fix will be available in the next maintenance release.

Currently, could you please check if the fix work for you? ​http://www.virtualbox.org/download/testcase/VirtualBox-4.3.3-90530-Linux_x86.run ​http://www.virtualbox.org/download/testcase/VirtualBox-4.3.3-90530-Linux_amd64.run

Thank you for reporting and pointing our attention to the issue!

Ok, just got 4.3.3 running and it looks good! The symptoms that I shared appears to have been addressed successfully with the fix!

[Frank Mehnert]

Thank you for the feedback!

[cszeto]

Replying to frank:

Thank you for the feedback!

Thanks for getting this fixed!

[Frank Mehnert]

Fixed in 4.3.4.