NAT Port Forwarding drops requests for LAMP services -> fixed in svn.

[Sean Conklin]

On both the Windows 32 and OS X 64 hosts, my guest OS (Win 32) running a LAMP web server on port 8081 drops requests randomly, sometimes causing web pages to not load CSS files or images. The problem was resolved when I switched from NAT to Bridged networking mode. It appears to be a bug with the port forwarding.

[Frank Mehnert]

Without a VBox.log file of such a session with NAT forwarding we can't say much.

[Adam Jenkins]

I've attached a log. This defect happens to me also. Surprisingly only when I use Chrome. If I setup port forwarding through ssh into the machine it doesn't occur, but if the port is forwarded using virtualbox, then it does.

[Frank Mehnert]

So, with port forwarding some packets are randomly dropped but the connection through VBox with port forwarding works in principle?

[Adam Jenkins]

That appeared to be the problem with mine. Only occurred when using Chrome for me. In the network monitor in Chrome I could see it randomly dropping connections.

I'm using port forwarding now and it works without issue.

[Ben Stragnell]

Seems to be happening for me too. It happens far more frequently with Chrome, but also to a lesser extent with Firefox.

I wrote a quick script to fetch the same resource several times in quick succession, and I see fairly frequent timeouts. My guess is that the difference in behaviour between Chrome and Firefox is down to the timing of their HTTP requests.

If I had to make a guess, I'd assume that there's some code in VirtualBox that has to translate incoming BSD-socket interface requests on the host machine, into a series of SYN, SYN/ACK etc... ethernet frames on the guest OS's network adapter. I'm wondering if it's only able to support a limited number of concurrent connection handshakes. Or it could just be buggy :)

[Ben Stragnell]

Looking through the trunk source, I'm wondering if it's down to the solisten() function in socket.c:

    if (   ((s = socket(AF_INET, SOCK_STREAM, 0)) < 0)
        || (setsockopt(s, SOL_SOCKET, SO_REUSEADDR,(char *)&opt, sizeof(int)) < 0)
        || (bind(s,(struct sockaddr *)&addr, sizeof(addr)) < 0)
        || (listen(s, 1) < 0))

The listen() call has a backlog of only 1, which could cause connections to be dropped when many come in at once.

[Adam Jenkins]

I'm ​trying to compile VirtualBox now to change the listen() call and see if it fixes this issue. If it does I'll let you know.

[Ben Stragnell]

I tried for a whole day to get VirtualBox building under Snow Leopard, so I could test this theory. In the end I gave up :( I hope you do better!

[Adam Jenkins]

Looks like someone is already on it, though this ticket isn't assigned to anyone.

The new code looks like this

   /**
     * changing listen(,1->SOMAXCONN) shouldn't be harmful for NAT's TCP/IP stack,
     * kernel will choose the optimal value for requests queue length.
     * @note: MSDN recommends low (2-4) values for bluetooth networking devices.
     */
    if (   ((s = socket(AF_INET, SOCK_STREAM, 0)) < 0)
        || (setsockopt(s, SOL_SOCKET, SO_REUSEADDR,(char *)&opt, sizeof(int)) < 0)
        || (bind(s,(struct sockaddr *)&addr, sizeof(addr)) < 0)
        || (listen(s, pData->soMaxConn) < 0))
    {

Note that I got it to compile by using a set of 64bit openssl libs for config, then editing Autoconfig.kmk to point to the universal ones.

[Ben Stragnell]

Sweet. Fingers crossed!

[the_qa_guy]

Crossing fingers as well.

My current workaround is to create an ssh tunnel with the necessary port forwarding but that's such an ugly solution.

[vasily Levchenko]

Please let me know if you need binaries (not forgetting to point OS and bitness :) ) for testing.

[the_qa_guy]

Replying to Hachiman:

Please let me know if you need binaries (not forgetting to point OS and bitness :) ) for testing.

Binaries of a 4.0.x virtualbox for Mac OS X 64 including this fix would be greatly appreciated! Unfortunately 4.1.x wouldn't help me since we're using vagrant to setup & provision the VM which is incompatible with virtualbox > 4.0.x

[vasily Levchenko]

Replying to the_qa_guy:

Replying to Hachiman:

Please let me know if you need binaries (not forgetting to point OS and bitness :) ) for testing.

Binaries of a 4.0.x virtualbox for Mac OS X 64 including this fix would be greatly appreciated! Unfortunately 4.1.x wouldn't help me since we're using vagrant to setup & provision the VM which is incompatible with virtualbox > 4.0.x

Sorry for delay, could you please try this bits ​VBoxDD.dylib, this is build of VBoxDD.dylib of 4.0.14 with applied changes to configure bind(2) call. For testing you need replace original VBoxDD.dylib in your VirtualBox installation. For configuration you need execute one of the following commands:

# VBoxManage set extradata <vmname> "VBoxInternal/Devices/e1000/0/LUN#0/Config/SoMaxConnection" 10

or

# VBoxManage set extradata <vmname> "VBoxInternal/Devices/pcnet/0/LUN#0/Config/SoMaxConnection" 10

depending on your guest vm's configuration.

[the_qa_guy]

Thank you very much!

First tests on my computer look very promising, I'll roll this out to coworkers that experienced the issue more prominent than I did. I'll let you know about the results!

[the_qa_guy]

Everything is still looking great, so apparently the fix helped.

Thank you very much for that.

Will this be included in the regular VirtualBox versions sometime soon?

[vasily Levchenko]

Replying to the_qa_guy:

Everything is still looking great, so apparently the fix helped.

Thank you very much for that.

Will this be included in the regular VirtualBox versions sometime soon?

Thanks for feedback, version will be available in the next maintenance release.