Monitoring / Sniffing USB traffic using Wireshark

In this I’m going to show how to use Wireshark to capture USB traffic, which can be useful if you are trying to debug a USB serial application, or in my case trying to understand communication flows with the aim of replacing commercial software.

I show this for Linux but you can use Wireshare to capture USB data on Windows and other operating systems.

The reason I needed this was that I needed to monitor data going to a laser cutter to be able to find out why the software wasn’t working.

I recently got a Laser Cutter module for my Crealty S3 3D printer. It didn’t come with any software and after some searching decided on using LightBurn. It’s commercial software and I had to pay for a licence, but it supported Linux and I’ve been happy with it until now!

There has now been an announcement that they are ending LightBurn support for Linux. Annoying to say the least, especially as the licence wasn’t particularly cheap, well not for a hobbyist anyway. They gave some reason about only having a small percentage of users on Linux and it being difficult to support lots of different distributions but I’d be happy with just supporting a single distribution and going along with that. Anyway basically it’s got me looking again at whether there are some open source alternatives which can be used with Linux instead.

I was unable to get it to work and so I resorted to viewing the messages going via USB to the laser cutter to find out what the problem is.

Educational / Hobby Use only

Note this is for educational or hobbyist use and for viewing your own data only. This should not be used for monitoring traffic for other users or to view other people's data.

In the video I explain how to install and setup Wireshark using USBMon to monitor data going to a USB device. In this case it's to a laser cutter which uses an Expressif microcontroller running GRBL.

It allows you to see the GCode being transmitted and more importantly (for my example) the error messages being produced by the laser cutter.

Install Wireshark / Setup USBMon for sniffing USB data

The steps taken are:

• Install Wireshark
  sudo apt install wireshark
• Load the usbmon driver
  sudo modprobe usbmon
• Start wireshark
  sudo apt install wireshark
• Get details of the USB device that is connected
  sudo dmesg
  sudo lsusb
• Or
  sudo less /sys/kernel/debug/usb/devices
• set the filters in wireshark
  usb.src ~ "<bus>.<dev>"or usb.dst ~ "<bus>.<dev>"
• export the capture
  File ... Export Packet Dissections
• get the "Leftover information"
  grep "Leftover" capture-test1-export.txt > capture-test1-leftover.txt
• strip out text label with sed
  sed -i 's/Leftover Capture Data: //g' capture-test1-leftover.txt
• Add spaces with sed
  sed -i 's/.\{2\}/& /g' capture-test1-leftover.txt
• Convert from ascii hex to ascii text using xxd
  xxd -r -p capture-test1-leftover.txt capture-test1-ascii.txt

Then read the output using less

The problem

You can see that this is based around G-Code. When comparing with the output from Visicut it looks more similar to the standard G-Code output than GRBL G-Code output format. Both are based on G-Code though.

But it is the messages at the start that got me thinking. What is this message about gpio_isr_handler. I had actually seen this in the console of LightBurn, but as it was working I assumed it was just a warning in the LightBurn code. But this is in the serial data, so now I figured out this error is actually coming from the laser cutter controller itself. It appears to be a bug in the code running on the laser cutter and most likely based on GRBL.

When I tried using VisiCut then it was failing when it got that same error back.

So presumably the error is being triggered by an early step where perhaps it’s trying to detect what kind of laser cutter it is and what it supports.

So I therefore tried to send the code manually using Putty. It worked! Not only that it didn’t give the error message that I’d seen from both LightBurn and VisiCut. The problem appears to be with the laser cutter module. Perhaps it could be fixed with a new firmware update, but there doesn’t appear to be an official update and I don’t really want to be trying to compile my own version of GRBL for hardware that I’m not familiar with.

Summary

This has come up with a potential solution in that if I send the GCode through the serial USB connection then I could avoid that error message. I'm not wanting to do that just yet as that would mean making sure that my code could handle all kinds of potential errors, but at least now I have an idea of how I could get around it in future.

It has however been a useful excercise in understanding data flows and how to sniff USB traffic using Wireshark