[hardware]IC Obsolete

[huajijam]

DSC6101CI2A series OSC labled Obsolete in Digikey
and IC6,IC10 are using them
IC6 using 26Mhz only have few stock in Digikey
and the 24Mhz one currently have no stock in Digikey and Mouser

any replacement?I am currently using YXC's OSC and get some problem
in HS device,the sniffer can only detect as FS,and get a lot of error
but with ./usb_sniffer --test I can get 44-45M/s

[ataradov]

What exact part number are you using?
The only critical parameter is frequency accuracy, which ideally should be +/- 25 ppm, but +/- 50 ppm should work too.

I'm reluctant to suggest specific part numbers, since I have not tried them, but this should be a direct logical replacement https://www.mouser.com/ProductDetail/Microchip-Technology/DSC1001BI2-026.0000?qs=8cKuZ6Ok2lZdYfu%2Fx18pgA%3D%3D

But again, almost any oscillator should work.

[huajijam]

What exact part number are you using? The only critical parameter is frequency accuracy, which ideally should be +/- 25 ppm, but +/- 50 ppm should work too.

I'm reluctant to suggest specific part numbers, since I have not tried them, but this should be a direct logical replacement https://www.mouser.com/ProductDetail/Microchip-Technology/DSC1001BI2-026.0000?qs=8cKuZ6Ok2lZdYfu%2Fx18pgA%3D%3D

But again, almost any oscillator should work.

24Mhz: OT322524MJBA4SL from YXC
26Mhz: ramdom Aliexpress seller claim from YXC SG-310 series and I just not trust it

I bought a new 26Mhz one from Digikey's stock,but it need about 2 week to get in hand,and I just no idea why it can't detect HS mode

[huajijam]

OSC and usb-phy chip image on my board(sry for oversharp img by my phone)

[ataradov]

Just to double check - have you configured HS mode in the settings? There is autodetection of the speed, but it is mostly for logging and information use. There is no automatic switch. You need to go into the interface settings and configure the speed you expect to see.

I've used 12 MHz version of that Yangxing Tech oscillator from LCSC in a different project and had no issues with them. But I would not trust AliExpress one, especially if there are issues.

[huajijam]

how 2 set speed? in Wireshark? I can't found it
hum, u meam --speed option? I am using as a plugin in wireshark so I didn't config it

[ataradov]

In the list of interfaces there is a cog icon next to the name:

Or use the same icon on the main toolbar if you are in a capture mode.

You should see this dialog:

[huajijam]

In the list of interfaces there is a cog icon next to the name:

Or use the same icon on the main toolbar if you are in a capture mode.

You should see this dialog:

it seems work now, but I am getting this error

[huajijam]

btw,will it cause error when using HS mode to capture LS/FS?
if no,why not HS by default

[ataradov]

This is the issue on the host side. In the data stream there is a toggling bit for each packet used to detect possible corruption. There are many reasons why this may happens, including overflows, bad cables or hubs on the device side. I would try a different cable and a different USB port on a root hub.

You need to capture with the setting that is actually use by the bus. It will not be able to receive the frames at the incorrect speed. There is no identification, speed is a setting. Normally devices negotiate which speed they want to use, but sniffer in general does not know that.

[huajijam]

This is the issue on the host side. In the data stream there is a toggling bit for each packet used to detect possible corruption. There are many reasons why this may happens, including overflows, bad cables or hubs on the device side. I would try a different cable and a different USB port on a root hub.

You need to capture with the setting that is actually use by the bus. It will not be able to receive the frames at the incorrect speed. There is no identification, speed is a setting. Normally devices negotiate which speed they want to use, but sniffer in general does not know that.

but this error will cause the capture stop and need manually restart,can there be an option to display as a log insteat of killing the capture?

[ataradov]

No, decoding of the incoming stream depends on the correct tracking of the state. This is how software knows what is a header and what is a data in a continuous stream. There is no way to recover if there was de-synchronization.

[ataradov]

Note that this is not an overflow on the capture side, which would cause frames to be dropped and corresponding log message to be issued.

This is an error on the host side, which should not happen really. If it does, it means that host side communication is not reliable for some reason.

If you can't make it work with a different cable and a different USB port, I can add a bit of debug logic and we can try to debug this if you can reliably reproduce the issue. I've only seen it a couple times when working tough a dodgy hub.

[huajijam]

Note that this is not an overflow on the capture side, which would cause frames to be dropped and corresponding log message to be issued.

This is an error on the host side, which should not happen really. If it does, it means that host side communication is not reliable for some reason.

If you can't make it work with a different cable and a different USB port, I can add a bit of debug logic and we can try to debug this if you can reliably reproduce the issue. I've only seen it a couple times when working tough a dodgy hub.

I can reproduce it a lot of time,I make the sniffer bcz my desktop usb3.0 hub sometimes will give me a code 43 or code 10 in some(all) usb 2.0 device(and only 2.0),I want to check what happened
but it seems like when I plug it in sniffer,it will fix this problem(wtf)

I am currently using hub from my dell monitor, and I can reproduce it by just plug in a bad usb device
as ur said, it came from error in host,but I am using a different hub for my target, and it will still error

both desktop hub and monitor hub are plug into pc's back usb3.0

[ataradov]

I don't understand your setup. But using hubs for the sniffer host connection is prone to cause errors like this. Hubs sometimes are bad at handling a lot of traffic. It is far better to use direct connection for the sniffer itself.

As for fixing the errors - I don't know why that wold be the case. In theory host would not be able to tell if there is a sniffer in-between.

[huajijam]

I don't understand your setup. But using hubs for the sniffer host connection is prone to cause errors like this. Hubs sometimes are bad at handling a lot of traffic. It is far better to use direct connection for the sniffer itself.

As for fixing the errors - I don't know why that wold be the case. In theory host would not be able to tell if there is a sniffer in-between.

rear usb3.0 → desktop 3.0hub(have issues) → target type-c port
rear usb3.0 → dell monitor 3.0hub → host type-c port

monitor's hub should be fine, as it will work if the desktop does not

maybe some debugging logic will make it easier to find out where the problem is

[ataradov]

I will add some logic a bit later, not sure how helpful it would be though.

But in the mean time I would try to avoid hubs for the host connection.

[ataradov]

I've added printing out of the header along with the error message. This in combination with the last frame should show a bit more information on what is going on. I don't know if that would be sufficient to fully debug this specific case though.

The error window will no longer show up, but the capture would stop on errors like this. The last messages in the log would be the diagnostic info.