USB String Descriptor requests/Response not appearing in Wireshark

[shingadaddy]

I've used Wireshark 4.0.3 and now the previous 3.xxx and still the same results. WIn 10 Enterprise. WIreshark 4.0.3. Device: 100% functional apparently VID 0483. PID 5740. ST micro controller as CDC device using VCP. I see DEVICE DESC request and response. I see CONFIG request for 9 bytes and response. I see second CONFIG REQUEST for ALL bytes this time and the expected response.I see STATUS request and response. I see a THIRD (Surprise) CONFIG DESC request and that same response. I see SET CONFIG. I see SET INTERFACE and lastly I see line coding requests and responses. BUT ---- I DO see the expected string information when Windows Device manager. As in iProduct and the text is readable in Device manager under DETAIL- Bus Reported Device Description. It is the expected TEXT. I tried using Wireshark native and USBPcapCMD by itself and then viewing the PCAP file with Wireshark. Also don't see Microsoft specific descriptor requests. Device descriptor response shows non-zero values for all 3 of iManufacturer, iProduct and iSerialNumber index values

NO REQUESTS FOR STRING DESCRIPTORS SHOW UP in Wireshark but Windows gets the data... Baffled.....

Help?

[desowin]

Did you start capture before connecting device or after?

[shingadaddy]

Hi and Thank you TM. --START CAPTURE BEFORE PLUG IN --
USB2.0 Full speed in use. This is exceedingly baffling to me. I closed WS and restarted machine. Started capture USBPcap1 and plugged in device. I see all expected requests and responses EXCEPT ANY STRING DESCRIPTOR. (I am somewhat surprised to NOT SEE any START of OF FRAME stuff clogging the capture data either. Should I be? I am not filtering ANYTHING. Or at least I don't THINK I am )
I stopped capture and plug in my phone. I SEE STRING DESCRIPTOR REQUESTS and RESPONSES. ???? I then thought I would change the string in firmware in the micro to see if it was really being read in and not cached somehow. I change it and got "FREDS_BAR_AND_GRIL" - mis-spelled just like I typed it into the firmware in the micro. I AM BAFFLED SIR ?? ....

[shingadaddy]

I ALWAY start capture and AFTER THAT I plug in device . Or I would not see any of enumerations. Sorry. Not enough sleep obviously. The device works properly other than this oddity.

[desowin]

You won't see start of frame because USBPcap is capturing URBs not actual USB packets.

[shingadaddy]

AH yes.. Back side via software and what the driver can see --versus what a ON THE WIRE sniffer can see.
So much to remember it gets a little confusing. Thank you for clarifying. About to plug in again and do another sifting exercise on what I see to make sure I didn't miss the strings sneaking in via a descriptor I was unaware of that carried the strings. I've spent nearly 3 day on this and its a head banger.

[shingadaddy]

Home on laptop. HP Spectre. I 7. Win 11 Pro. Wireshark 4.0.3..... Same thing.... Ugh... starting to sift now.

[shingadaddy]

After hunting down a USB C to C cable here at home - this now makes my cerebrum hurt.. 0x46,0x52,0x45,0x44 ( OR "FRED" in UNICODE) is not in any descriptor response I see here. Yet even on THIS computer I see:

This makes it near certain that I must be doing something incredibly stupid . :-\

[shingadaddy]

So I shop around quickly and find this little descriptor dumper.
https://www.thesycon.de/eng/usb_descriptordumper.shtml. Pretty simple. I launch Wireshark -
I launch TDD . It asks me to select which device to dump.... Shockingly - I see this from their list.

Further amazed and befuddled I select it and it tells me to please unplug the device and plug it back in I get this:

I get the same stuff on Wireshark as before. I have been told at times that I can break a steel wedge while playing in a sandpile. I now understand that more perfectly. Any ideas?

[shingadaddy]

Plugged in a flash drive:

Time for a nice beverage.
I've been tasked with doing some training on this. Seems I have a bus with no wheels right now.
My initial thought was - Well the device is sending SOMETHING (or NOT) back in the device descriptor that tells the PC their are no strings. I could troubleshoot that.
Yet I see the string that apparently Windows didn't ask for - IN THE PC!
"T" I am 100% perplexed here.
Is there a way that this string traffic can be hid from Wireshark but not TDD? Thanks for previous responses and I hope I haven't over flooded you with --- well --- I'm not sure what to call it.
Anyway - ANY HELP GREATLY APPRECIATED!

[shingadaddy]

Still no progress after trying several different tests. Can't explain why Windows see all the data when Wireshark never shows any string requests or response. ?

[desowin]

Do you see any unknown transfers (transfer type 0xFF)? Another option can be that the strings are retrieved before FDO is created.

Only ST board I have is 32F746GDISCOVERY. Can you check if it happens on such board and prepare firmware hex for me to try?

[shingadaddy]

Thank you very much T.
"FDO" .Okay I had to look that one up. the pool is DEEP. This makes me think:

1. Wireshark only captures after FDO?
2. How / Why can the device I have effect that?
   The VERY FIRST IMAGE I posted above shows the total of what I see with enumeration of my device. That's it. No RED stripes. No FAILURE messages.
   I've blown Wireshark off my machine and intend to reinstall. Not much confidence in that helping though.

Ill look at STM32F746G Discovery to see if they had an example program for VCP in the STM32CubeF7 package of downloadable examples. Code from one ST device is very portable to each of their other devices but it usually take some massaging to get it lined up right. But at that point we won't be exactly APPLES and APPLES.
I wan to thank you for responding. I've asked about this in other places and I get NOTHING. That's disheartening to say the least.
Your F746 looks like this right?

[desowin]

Wireshark does not capture - USBPcap does (after FDO is created). Device can have some effect on FDO creation (it is the VID/PID and/or class that is required for host to select driver) but it mostly boils down to host (Windows) driver for the device.

The photo matches discovery board that I have. It has two USB device ports - one full speed the other one high speed. Only one can be active at a time and which one is used depends on loaded firmware.

[shingadaddy]

Yeah I worded it broadly. I've use USBPcapCMD to capture by itself and then view the PCAP file in WS. I'm so scattered at the moment but I was going to see if there was another USB CAPTURE add in to capture with but I just can't spin all the plates .
Ill try spinning up a hex for that Discovery PCB but it will be a blind attempt. IF it compiles it MIGHT work..... :-
Full speed is what STM32L476VG offers so that will be my target.

[shingadaddy]

Time has yanked the rug from under my feet today I'm afraid. I will have to be away from my Lab environment for some time and working only from the limits of remote access. The training I was to provide will be delayed. And I won't be able to do this Firmware generating gymnastics for a few days now until I get settled in to a different environment. The F746 examples do not have a CDC STANDALONE DEVICE EXAMPLE. That's a killer for having something QUICK but I don't know how bad. It means I have to find one of the F7xx projects that DOES have that example "APPLICATION" (IF ONE EXISTED - and it does - 756G_Eval). Then see what might need to be changed to suite the other F746G Discover PCB.
T, I very much appreciate your help here. But I'll probably drop off the radar a few days before I get set up in a VERY limited capability environment.
Best to you!