On Thursday, May 16th, 2024 at 00:19, Lars Melin <larsm17@xxxxxxxxx> wrote: > On 2024-05-16 05:12, Ethin Probst wrote: > > > On Sunday, May 12th, 2024 at 09:13, Alan Stern stern@xxxxxxxxxxxxxxxxxxx wrote: > > > > > ... > > > > > Most likely, Windows sends some firmware to the device (which it needs > > > in order to run properly) and then restarts the device. > > > > I don't believe this is happening after trying to dig into the > > captures a bit more. The firmware blobs that are in the archive are > > over 100000 bytes, and though there are some significantly large > > transfers, there isn't a single transfer that is the size of the > > firmware blob. I can't tell for certain though; VirtualBox truncated > > those large frames, so I'm uncertain what data is in them. > > > The .inf files in your drivers directory clearly tells the difference > between the two USB Id's. > The description of 2b5a:000c is "UAD2 Arrow Firmware Loader" while the > description for 2b5a:000d is "Universal Audio Apollo Solo USB" so there > is no doubt what the initial pid 000c is intended for. Ah, I didn't look too deeply into those, I should've! :) > There is nothing in your packet captures indicating a firmware transfer > but that does not necessarily have to happen, there might just be a > check of what firmware version is currently loaded in your audio > hardware and if their isn't a more recent one in the firmware directory > then everything is ok. The trick then is to figure out what makes it make the transition. I don't know if it's vendor-specific or not and I'm uncertain how to "replay" the packets, particularly given that they're truncated. > What puzzles me is your ua-init-windows.pcap, it starts with the device > already having the pid 000d (packet #2). You said that the capture > starts when the device is plugged in but I think you have missed > something, it should have started as pid 000c and later transitioned to > pid 000d. > > I can also not find such a transition in your other two captures, all > descriptor readouts that includes USB Id are 2b5a:000c. This is what puzzles me as well. If I'm missing something it's at a level that USB Pcap can't capture. When I begin the capture, plug in the device and power it on, the second packet is always the right descriptor (pid 000d). There is no indicator in the capture that commands are sent before that pid is received. As for the other problem, yeah, that confused me too; I would've thought that another get descriptor request would've been sent, but apparently not, because when I remove the device from the VM and reattach it to the host, the pid is correct. If you want I can try another capture, though I'm not sure how useful that would be. I can also try another VM-based USB capture as well. If I'm the only person on this list with this device I don't mind doing all the debugging; the device isn't super expensive but it's also not really cheap, either. It also needs some extra setup to get it working, but perhaps that setup process could give us an idea as to more things we're missing. > > rgds > Lars >
Attachment:
publickey - ethindp@pm.me - 0x846BFA7B.asc
Description: application/pgp-keys
Attachment:
signature.asc
Description: OpenPGP digital signature
