[Matt Keeter], like many of us, has a lot of network-connected devices and an oscilloscope. He decided he wanted to look into what was on the network. While most of us might reach for Wireshark, he started at the PCB level. In particular, he had — or, rather, had someone — solder an active differential probe soldered into an Ethernet switch. The scope attached is a Textronix, but it didn’t have the analyzer to read network data. However, he was able to capture 190+ MB of data and wrote a simple parser to analyze the network data pulled from the switch.

The point of probing is between a network switch and the PHY that expands one encoded channel into four physical connections using QSGMII (quad serial gigabit media-independent interface). As the name implies, this jams four SGMII channels onto one pair.

From Oscilloscope to Wireshark: A UDP Story
https://www.mattkeeter.com/blog/2022-08-11-udp/

Like many of you, I’ve got hardware on my desk that’s sending UDP packets, and the time has come to take a closer look at them.

Most “low-level” networking tutorials will bottom out somewhere at “use tcpdump to see raw packets”. We’ll be starting a bit lower in the stack; specifically, here

This is a high-speed active differential probe soldered to an Oxide Computer Company rack switch. We’re going all the way down to the metal.

The oscilloscope doesn’t have a built-in QSGMII analyzer (and we’ll want to do fairly sophisticated processing of the data), so I wanted to export waveform data to my computer.

How much data should I capture? Analog waveforms can easily add up to multiple gigabytes, so I’d like to capture a small amount while still catching a packet or two.

I knew that a device on the network was emitting about 30K UDP packets per second, or one packet every 33 µs. I configured the oscilloscope to collect 100M samples at 1 TSPS (tera-sample per second, 1012), which multiplies out to 100 µs of data; this means we should catch 1-3 UDP packets.

After hunting down a USB key, I ended up with a 191M .wfm file to process.

We know our sample rate (1 TPSP) and the nominal QSGMII bit rate (5 GHz); this means that a single-bit pulse (e.g. 010) should be a 200-sample pulse. In turn, we expect a comma character to be roughly 1000 samples long (200 × 5).

The oscilloscope and switch may not have exactly the same clock rate. If we go a long time between comma characters, we may end up sampling at the wrong position in the waveform!

It turns out that we need to synchronize in two places:

Comma characters tell us when a new code-group starts
Bit transitions help us keep the clock in sync

Storing and analyzing packets

Decoding ethernet frames with our eyes gets old fast.

Luckily, there are lots of good tools for working with frame data. Using the pcap library, we can write out a .pcap file to be analyzed with Wireshark.

Here’s our full analyzer, going from .wfm to four .pcap files

The whole pipeline – from loading the .wfm to writing the .pcap file – runs in about 410 milliseconds on my computer. Considering I put no effort into optimization, this isn’t too bad!

Using tshark, we can confirm that these are UDP packets:

In this video, we hook an oscilloscope up to an Ethernet link to see what’s going on.