Ask Your Question

What constitutes a packet a Wireshark USB bus capture of an isochronous endpoint?

asked 2023-06-06 18:37:23 +0000

jnagy gravatar image

I am working with a USB device which uses UAC to transfer audio data to the USB host and it does this through an isochronous endpoint. I understand that these endpoints are polled on regular intervals but I am having difficulty understanding what my Wireshark captures are actually capturing. Looking at the USB descriptor, it states that the interface sends audio in 96 byte packets but each capture on Wireshark contains 10 packets of 96 bytes. Why could that be? Does Wireshark capture multiple ISO packets and combine them?

The device also has a bulk video endpoint and it has a single packet capture that is 16kB so I am confused why audio is not showing one packet per 96 bytes of data.

Any help understanding what the packet window is showing in the bottom left of the following photo would be greatly appreciated.

ISO endpoint capture

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted

answered 2023-06-07 10:53:29 +0000

desowin gravatar image

The USB software sniffers (here: USBPcap) capture URBs and not the raw USB packets. URB is USB Request Block and is what the device driver (here: USB Audio driver) submits to host controller driver (here: most likely xHCI). Each and every URB is always shown in Wireshark as two "packets":

  • "submit" one always from host to endpoint, regardless of endpoint (i.e. actual data flow) direction
  • "complete" one always from endpoint to host, regardless of endpoint (i.e. actual data flow) direction

Expand the "USB URB" in Protocol Tree to find the matching "submit" for the visible "complete" packet. For working streaming the driver would really need to have multiple URBs rolled over - otherwise the host OS latencies would be clearly audible. In the screenshot "packet" 49063 is most likely resubmitting the just completed URB, but likely there are at least 2 "IN" URBs involved - you can check how many URBs are involved by looking at usb.irp_id (USBPcap) or usb.urb_id (usbmon) in the "packets" addressed to endpoint in question.

Queuing multiple URBs is not really enough to cope up USB Audio timing. For Full-Speed device we are talking IN DATA packet every 1 ms and for High-Speed it IN DATA packet every 125 us (=1/8 ms; not to mention high-bandwidth endpoints where there can be up to three DATA packets every microframe). In your capture USB Audio driver is grouping the transfers in 10 frames chunks. Doing so essentially reduces CPU overhead 10 times, because makes the "top level handling" happen only once for every 10 actual packets. This combined together with multiple URBs is what makes host possible to cope up with the USB Audio timing.

You noted that individual packet is 96 bytes. This is not quite accurate. What you mean is that there is 96 bytes of payload every bInterval frames. The actual DATA0 packet you would see on bus if you captured in hardware would be 1 (DATA0) + 96 (actual payload) + 2 (CRC16) bytes long. You don't see the SOFs at all when capturing in software, but each "USB isochronous packet" shown in the screenshot is one bInterval apart from the previous one. If the packet would fail (e.g. CRC error) you would see different ISO USBD status than USBD_STATUS_SUCCESS.

Similar story applies to the bulk endpoint. You see 16407 bulk in, but that's definitely more than bulk endpoint wMaxPacketSize (which is 8 or 16 or 32 or 64 on Full-Speed and 512 on High-Speed device). If you looked at the data with hardware sniffer you would see alternating DATA0/DATA1 packets with wMaxPacketSize bytes of payload. The reassembly is handled by host controller and USBPcap (or usbmon if on Linux) never really sees the individual DATA packets.

If you want to see what the actual USB packets are being transmitted on the bus and how that compares to URBs, check out the USB Link Layer Sample Captures that contain multiple pcap showing exactly the same traffic captured by different sniffers.

edit flag offensive delete link more


Thanks for the help! I had just a few follow up questions:

What do you mean by "resubmitting the just completed URB"? You mean that there are several URB 'chains' that are sent to the device, the device sends data back in a response and then that same URB is sent back to the device for another response? I took a peek at the USB URB tree and noticed that "IRP ID" is the same for a chain of requests. Looking at another capture, I can see there are about 18 URB INs sent by the host to the device between any given request and its response. Is this what you mean by multiple URBs being "rolled over".

Is it typically the device or driver doing this 10 packet grouping or can it vary?

The device is using USB 3.0 and the descriptor states that wMaxPacketSize is 1024 and ...(more)

jnagy gravatar imagejnagy ( 2023-06-07 13:21:48 +0000 )edit

URBs happen entirely at host side and device has absolutely no idea that there was URB, what URB contents were and how many URBs there were. The class driver maintains the URB chain and just uses the same URB structures over and over in circular manner (for continuous streaming it is more effective just to reuse just completed URB than to free the used URB and allocate new one). The 18 URB INs, if they all are to the same endpoint, would be the "URB chain" that gets "rolled over".

The grouping is done entirely by the device driver and it varies on the device driver in question. It is almost entirely up to the device driver (host only limits the absolute maximum which is generally really high). For Windows you can check _URB_ISOCH_TRANSFER structure documentation.

DATA0 and DATA1 packets are on USB 2.0 bus, therefore Low/Full/High ...(more)

desowin gravatar imagedesowin ( 2023-06-09 05:12:50 +0000 )edit

Submitting IN URB roughly to "please start issuing IN tokens, give me the data after that many DATA packets are received (or a short packet on bulk happens, meaning device won't send more data in this transfer; of course there are exceptions managed by URB flags)".

desowin gravatar imagedesowin ( 2023-06-09 05:21:52 +0000 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower


Asked: 2023-06-06 18:37:23 +0000

Seen: 169 times

Last updated: Jun 07