Low-cost LS/FS/HS USB sniffer with Wireshark interface

[ataradov]

I'm finally releasing the design files for my low-cost LS/FS/HS USB sniffer with Wireshark interface - https://github.com/ataradov/usb-sniffer

This project has been in development for a long time. First it was delayed by my reluctance to work on the GUI for it, then pandemic made parts disappear. Now the parts are back in stock.

The sniffer is based on Cypress CY7C68013A, Lattice LCMXO2 FPGA, and Microchip USB3343 USB PHY.

It integrates with Wireshark, so that capture can be started and stopped directly from the UI, just like for any other interface. Wireshark is not perfect for USB, but very workable.

It can also be used standalone from the command line.

There are example capture files on GitHub.

[coromonadalix]

i would  love to get a complete board, if not too costlly


Kudos   

[ataradov]

I have no plans to sell assembled boards myself. The total BOM for this should be less than $50 in single quantities and all the parts are available. And there is nothing here that is too hard to solder. The only thing that really needs hot air station is USB3343. And oscillators are much easier with hot air.

[spostma]

the PCB you designed is beautiful; it has almost no vias!
I also admire your programming + hacking skills!
Thank you also for open-sourcing so many very useful bare-metal software projects.

About this sniffer project, would it be an idea to add a free-running ADC (with fast sample and hold)
on the D+ and D- lines to get a histogram of voltage level distributions?
That could give an impression of rise times and overshooting of the input signals.

[ataradov]

That could give an impression of rise times and overshooting of the input signals.

This is not a task for a sniffer. A scope if far better suited for this. Also, ADC capable of sampling 480 MHz alone would cost 100 times more than this whole board. And even 12 MHz for FS mode is no that trivial.

Sniffers are for debugging logical issues, all electrical problems should be resolved by that time.

[KE5FX]

Seems to be working great, thanks for developing and posting this project! 

One suggestion: add a few paragraphs of 'WireShark USB capture for dummies' to your project's main page, and include this little tidbit. 

When looking at HS traffic, I was getting nothing but invalid packets.  I reflowed the board, then when that didn't help, I added some tweaks that also didn't help but are probably worthwhile anyway (bypassing VBus with a 4.7 uF cap on the target interface, another 4.7 uF cap to delay the PHY's power-on reset to give the clock oscillator some extra time to come up, and a pair of 100-ohm resistors at the point where the traces to the comparators connect to the USB A DP/DM pins.)  I was very close to chucking the board in the junk box when I found your post about setting the transfer speed and where to find the option.  Glad I didn't give up, it's a very cool little gadget!

[NiHaoMike]

I remember there was some project to do that with Beaglebone Black. Could a Raspberry Pi 4 do the same since it also has an OTG controller and an independent host controller?

[moffy]

Beautiful project thank you for sharing all your hard labour.

[Bud]

In installation section link to Windows executable is broken

[moffy]

In installation section link to Windows executable is broken

I successfully downloaded the whole project as a .zip file and the 'usb_sniffer_win.exe' is there and runs successfully from the command line.

[Njk]

In the past, the company existed called CATC. It was eventually acquired by Lecroy. And Lecroy did produce the USB protocol analyzer CATC Tracer/Trainer. It was a big desktop box that was almost empty inside so I presume the main purpose of the metal frame was to provide stability, which is highly desired in the lab. User can comfortably plug/unplug the cable using one hand, without the necessity to use the other hand to immobilize the instrument. Something that can't be achieved with a small plastic box. No idea if it's still in production. Back at that time, I had terrible experience with the Lecroy salesman so I'd blacklisted the company. Now, I'm banned because of nationality. The instrument is likely morphed into something of universal type.

Anyway I was not impressed with the build quality, but it was a big pleasure to use the instrument because of very convenient GUI. Wireshark is OK, but it can't be compared with CATC. For USB, it's actually industry standard. One time we were contracted by Apple. Fortunately, the Apple guys also had that analyzer, so I did not have to travel to Cupertino to investigate every stupid issue. It was enough to exchange the CATC trace files instead. Note that it's not necessary to have the device to view the trace file. The viewer is a PC application that can be used separately.

The low-cost USB sniffer with Wireshark interface is a great project. With added support of CATC trace file format it would be even more great, I think.

[ataradov]

In installation section link to Windows executable is broken

Fixed, minor link error.

[ataradov]

I remember there was some project to do that with Beaglebone Black. Could a Raspberry Pi 4 do the same since it also has an OTG controller and an independent host controller?

Not really. You can get somewhat close, but you will be seeing the same thing as any software USB sniffer. You will be observing transfers, but not individual packets, since no USB controller will pass token packets to the application level.

[ataradov]

(bypassing VBus with a 4.7 uF cap on the target interface, another 4.7 uF cap to delay the PHY's power-on reset to give the clock oscillator some extra time to come up

I don't see how this would do anything. PHY outputs the clock all the time, so assuming you connect host USB before the target, everything should be ready by the time you capture anything.

Adding extra capacitance to the VBus may be intrusive to the target and VBus voltage is not really used for anything other than indication of the bus state, which could be ignored entirely.

and a pair of 100-ohm resistors at the point where the traces to the comparators connect to the USB A DP/DM pins.)

Yes, I've seen this idea. I'll need to investigate if it does anything.

In my case I can only reproduce HS capture issues with really sketchy USB cables. I use random silicone cables, which are really nice and flexible, but have terrible performance apparently.

With the same setup, switching to a decent cable solves all issues.  Of course, the sniffer capture circuitry introduces additional loss, but cable quality seems to matter as well. Marginal cables + extra loss = bad day.

[KE5FX]

(bypassing VBus with a 4.7 uF cap on the target interface, another 4.7 uF cap to delay the PHY's power-on reset to give the clock oscillator some extra time to come up

I don't see how this would do anything. PHY outputs the clock all the time, so assuming you connect host USB before the target, everything should be ready by the time you capture anything.

Adding extra capacitance to the VBus may be intrusive to the target and VBus voltage is not really used for anything other than indication of the bus state, which could be ignored entirely.

Agreed, I doubt it does anything useful as well.  It's not enough C to have any adverse effects, though.  The USB spec assumes that some capacitance will be used on both upstream- and downstream-facing ports:

and a pair of 100-ohm resistors at the point where the traces to the comparators connect to the USB A DP/DM pins.)

Yes, I've seen this idea. I'll need to investigate if it does anything.

In my case I can only reproduce HS capture issues with really sketchy USB cables. I use random silicone cables, which are really nice and flexible, but have terrible performance apparently.

With the same setup, switching to a decent cable solves all issues.  Of course, the sniffer capture circuitry introduces additional loss, but cable quality seems to matter as well. Marginal cables + extra loss = bad day.

I used the Amazon Basics cables you recommended in one reply on Github, and they seem fine.  To the extent the order in which the ports are connected matters, that'd be another good thing to mention in the operating notes.

I figured the resistors couldn't hurt anything, since the comparators aren't timing-sensitive.  But whether the stubs are long enough to impact SI without the resistors is debatable.  I was mostly just trying random stuff...

[ataradov]

The point here is that sniffer itself just observes the VBus, you still have two sides and they will have whatever capacitance they have. There is no UFP or DFP here, the sniffer is just a tap that should be non-intrusive as much as possible.

The order does not really matter, but it is logical to have the device powered first before the target interface is powered.  In practice it works either way. I'll add that to the readme a bit later along with the settings dialog stuff.

What would prevent devices from working for sure is not powering the PC side at all, since ESD diodes in the PHY and comparators would clamp the data lines.

Adding series resistors before the comparators is not a bad idea as far as shooting in the dark goes. I will definitely try that mod. A bit later though, I just returned from a trip.

And there is obviously no controlled impedance anything here, I just put down the traces. I'm not sure it matters all that much. A typical USB 2.0 front panel connectors on PCs go though 0.1" IDC connector, I doubt it has ideal impedance control.

It is hard to tell what may be going on without using proper measuring equipment, which I don't have.

[ataradov]

I added usage information to the readme.

I also did some experiments with proposed changes. I added 510 Ohm resistors before the comparators. I cut the trace close to the connector pins on the existing board. I also drilled out the short layer jump on the DM line and replaced it with 0 Ohm resistor.

None of that had any perceivable effect.

But I also ran into some strange effect that I can't fully explain.  I use Lenovo ThinkCentre mini PC. It has USB ports on the front and in the back. I tried with USB stick directly plugged into the sniffer and an Android phone plugged using another USB cable.

At first I tried back USB for the data interface and front USB for the target interface. Back USB uses the same Chinese flexible cable. With flexible cable for the target interface, devices fail to enumerate. With a good cable, both devices work as expected and the capture works fine.

But then I tried to reverse the connectors using back USB as a target interface and the front USB as a data interface. With this change and both "bad" cables, it all worked as expected.

As far as I can tell all of those USB connectors are attached to different ports of the same root hub. So, it looks like there are a lot of things stacking up to cause marginal behavior.  Routing of the USB connector inside the PC to the front panel, bad cables, losses introduced by the sniffer itself.

It is really hard to tell what exactly going on without proper equipment. But it does not look like there is a simple solution to this. Even improving impedance matching in the sniffer may not help, so using the best cables and trying different ports in case of issues may be necessary.

[ataradov]

I've been told that a version of  this sniffer is available for sale https://www.aliexpress.us/item/3256806174548913.html

They did communicate with me and we discussed the changes compared to the original design.  But I was not directly involved in the modifications nor have I evaluated the changes. But they do look reasonable.

Note, just to be safe, I would replace the firmware and FPGA binaries with the ones from GitHub.