USBPCap did not recognize URB Function code (Razer Tartarus Pro on Windows)

[NessDan]

I was checking to see what a USB handshake looked like for my Razer Tartarus Pro and 4 packets arrived that told me to create an issue here :)

The full message:

    URB transfer type: Unknown (0xff)
        [Expert Info (Error/Malformed): USBPcap did not recognize URB Function code (report to desowin.org/USBPcap)]
            [USBPcap did not recognize URB Function code (report to desowin.org/USBPcap)]
            [Severity level: Error]
            [Group: Malformed]

Here are the packets & data:

[berkakinci]

I also have the same lines at the same time. Mine is for two different brand touch screens.

E.g:

    URB transfer type: Unknown (0xff)
        [Expert Info (Error/Malformed): USBPcap did not recognize URB Function code (report to desowin.org/USBPcap)]
            [USBPcap did not recognize URB Function code (report to desowin.org/USBPcap)]
            [Severity level: Error]
            [Group: Malformed]
    Packet Data Length: 0

Raw packet:

0000   1b 00 20 1a 39 99 0d 8a ff ff 00 00 00 00 2a 00
0010   00 03 00 04 00 00 ff 00 00 00 00

Sorry, I realized, after a little digging, this is probably the pretty version of what you need:

    URB Function: URB_FUNCTION_GET_MS_FEATURE_DESCRIPTOR (0x002a)

[berkakinci]

I believe this and #113 are exact duplicates. The URB Function apparently not handled are the same: "0x002a"

I was initially discounting these as "empty" packets. Now I'm thinking the 0-byte payload may be because USBPcap doesn't implement or attempt to understand them.

I'm attaching a pcap file demonstrating one instance. USBHID MultiTouch Overlay.zip Unfortunately, if my suspicion is correct, the raw data you need probably never got into the pcap file.

[desowin]

I believe this and #113 are exact duplicates. The URB Function apparently not handled are the same: "0x002a"

And both will be fixed when #78 gets implemented.

I was initially discounting these as "empty" packets. Now I'm thinking the 0-byte payload may be because USBPcap doesn't implement or attempt to understand them.

That's indeed the case.

I'm attaching a pcap file demonstrating one instance. USBHID MultiTouch Overlay.zip

Actual capture is way better than screenshots and/or packet text copies. I wish other reporters realized that.

Unfortunately, if my suspicion is correct, the raw data you need probably never got into the pcap file.

They never did, the change requires updating USBPcapDriver. The reassuring fact is that URB_FUNCTION_GET_MS_FEATURE_DESCRIPTOR is not crucial for dissecting the payload in Wireshark. MS Feature Descriptors are mostly used for automatic driver installation on Windows, other OS do not even read them at all.

[berkakinci]

When I get back in the lab, I'll try to get you a real hardware capture to go along with a pcap for these. It'll be captured on a Totalphase Beagle USB 480.

Let me know if you want the conversation to continue on #78 or here, or another related thread.

Like you said, this doesn't seem too critical. (BTW, in my case, I'm not trying to port any drivers to another OS. I'm trying to replicate behavior of a HID device. It's causing a failure for a customer, and we can't get the device in the lab.

[desowin]

When I get back in the lab, I'll try to get you a real hardware capture to go along with a pcap for these. It'll be captured on a Totalphase Beagle USB 480.

Thanks. However, the raw packet capture without corresponding URB information is of limited use. Basically what you should observe on the bus is request for string descriptor 0xEE. The real question is how to compute the SETUP DATA0 packet contents and the response payload from the information available in URB structure during the capture.

Let me know if you want the conversation to continue on #78 or here, or another related thread.

Here is fine, there is mention in the other thread so interested people can see it.

Like you said, this doesn't seem too critical. (BTW, in my case, I'm not trying to port any drivers to another OS. I'm trying to replicate behavior of a HID device. It's causing a failure for a customer, and we can't get the device in the lab.

URB_FUNCTION_GET_MS_FEATURE_DESCRIPTOR request should have no effect on HID device operation. If the request for OS descriptor is causing issue, then the device USB implementation is seriously wrong. From device perspective this is simply a string descriptor request.

[berkakinci]

Thanks. However, the raw packet capture without corresponding URB information is of limited use. Basically what you should observe on the bus is request for string descriptor 0xEE. The real question is how to compute the SETUP DATA0 packet contents and the response payload from the information available in URB structure during the capture.

I forgot that you're not capturing the URB at all in these cases. Is there any way for me to get USBPcap to dump out the raw URB so you can see it side-by-side?

URB_FUNCTION_GET_MS_FEATURE_DESCRIPTOR request should have no effect on HID device operation. If the request for OS descriptor is causing issue, then the device USB implementation is seriously wrong. From device perspective this is simply a string descriptor request.

I don't think this is related to the issue I'm chasing. I just wanted to improve USBPcap while I'm actively using it. The "failure" I mentioned is probably in the OS drivers or modules.

[berkakinci]

I forgot that you're not capturing the URB at all in these cases. Is there any way for me to get USBPcap to dump out the raw URB so you can see it side-by-side?

If there is a way to get the software side of what's happening, I'll do this double-capture. Otherwise, it seems pointless. As you said; this isn't critical either.

[desowin]

I forgot that you're not capturing the URB at all in these cases. Is there any way for me to get USBPcap to dump out the raw URB so you can see it side-by-side?

If there is a way to get the software side of what's happening, I'll do this double-capture. Otherwise, it seems pointless. As you said; this isn't critical either.

You might try to run https://github.com/MartinDrab/IRPMon however, I have had no luck with it on Windows 10. Inside IRPMon you can select watching USB class (lower). I don't quite know what information it includes.

Another option would be to dump the information in USBPcapDriver, but that would require compiling modified driver yourself.

[berkakinci]

compiling modified driver yourself.

Hah! That's not going to happen. I don't have the toolchain for that, and little interest in setting it up. I use Windows, but stay away from writing code for it. I had to download a 1.5GB "WDK" just to see the "URB_FUNCTION..." define mentioned here... I wasn't pleased.

I don't mind running it if you make a debug version of USBPCap.

I'm on Windows10, so IRPMon probably won't work for me either.

[NessDan]

I had to download a 1.5GB "WDK" just to see the "URB_FUNCTION..." define mentioned here...

What download was it? I'm having this same issue.

[berkakinci]

Windows Driver Kitwikipedia.orgIf you’re asking specific version, I don’t know.On Sep 11, 2023, at 22:11, Daniel Kaspo @.***> wrote:

I had to download a 1.5GB "WDK" just to see the "URB_FUNCTION..." define mentioned here...

What download was it? I'm having this same issue. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.***>