When using NAT interface on Windows host, guest can't receive UDP datagrams larger than 8 KB => Fixed in SVN

[sportzer]

Tested with a Windows 7 host and both Ubuntu and Windows XP guests. The guest type shouldn't make a difference. I was using Python to send and receive datagrams, but the application also shouldn't matter. The VBox.log file doesn't seem to contain any information about what happened.

If I send a UDP datagram from the guest to the host over a NAT interface and then reply with a datagram larger than 8192 bytes, the reply datagram is never received by the guest. If the datagram is 8192 bytes or smaller, the datagram is received as expected.

On Windows, 8192 is the default receive buffer size. After modifying the registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Afd\Parameters\DefaultReceiveWindow to increase the default receive buffer size to 16384, the guest is able to receive datagrams up to 16384 bytes, but datagrams larger than that are still dropped.

My testing (on the same Windows 7 host) shows that Windows can buffer a single datagram larger than its receive buffer size, but ioctlsocket's FIONREAD command will never pass back a value larger than the size of the socket's receive buffer (even if the buffered datagram is larger than that). The logic for receiving UDP datagrams in sorecvfrom() in src/VBox/Devices/Network/slirp/socket.c seems to indicate that VirtualBox is directly using the result of the FIONREAD command for the amount of data to read, which underestimates the size of the next datagram if that datagram is larger than the default receive buffer size.

[vasily Levchenko]

Could you please attach the log file and attach pcap dump of communication guest and on the host?

[sportzer]

Done. In these logs, the host is listening on 192.168.0.107:12345. The guest OS sends a zero byte datagram and the host responds with a 8192 byte datagram followed by a 8193 byte datagram. Only the 8192 byte datagram is received by the guest.

[vasily Levchenko]

Interesting Slirp tries to inform guest (with ICMP) that it can't send response to guest (frame.number == 226) at offset 0x3e is exactly udp header of (frame.number == 219). (It's just remark).

[Valery Ushakov]

This should be fixed in SVN now. Will be in 4.3.16.

[Frank Mehnert]

Fix is part of VBox 4.3.16.