VirtualBox

Ticket #13156 (closed defect: fixed)

Opened 5 years ago

Last modified 3 years ago

'NAT Network' cannot send big files

Reported by: matthijs Owned by:
Component: network/NAT Version: VirtualBox 4.3.12
Keywords: 'NAT Network' Cc:
Guest type: Linux Host type: Windows

Description

It seems 'NAT network' does not implement flow control.

From the attached network trace files one can observe that when flow control is needed, the 'NAT Network' adapter stops working and sends a RST to both ends of the tcp connection.

My setup for demonstrating the problem is as follows:

Laptop with Win7 and VBox 4.3.12 Win7=192.168,178.34
Linux machine with open port 9 (discard), Linux=192.168.178.25
GBit switch between Laptop and Linux
Ubuntu 14.04 running in a VBox on the Laptop, eth0=192.168.178.38, eth1=10.0.3.4
Network interface 2 is set to 'NAT Network' with paravirtualized driver.
On Ubuntu, Linux is routed through the 'NAT Network' interface:

# ip route add 192.168.178.25 via 10.0.2.1 dev eth1 scope link src 10.0.2.4

Wireshark running on both ends of the connection, in VBox Ubuntu and on Linux,
both selecting only packets for port 9

Then the following command will show the problem in the 2 traces:

$ dd if=/dev/zero bs=9820 count=1 | nc 192.168.178.25 9

This will mostly fail,
a smaller number of bytes will always succeed ( < 9800),
and a greater number of bytes will always fail ( > 9900).

Using another adapter type does not make a difference.
Not offloading tcp segmentation does not make a difference.
There are no messages in the VBox log file at the time this happens.

The 2 .pcapng files contain the network traces of the following commands:

$ dd if=/dev/zero bs=9820 count=1 | nc 192.168.178.25 9 && echo OK
1+0 records in
1+0 records out
9820 bytes (9,8 kB) copied, 0,000322761 s, 30,4 MB/s
OK
$ dd if=/dev/zero bs=9800 count=1 | nc 192.168.178.25 9 && echo OK
1+0 records in
1+0 records out
9800 bytes (9,8 kB) copied, 0,000111585 s, 87,8 MB/s
OK
$ dd if=/dev/zero bs=9900 count=1 | nc 192.168.178.25 9 && echo OK
1+0 records in
1+0 records out
9900 bytes (9,9 kB) copied, 0,031919 s, 310 kB/s
OK
$ dd if=/dev/zero bs=99000 count=1 | nc 192.168.178.25 9 && echo OK
1+0 records in
1+0 records out
99000 bytes (99 kB) copied, 0,0124187 s, 8,0 MB/s
OK
$ 

Only the second command does not end with RST message in the .pcapng file.

Of course, the workaround for this problem is to use the good old 'NAT' adapter...

Attachments

NAT-client-4.pcapng Download (2.1 KB) - added by matthijs 5 years ago.
Ubuntu/client side of communication
NAT-server-4.pcapng Download (1.5 KB) - added by matthijs 5 years ago.
Linux/server side of connection

Change History

Changed 5 years ago by matthijs

Ubuntu/client side of communication

Changed 5 years ago by matthijs

Linux/server side of connection

comment:1 Changed 5 years ago by vushakov

Since this is on Windows host I think that it's a manifestation of a bug recently fixed in SVN that was caused by confusion of errno and winsock errors. I can't reproduce this scenario on the latest trunk and 4.3 branch. I will test with older builds to see if I can reproduce it. If you want, I can also provide you a recent 4.3 build to check if it's fixed for you.

comment:2 Changed 5 years ago by matthijs

Thanks for your investigation.
I will check this behavior again when release 4.3.14 is available.

comment:3 follow-up: ↓ 4 Changed 5 years ago by mmokrzycki

I have similar issue, described here: https://www.virtualbox.org/ticket/13164# Could You send me a recent build 4.3 so i could check that feature?

comment:4 in reply to: ↑ 3 Changed 5 years ago by vushakov

Replying to mmokrzycki:

You can get a test 4.3 build here. Please, let us know if it worked for you. Thanks.

comment:5 follow-up: ↓ 6 Changed 5 years ago by mmokrzycki

I've checked this build and it didn't fixed connection problem with downloading files from virtual machine to windows host.

comment:6 in reply to: ↑ 5 Changed 5 years ago by vushakov

Replying to mmokrzycki:

You are right. Simple transfers worked, but the fix mentioned in comment 1 had a problem that would still cause some connections to misbehave. This should be fixed in SVN now (unfortunately, it didn't make it to 4.3.14 RC1).

comment:7 Changed 5 years ago by vushakov

  • Status changed from new to closed
  • Resolution set to fixed

Marking as fixed in 4.3.14. Please reopen if necessary.

comment:8 Changed 3 years ago by kfranken

Same Problem with 5.1.8! When downgrading to 5.1.6 everything works fine.

With 5.1.8 I cannot

wget  https://xxxxxx

I get a lot of this errors: 2016-10-31 15:00:19 (23.3 MB/s) - Read error at byte 16384/39639 (Error in the pull function.). Retrying.

Unencrypted connections seems to be fine (apt-get upgrade works).

Environment:

  • OS X 10.11.6
  • GuestOS: Debian Jessie 8.6

P.S. Sorry for re-opening this issue - I dindn't found a possibility to create a new ticket.

comment:9 Changed 3 years ago by vushakov

There was a regression in "NAT" (NB: not "NAT Network" this bug is about). See #16084.

Note: See TracTickets for help on using tickets.

www.oracle.com
ContactPrivacy policyTerms of Use