VirtualBox

Opened 13 years ago

Closed 12 years ago

#8471 closed defect (fixed)

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

Reported by: Sean Conklin Owned by:
Component: network/NAT Version: VirtualBox 4.0.4
Keywords: server Cc:
Guest type: Windows Host type: Windows

Description

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.

Attachments (1)

VBox.log (67.4 KB ) - added by Adam Jenkins 13 years ago.

Download all attachments as: .zip

Change History (19)

comment:1 by Frank Mehnert, 13 years ago

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

by Adam Jenkins, 13 years ago

Attachment: VBox.log added

comment:2 by Adam Jenkins, 13 years ago

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.

comment:3 by Frank Mehnert, 13 years ago

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

comment:4 by Adam Jenkins, 13 years ago

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.

comment:5 by Ben Stragnell, 13 years ago

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 :)

comment:6 by Ben Stragnell, 13 years ago

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.

comment:7 by Adam Jenkins, 13 years ago

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.

comment:8 by Ben Stragnell, 13 years ago

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!

comment:9 by Adam Jenkins, 13 years ago

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.

comment:10 by Ben Stragnell, 13 years ago

Sweet. Fingers crossed!

in reply to:  10 ; comment:11 by the_qa_guy, 12 years ago

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.

in reply to:  11 ; comment:12 by vasily Levchenko, 12 years ago

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

in reply to:  12 ; comment:13 by the_qa_guy, 12 years ago

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

in reply to:  13 ; comment:14 by vasily Levchenko, 12 years ago

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.

in reply to:  14 comment:15 by the_qa_guy, 12 years ago

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!

comment:16 by the_qa_guy, 12 years ago

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?

in reply to:  16 comment:17 by vasily Levchenko, 12 years ago

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

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.

comment:18 by Frank Mehnert, 12 years ago

Resolution: fixed
Status: newclosed
Note: See TracTickets for help on using tickets.

© 2023 Oracle
ContactPrivacy policyTerms of Use