VirtualBox

Ticket #8471 (closed defect: fixed)

Opened 3 years ago

Last modified 2 years ago

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

Reported by: beAutomated Owned by:
Priority: minor 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

VBox.log Download (67.4 KB) - added by emperorcezar 3 years ago.

Change History

comment:1 Changed 3 years ago by frank

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

Changed 3 years ago by emperorcezar

comment:2 Changed 3 years ago by emperorcezar

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 Changed 3 years ago by frank

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

comment:4 Changed 3 years ago by emperorcezar

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 Changed 3 years ago by strags

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 Changed 3 years ago by strags

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 Changed 3 years ago by emperorcezar

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 Changed 3 years ago by strags

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 Changed 3 years ago by emperorcezar

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 follow-up: ↓ 11 Changed 3 years ago by strags

Sweet. Fingers crossed!

comment:11 in reply to: ↑ 10 ; follow-up: ↓ 12 Changed 2 years ago by 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.

comment:12 in reply to: ↑ 11 ; follow-up: ↓ 13 Changed 2 years ago by Hachiman

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

comment:13 in reply to: ↑ 12 ; follow-up: ↓ 14 Changed 2 years ago by 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

comment:14 in reply to: ↑ 13 ; follow-up: ↓ 15 Changed 2 years ago by Hachiman

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.

comment:15 in reply to: ↑ 14 Changed 2 years ago by 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!

comment:16 follow-up: ↓ 17 Changed 2 years ago by 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?

comment:17 in reply to: ↑ 16 Changed 2 years ago by Hachiman

  • Summary changed from NAT Port Forwarding drops requests for LAMP services to NAT 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 Changed 2 years ago by frank

  • Status changed from new to closed
  • Resolution set to fixed
Note: See TracTickets for help on using tickets.

www.oracle.com
ContactPrivacy policyTerms of Use