Opened 9 years ago
Last modified 9 years ago
#15282 new defect
USB subsystem or USB logging is broken
Reported by: | Pingu | Owned by: | |
---|---|---|---|
Component: | USB | Version: | VirtualBox 5.0.16 |
Keywords: | Cc: | ||
Guest type: | Linux | Host type: | Mac OS X |
Description
The USB subsystem is broken either itself or the logging.
I have a USB device that supports CDC and UVC. Putting UVC aside, I want to talk CDC with the device, but only get garbage. For that reason I ran usbmon on the Linux guest and USB logging from VirtualBox to identify the problem. The USB log from VirtualBox is garbage. Unfortunatly, I can not verify if it is only the logging or f VirtualBox send this out.
I attached the plain text log from the guest and from Virtual Box. Both should be equal, but its not.
The most obvoius is packet number 107 in guest and number 104 in host:
Guest
Frame 107: 71 bytes on wire (568 bits), 71 bytes captured (568 bits) on interface 0 USB URB URB setup bmRequestType: 0x21 bRequest: 32 wValue: 0x0000 wIndex: 2 wLength: 7 Leftover Capture Data: 00c20100000008
Host
Frame 104: 72 bytes on wire (576 bits), 64 bytes captured (512 bits) on interface 0 USB URB URB setup bmRequestType: 0x21 0... .... = Direction: Host-to-device .01. .... = Type: Class (0x01) ...0 0001 = Recipient: Interface (0x01) bRequest: 32 wValue: 0x0000 wIndex: 2 (0x0002) wLength: 7 No. Device Source Destination Protocol Length Info URB type URB transfer type Data length [bytes] Leftover Capture Data bString 105 3 0.3.0 host USB 72 URB_CONTROL out[Packet size limited during capture] URB_COMPLETE URB_CONTROL 0 Frame 105: 72 bytes on wire (576 bits), 64 bytes captured (512 bits) on interface 0 USB URB [Packet size limited during capture: USB truncated] No. Device Source Destination Protocol Length Info URB type URB transfer type Data length [bytes] Leftover Capture Data bString 106 3 host 0.3.0 USB 71 Unknown type c2 Request URB_SUBMIT URB_CONTROL 0 Frame 106: 71 bytes on wire (568 bits), 64 bytes captured (512 bits) on interface 0 USB URB URB setup bmRequestType: 0x00 0... .... = Direction: Host-to-device .00. .... = Type: Standard (0x00) ...0 0000 = Recipient: Device (0x00) bRequest: Unknown (194) wValue: 0x0001 wIndex: 0 (0x0000) wLength: 8
Here it can be seen that the "left over capture data", the actual data of the USB request (setting baudrate to 115200 bps) is recognised as a 2nd USB packet. As 0xC2 is detected as request type, 0x01 as wValue, and 0x08 as wLength instead as part of the packet number 104.
Attachments (3)
Change History (6)
by , 9 years ago
Attachment: | VBox.log.gz added |
---|
by , 9 years ago
Attachment: | usb201603292127_guest_linux.txt.gz added |
---|
by , 9 years ago
Attachment: | usb201603292127_host_macosx.txt.gz added |
---|
comment:1 by , 9 years ago
comment:2 by , 9 years ago
Pingu, the code is correct. The sizeof operator evaluates the object size which is known at compile time. So pExtra has the type PVUSBCTRLEXTRA and the compiler knows the size of the object which pExtra will point to (VUSBCTRLEXTRA) and therefore also the size of a part of this object (VUSBURB).
On looking through the source I found something irritating. I don't know if it is related to that bug or not.
In VUSBUrb.cpp the following is written:
The local variable "pExtra" is defined and still unintialized. Then while evaluating the size to be allocated, that uninitilzed pointer is used with "pExtra->Urb.abData". That seems to be completely wrong. I don't know what is correct there. May be it should be "pUrb->Urb.abData" or some other static value.