Question about URB_FUNCTION_VENDOR_DEVICE

NTDEV
1

Hello,

at first i want to wish all members of this forum a happy new year.

I created a logfile with the program SniffUSB.

I added a part of the logfile at the end of this message.

My problem ist to understand why the function code in the URB header changed from
URB_FUNCTION_VENDOR_DEVICE to URB_FUNCTION_CONTROL_TRANSFER.

Can anybody explain this ?

Thank you very much for all help.

Best regards,

Stefan Witt

[523 ms] >>> URB 7 going down >>>
– URB_FUNCTION_VENDOR_DEVICE:
TransferFlags = 00000003 (USBD_TRANSFER_DIRECTION_IN, USBD_SHORT_TRANSFER_OK)
TransferBufferLength = 00000002
TransferBuffer = f9dfb89c
TransferBufferMDL = 00000000
UrbLink = 00000000
RequestTypeReservedBits = 00000000
Request = 00000090
Value = 00000000
Index = 00000003

[529 ms] UsbSnoop - MyInternalIOCTLCompletion(f71daca0) : fido=00000000, Irp=815bb008, Context=815b0310, IRQL=2
[529 ms] <<< URB 7 coming back IRP Status: 0x00000000, IRP Information: 0x00000000<<<
– URB_FUNCTION_CONTROL_TRANSFER:
PipeHandle = 813ac6f0
TransferFlags = 0000000b (USBD_TRANSFER_DIRECTION_IN, USBD_SHORT_TRANSFER_OK)
TransferBufferLength = 00000002
TransferBuffer = f9dfb89c
TransferBufferMDL = 813a6250
00000000: ff ff
UrbLink = 00000000
SetupPacket =
00000000: c0 90 00 00 03 00 02 00

2

xxxxx@seh.de wrote:

at first i want to wish all members of this forum a happy new year.

I created a logfile with the program SniffUSB.

I added a part of the logfile at the end of this message.

My problem ist to understand why the function code in the URB header changed from
URB_FUNCTION_VENDOR_DEVICE to URB_FUNCTION_CONTROL_TRANSFER.

Can anybody explain this ?

Come on. You should be able to figure this out on your own.

Of the 52 or so URBs currently defined, 29 of them are simply shortcut
aliases for control transfers. URB_FUNCTION_VENDOR_DEVICE is just a
control transfer where bmRequestType is set to 0x20 (for output) or 0xC0
(for input). The host controller driver must change the URB code so
they can all be processed using the same code path.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

3

This is b/c URB_FUNCTION_VENDOR_DEVICE is really a control transfer (as is URB_FUNCTION_CLASS_Xxx, etc). these specialized URBs just control how the 8 byte setup packet is formatted. If you look at wdfusb.h in the KMDF headers and all of the WDF_USB_CONTROL_SETUP_PACKET_XXX_INIT functions, you will see this more clearly.

As to why the actual urb header itself was changed, my guess is that the usb core just remaps all of these to a control URB type and uses the header as a scratch area to do that

D

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@seh.de
Sent: Wednesday, January 07, 2009 2:44 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Question about URB_FUNCTION_VENDOR_DEVICE

Hello,

at first i want to wish all members of this forum a happy new year.

I created a logfile with the program SniffUSB.

I added a part of the logfile at the end of this message.

My problem ist to understand why the function code in the URB header changed from
URB_FUNCTION_VENDOR_DEVICE to URB_FUNCTION_CONTROL_TRANSFER.

Can anybody explain this ?

Thank you very much for all help.

Best regards,

Stefan Witt

[523 ms] >>> URB 7 going down >>>
– URB_FUNCTION_VENDOR_DEVICE:
TransferFlags = 00000003 (USBD_TRANSFER_DIRECTION_IN, USBD_SHORT_TRANSFER_OK)
TransferBufferLength = 00000002
TransferBuffer = f9dfb89c
TransferBufferMDL = 00000000
UrbLink = 00000000
RequestTypeReservedBits = 00000000
Request = 00000090
Value = 00000000
Index = 00000003

[529 ms] UsbSnoop - MyInternalIOCTLCompletion(f71daca0) : fido=00000000, Irp=815bb008, Context=815b0310, IRQL=2
[529 ms] <<< URB 7 coming back IRP Status: 0x00000000, IRP Information: 0x00000000<<<
– URB_FUNCTION_CONTROL_TRANSFER:
PipeHandle = 813ac6f0
TransferFlags = 0000000b (USBD_TRANSFER_DIRECTION_IN, USBD_SHORT_TRANSFER_OK)
TransferBufferLength = 00000002
TransferBuffer = f9dfb89c
TransferBufferMDL = 813a6250
00000000: ff ff
UrbLink = 00000000
SetupPacket =
00000000: c0 90 00 00 03 00 02 00

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

4

> -----Original Message-----

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Wednesday, January 07, 2009 7:35 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Question about URB_FUNCTION_VENDOR_DEVICE

As to why the actual urb header itself was changed, my guess
is that the usb core just remaps all of these to a control
URB type and uses the header as a scratch area to do that

Yes. Recently I looked at it when solving a problem related to reusing
an URB after communication error. The problem was different but it seems
as reusing an URB after return isn’t safe as OS can change several
fields. Anyway, docs doesn’t state anywhere URB will remain the same
after return.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

5

Hello,

thank you very much for your replies.

i know that URB_FUNCTION_VENDOR_DEVICE and the most other requests are a control requests :).
But i did not know ->why<- the usb host controller driver change this. The explanation that the driver must change the URB code because of using the same code path is plausible.

I wrote a virtual usb bus driver and my driver do not change the URB.
Is it better to behave like the windows host controller driver ?

Best regards,

Stefan

6

It depends. Theoretically not because this behaviour is undefined and
caller shouldn’t depend on URB content on return. It is like an IRP, you
can’t reuse it without reinitialization (but it is at least documented).
In addition, this behaviour can change with OS version, SP or even a
hotfix.

On the other hand, you can encounter a software which depends on this
behaviour. In this case typical customers’ reaction is “it works with
standard USB drivers and doesn’t work with yours -> it is your bug”.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@seh.de
Sent: Thursday, January 08, 2009 11:18 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Question about URB_FUNCTION_VENDOR_DEVICE

Hello,

thank you very much for your replies.

i know that URB_FUNCTION_VENDOR_DEVICE and the most other
requests are a control requests :).
But i did not know ->why<- the usb host controller driver
change this. The explanation that the driver must change the
URB code because of using the same code path is plausible.

I wrote a virtual usb bus driver and my driver do not change the URB.
Is it better to behave like the windows host controller driver ?

Best regards,

Stefan

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online
at http://www.osronline.com/page.cfm?name=ListServer