'NAT Network' cannot send big files

[Matthijs Melchior]

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...

[Matthijs Melchior]

Ubuntu/client side of communication

[Matthijs Melchior]

Linux/server side of connection

[Valery Ushakov]

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.

[Matthijs Melchior]

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

[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?

[Valery Ushakov]

Replying to mmokrzycki:

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

[mmokrzycki]

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

[Valery Ushakov]

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

[Valery Ushakov]

Marking as fixed in 4.3.14. Please reopen if necessary.

[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.

[Valery Ushakov]

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