Custom Query (16363 matches)
Results (1987 - 1989 of 16363)
| Ticket | Resolution | Summary | Owner | Reporter |
|---|---|---|---|---|
| #12136 | fixed | When using NAT interface on Windows host, guest can't receive UDP datagrams larger than 8 KB => Fixed in SVN | ||
| Description |
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. |
|||
| #14450 | fixed | Shared Folders implementation have a bug with access rights for reading file attributes | ||
| Description |
Shared Folders implementation have a bug with access rights for reading file attributes Host: Windows Guest: Windows When you are trying from the GUEST machine to open files on HOST-shared folder for reading attributes with the rights [FILE_READ_ATTRIBUTES | SYNCHRONIZE] in practice (on the HOST machine) it tries to open files with [GENERIC_READ] right, so the code that shown below is not working correctly (the second try to open a file will fail with SHARING_VIOLATION error): Request for reading file attributes is differ from a simple file reading, because in case of attribute reading "file share reading" must be ignored. Here is a sample program:
#include <stdio.h>
#include <windows.h>
int main(int argc, char *argv[])
{
if (argc < 2)
{
printf("ERROR: No filename specified!\n");
return -1;
}
HANDLE h1 = CreateFile(argv[1], GENERIC_READ | GENERIC_WRITE, 0, NULL, OPEN_EXISTING, 0, NULL);
printf("Le1 = %u\n", GetLastError());
HANDLE h2 = CreateFile(argv[1], FILE_READ_ATTRIBUTES | SYNCHRONIZE, FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE, NULL, OPEN_EXISTING, 0, NULL);
printf("Le2 = %u\n", GetLastError());
if (h1 != INVALID_HANDLE_VALUE)
{
CloseHandle(h1);
}
if (h2 != INVALID_HANDLE_VALUE)
{
CloseHandle(h2);
}
return 0;
}
To checkout access rights and flags of opening file on HOST machine and GUEST machine you can use ProcessMonitor utility: https://technet.microsoft.com/en-us/library/bb896645.aspx Here is a sample of wrong work: On HOST machine: 17:54:16.1144379 VirtualBox.exe 3196 IRP_MJ_CREATE D:\tmp\file.pdb SHARING VIOLATION Desired Access: Generic Read, Disposition: Open, Options: Synchronous IO Non-Alert, Non-Directory File, Attributes: N, ShareMode: Read, Write, AllocationSize: n/a But inside the VM (GUEST machine) it was opened with following rights/flags: 18:09:16,6181478 mspdbsrv.exe 2472 IRP_MJ_CREATE \\VBOXSVR\shared\file.pdb SHARING VIOLATION Desired Access: Read Attributes, Synchronize, Disposition: Open, Options: Synchronous IO Non-Alert, Non-Directory File, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a What must be fixed (here is a code that must be fixed/modified) -- all modifications are marked with "<=" sign: 1) file: .\src\VBox\HostServices\SharedFolders\vbsf.cpp function: static int vbsfConvertFileOpenFlags(unsigned fShflFlags, RTFMODE fMode, SHFLHANDLE handleInitial, uint32_t *pfOpen) case SHFL_CF_ACCESS_NONE:
{
/** @todo treat this as read access, but theoretically this could be a no access request. */
fOpen |= RTFILE_O_READ; <========= (!) This must be deleted; opening file for reading attributes is NOT a reading a file!
Log(("FLAG: SHFL_CF_ACCESS_NONE\n"));
break;
}
2) file: .\src\VBox\Runtime\r3\fileio.cpp function: int rtFileRecalcAndValidateFlags(uint64_t *pfOpen) switch (fOpen & RTFILE_O_ACCESS_MASK)
{
<= (!) add:
<= case 0: break; 0 - allowed value (file is opened to access attributes, but not for reading/writing a data)
case RTFILE_O_READ:
fOpen |= g_fOpenReadSet;
fOpen &= ~g_fOpenReadMask;
break;
case RTFILE_O_WRITE:
fOpen |= g_fOpenWriteSet;
fOpen &= ~g_fOpenWriteMask;
break;
case RTFILE_O_READWRITE:
fOpen |= g_fOpenReadWriteSet;
fOpen &= ~g_fOpenReadWriteMask;
break;
default:
AssertMsgFailed(("Invalid RW value, fOpen=%#llx\n", fOpen));
return VERR_INVALID_PARAMETER;
}
3) file: .\src\VBox\Runtime\r3\win\fileio-win.cpp function: RTR3DECL(int)·RTFileOpen(PRTFILE·pFile,·const·char·*pszFilename,·uint64_t·fOpen) DWORD dwDesiredAccess; <=========== (!) add = 0 (init value)
switch (fOpen & RTFILE_O_ACCESS_MASK)
{
<= (!) add:
<= case 0: break; 0 - allowed value (file is opened to access attributes, but not for reading/writing a data)
case RTFILE_O_READ:
dwDesiredAccess = FILE_GENERIC_READ; /* RTFILE_O_APPEND is ignored. */
break;
case RTFILE_O_WRITE:
dwDesiredAccess = fOpen & RTFILE_O_APPEND
? FILE_GENERIC_WRITE & ~FILE_WRITE_DATA
: FILE_GENERIC_WRITE;
break;
case RTFILE_O_READWRITE:
dwDesiredAccess = fOpen & RTFILE_O_APPEND
? FILE_GENERIC_READ | (FILE_GENERIC_WRITE & ~FILE_WRITE_DATA)
: FILE_GENERIC_READ | FILE_GENERIC_WRITE;
break;
default:
AssertMsgFailed(("Impossible fOpen=%#llx\n", fOpen));
return VERR_INVALID_PARAMETER;
}
|
|||
| #8701 | fixed | Fragmented IP packages are corrupted when using NAT | ||
| Description |
I'm running Windows 7 with a Windows 7 virtual box. Inside the virtual box I'm trying to set up a IPSec session, however since the session failed to connect I was forced to network debug to find the problem. The IPSec uses UDP hole punching to connect through NAT. I started two Wireshark sessions, one in the host machine and one in the virtual box. After an hour or so I found the problem. The session died from a fragmentation timeout after 3 fragmented packages where failed to be reassembled. In the attached image you can see the 6 packages coming (3 datagrams with 2 fragments each) in from the remote IPSec server to the left (the remote IP has been redacted as it's classified - the black box contains the same remote IP.) To the right you can see wireshark running in the virtual machine. I have aligned the logs so the packages matches each other top-down. Interestingly enough the NAT rewrote the ID's in the IP header for some reason. Now the problem as you can see is that the remote IP is corrupted and becomes "10.0.2.2" in every fragment after the first - therefore the virtual machine cannot reassemble them since they are coming from different hosts. Please fix this. I did not attach the VBox.log since it did not contain any relevant information from what I could see. I tried several times using different virtual network interfaces. The problem as I see it is that your NAT-translator corrupts the packages. |
|||

