Update: I just realized I'd made a typo -- the unknown request is actually a get_min request.
On 7/2/21, Ethin Probst <harlydavid...@gmail.com> wrote: > Thank you for all that information, both of you. I didn't realize that > VirtIO sound would be so complicated. The specification seemed simple > enough -- but, alas, all things seem simple until you actually go and > try to implement them. > > I did manage to retrieve a packet dump, from both myself and from > somebody else that Leif contacted. The one from myself was from a USB > mixer that I have -- its how my audio headphones work, and that > generated far too many packets -- well over 5,000 at least. Utilizing > display filters wasn't much of a help either -- it doesn't seem like > my mixer makes available an audio device class descriptor anywhere, > which is odd because it should. But I also might not have been > filtering it properly. The other packet dump was sort-of helpful, but > did contain some confusing elements: > > * There were four unknown URB transfer types (0x7F) that Wireshark > claimed were "malformed". I asked around on the OSDev.org forum and I > don't think anyone recognizes that either. > * The primary init sequence was understandable, along with the get > string requests, but after that there were a bunch of URB control > transfers from device-to-host and some requests from host-to-device > containing data that I didn't understand. I wasn't sure what those > were for. They looked something like this: > > Frame 29: 36 bytes on wire (288 bits), 36 bytes captured (288 bits) on > interface wireshark_extcap1868, id 0 > Interface id: 0 (wireshark_extcap1868) > Interface name: wireshark_extcap1868 > Encapsulation type: USB packets with USBPcap header (152) > Arrival Time: Jul 1, 2021 02:21:45.291271000 CDT > [Time shift for this packet: 0.000000000 seconds] > Epoch Time: 1625124105.291271000 seconds > [Time delta from previous captured frame: 0.000008000 seconds] > [Time delta from previous displayed frame: 0.000008000 seconds] > [Time since reference or first frame: 0.035324000 seconds] > Frame Number: 29 > Frame Length: 36 bytes (288 bits) > Capture Length: 36 bytes (288 bits) > [Frame is marked: False] > [Frame is ignored: False] > [Protocols in frame: usb] > USB URB > [Source: host] > [Destination: 2.7.0] > USBPcap pseudoheader length: 28 > IRP ID: 0xffffa90f548b8a20 > IRP USBD_STATUS: USBD_STATUS_SUCCESS (0x00000000) > URB Function: URB_FUNCTION_CLASS_INTERFACE (0x001b) > IRP information: 0x00, Direction: FDO -> PDO > 0000 000. = Reserved: 0x00 > .... ...0 = Direction: FDO -> PDO (0x0) > URB bus id: 2 > Device address: 7 > Endpoint: 0x80, Direction: IN > 1... .... = Direction: IN (1) > .... 0000 = Endpoint number: 0 > URB transfer type: URB_CONTROL (0x02) > Packet Data Length: 8 > [Response in: 30] > Control transfer stage: Setup (0) > [bInterfaceClass: Audio (0x01)] > Setup Data > bmRequestType: 0xa1 > 1... .... = Direction: Device-to-host > .01. .... = Type: Class (0x1) > ...0 0001 = Recipient: Interface (0x01) > bRequest: 130 > wValue: 0x0201 > wIndex: 1536 (0x0600) > wLength: 2 > > Frame 30: 30 bytes on wire (240 bits), 30 bytes captured (240 bits) on > interface wireshark_extcap1868, id 0 > Interface id: 0 (wireshark_extcap1868) > Interface name: wireshark_extcap1868 > Encapsulation type: USB packets with USBPcap header (152) > Arrival Time: Jul 1, 2021 02:21:45.291389000 CDT > [Time shift for this packet: 0.000000000 seconds] > Epoch Time: 1625124105.291389000 seconds > [Time delta from previous captured frame: 0.000118000 seconds] > [Time delta from previous displayed frame: 0.000118000 seconds] > [Time since reference or first frame: 0.035442000 seconds] > Frame Number: 30 > Frame Length: 30 bytes (240 bits) > Capture Length: 30 bytes (240 bits) > [Frame is marked: False] > [Frame is ignored: False] > [Protocols in frame: usb] > USB URB > [Source: 2.7.0] > [Destination: host] > USBPcap pseudoheader length: 28 > IRP ID: 0xffffa90f548b8a20 > IRP USBD_STATUS: USBD_STATUS_SUCCESS (0x00000000) > URB Function: URB_FUNCTION_CONTROL_TRANSFER (0x0008) > IRP information: 0x01, Direction: PDO -> FDO > 0000 000. = Reserved: 0x00 > .... ...1 = Direction: PDO -> FDO (0x1) > URB bus id: 2 > Device address: 7 > Endpoint: 0x80, Direction: IN > 1... .... = Direction: IN (1) > .... 0000 = Endpoint number: 0 > URB transfer type: URB_CONTROL (0x02) > Packet Data Length: 2 > [Request in: 29] > [Time from request: 0.000118000 seconds] > Control transfer stage: Complete (3) > [bInterfaceClass: Audio (0x01)] > CONTROL response data: 00d3 > > According to the audio 1.0 specification, this is a "get_cur" request > (appendix 9: Audio Class-Specific Request Codes). However, I wasn't > really sure what it was trying to get. The spec (SEC. B.3.3.3) > indicates that this is an input terminal descriptor. I'll continue > following this chain of requests and responses and see if I can figure > out exactly what its doing -- I need to map the request IDs onto their > actual values since Wireshark isn't doing that for me automatically. > > On 7/2/21, Michael Brown <mc...@ipxe.org> wrote: >> On 02/07/2021 10:41, Michael Brown wrote: >>> UsbIo->UsbControlTransfer(UsbIo, &Req, EfiUsbDataIn, >>> PcdGet32 (PcdUsbTransferTimeoutValue), >>> &Header, sizeof(Header), &Status); >>> >>> (Error handling etc omitted for brevity) >>> >>> That would get you the first 8 bytes of the class-specific AC interface >>> header descriptor. You would then need to extract the TotalLength >>> field, allocate that length of memory, and repeat the >>> UsbControlTransfer() call to fetch the full-length descriptor into the >>> newly allocated block. >>> >>> Hope that helps, >> >> BTW, in case you aren't already aware of this: wireshark is pretty good >> at dissecting USB traffic. You can capture it by doing a "modprobe >> usbmon", after which you'll see a number of usbmonN devices show up in >> the wireshark interface list. Try them each in turn until you find >> which one corresponds to the host controller to which your device is >> attached. >> >> My normal method for developing or debugging iPXE USB drivers will >> typically involve using wireshark to capture the USB traffic that >> happens when the device is being used by a known-working driver (e.g. >> the Linux driver for that device) and comparing it to the traffic that >> happens when I'm using my own driver (via USB pass-through in a VM). >> This is often a lot faster than trying to pull together all of the >> information from the multiple USB spec documents. >> >> Good luck! >> >> Michael >> > > > -- > Signed, > Ethin D. Probst > -- Signed, Ethin D. Probst -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#77455): https://edk2.groups.io/g/devel/message/77455 Mute This Topic: https://groups.io/mt/83904983/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
