USB DMX, Part 1. Capturing USB Traffic with Linux
Jul 15, 2019Welcome back to the USB DMX postmortem. Last time we built our custom DMX controller and installed Wireshark. In this second installation we’ll be looking at setting up Wireshark to capture USB traffic sent from existing software (in our case QLC+) through a specific USB port and to our device (in our case a DMXUSB controller). One of the great things we’ll learn about Wireshark is you can save your output to a file and share it with your team or review it on the go. Whilst working on this project I was spending quite a lot of time away from home without the required hardware to build the project. Thankfully I didn’t need this and could continue to analyse the output whilst away from home or using a different machine.
Setting Up Wireshark
Last time we installed Wireshark, if you’re not sure how to do this you can check out the Wireshark Wiki installation guide which covers most operating systems. For this project in particular I was using Ubuntu and as such I’ll be giving commands based on a Ubuntu installation (although it will likely be similar for any Linux distro)
Once we’re installed we need to do some slight configuration to allow Wireshark to capture USB traffic. You can find a concise guide on the Wireshark Wiki, but I’ll summarise the commands and what they do here in the interest of berevity.
$ sudo modprobe usbmon
modprobe adds and removes kernel modules to the Linux Kernel, in this case we’re adding the usbmon module. In short, the usbmon module is used to collect traces of I/O on the USB bus; this lets us capture packets sent on the USB bus. More info on usbmon can be found over at the usbmon page on kernel.org
$ sudo dpkg-reconfigure wireshark-common
This will bring up a GUI asking you if non super users should be able to capture packets, for our purposes
we would like them to be able to do so. Running Wireshark as sudo isn’t always advisable, infact in most
cases I’d advise against it. dpkg-reconfigure needs super user priveledges to run, so we prepend
it with sudo.
$ sudo usermod -a -G wireshark $USER
usermod is the command used to modify user accounts on a system. In our case we’re appending (-a) a group
(-G) of “wireshark” to the current user ($USER). As with the previous command, usermod requires super user
priveledges so we prepend it with sudo. More info can be found over on the
linux.die.net or by typing man usermod
After running these commands you should be good to go and we can start sniffing USB traffic on devices that are connected to your computer. So let’s fire up Wireshark and QLC+ and start capturing some traffic sent between your computer and your DMX controller.
Setting up QLC+
Hopefully you’ve had a quick play around with QLC+ by now, but if not don’t worry too much as it’s not massively important to have a good knowledge of the software. All we need to do is set our output device to our custom made DMX controller and send some data. Ideally you should have a DMX fixture to test with but you should be able to see RX light on the board flashing to acknowledge that data is being passed to the controller.
Select the “Inputs/Outputs” tab in QLC (likely to be the last tab at the bottom of the screen) and find our connected device. This should be called “DMX USB” and the device should be something along the lines of “FT232R USB UART”. Tick the output checkbox and take a look at the RX light, it should be rapidly flashing. We’re nearly ready to get started capturing our data, but we need to do one more thing to make our data easier to spot. Open the Simple Desk (Normally the 5th tab at the bottom of the window) and set a couple of the sliders to their maximum value. I set the first 8 values to 255. When we come to analysing our data we’ll be looking for 8 consecutive bytes with the value 255, or FF in hex.
Capturing Traffic with Wireshark
In Wireshark find your device, it’s likely named “usbmon{n}” where {n} is a number, There is usually one for each USB port that on your machine. Once you’ve identified which port your device is connected to you should stop QLC+ from sending any output to your device by unticking the checkbox in the inputs/outputs panel.
We need to make sure that we capture all the data going between the software and the device, including any handshake data. So, with that in mind, we need to start our capture before we start sending any output from QLC. So start the Wireshark capture, head back over to QLC and enable the device output. After a few seconds of capturing data uncheck the output in QLC and stop the capture. You should now have collected a ton of packets that have been sent over USB. Make sure you save the output, it’s important that we can guarantee our data is reliable and can be accessed anywhere we’re working.
I’ve outputted a small selection of the packets I collected. You can clearly see where we started collecting data if you look at Packet No. 6 and No. 7 and the time difference between the two.
No. Time Source Destination Protocol Length Info
2 0.000400 3.3.0 host USB 82 GET DESCRIPTOR Response DEVICE
3 0.000461 host 3.2.0 USB 64 GET DESCRIPTOR Request DEVICE
4 0.000653 3.2.0 host USB 82 GET DESCRIPTOR Response DEVICE
5 0.000702 host 3.1.0 USB 64 GET DESCRIPTOR Request DEVICE
6 0.000714 3.1.0 host USB 82 GET DESCRIPTOR Response DEVICE
7 4.374006 host 3.3.0 USB 64 GET DESCRIPTOR Request STRING
8 4.374130 3.3.0 host USB 68 GET DESCRIPTOR Response STRING
9 4.374190 host 3.3.0 USB 64 GET DESCRIPTOR Request STRING
You can see the clear power of Wireshark here and the ability to export and analyse small parts of your collection at the drop of a hat. I’d recommend taking a poke around the software, it’s one of my personal favourites.
Next time we’ll be digging into our data set, and I’ll supply my exported data for anybody who wants to have a go but doesn’t have the hardware or is struggling to capture data themesleves. We’ll break down how to differentiate between control packets and data packets and get a better understanding of the structure of USB data. Read more from this series
More Posts