VirtualBox

Custom Query (16363 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


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 sportzer
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 sporaw
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:

  • when all is correct it must print Le1 = 0, Le2 = 0
  • if you will try to sumbit a file that is located on shared folder, the second open will fail with sharing violation error.
#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 spooc
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.

Batch Modify
Note: See TracBatchModify for help on using batch modify.
Note: See TracQuery for help on using queries.

© 2024 Oracle Support Privacy / Do Not Sell My Info Terms of Use Trademark Policy