Etherify 4 – back to earth with “normal” ethernet hardware

Recently i’ve published:

Etherify – bringing the ether back to ethernet

Etherify 3 – the PI 4’s dirty little secret

please read these articles first, before reading this one.

Those articles use primarily raspberry PI 4 for transmission, which give an exceptionally strong signal, and fast link-up time. Unfortunately Etherify 3 shows that the strong signals seen in the original Etherify article are do to the unique properties of the Raspberry PI 4 (either all of them, or just the one i used).

This time i wanted to test leakage from a “normal” ethernet port, so i used two old Dell Lattitude laptops (E6220 and D610) and a good ethernet cable.  I use them for playing with radio, because they don’t generate a lot of interference compared to some other laptops i’ve used, so they should be very well shielded.

The problem is that when changing the interface speed the link up time is about 2-5 seconds with most hardware. This is unacceptable for sending regular morse code. Fortunately radioamateurs have an answer to this: QRSS CW (CW is morse code in ham radio speak).  In QRSS CW the symbol length is increased to a few seconds or more, and the morse code is decoded by eye from a slow spectrogram.

Transmit setup

Two Dell Lattitude laptops were used: E6220 with Debian Bullseye running the etherify4.sh script, and D610 running Debian Sarge. The laptops were connected using a good quality 2m ethernet cable.

Please see the etherify4.sh script on https://github.com/sq5bpf/etherify. It measures the time from changing speed to establishing an ethernet link, which is usually 2-5 seconds depending on hardware. Then it uses this time as the delay between symbols, the dot time is equal to this delay, and dash time is 3 times this period (per morse code specifications).

Receive setup

A laptop running gqrx and an usb rtl-sdr receiver was used. The gqrx output was connected via pulseaudio to DL4YHF Spectrum Lab running under wine. Spectrum Lab is used to display a high resolution spectrogram.

Please see the etherify4.sh script on https://github.com/sq5bpf/etherify. It measures the time from changing speed to establishing an ethernet link, which is usually 2-5 seconds depending on hardware. Then it uses this time as the delay between symbols, the dot time is equal to this delay, and dash time is 3 times this period (per morse code specifications).

It is best to check both 125MHz and it’s harmonics. Some of these signals will penetrate the shielding and radiate better than others.

Results

Changing the interface speed will result in changing the signal radiated by the interface. This is both amplitude and frequency modulation.  Also changing the speed changes the drift of the interface clock, at least in the case of the hardware tested.

This is easy to see at 625MHz, the 5th harmonic, at 3m distance:

The above spectrogram doesn’t show the last dash of Y.

The mark frequency is lower, and the space frequency is higher.  Usually the mark frequency also has a stronger signal.

This shows etherify 4 at 375MHz, 3m distance:

This shows etherify 3 at 625MHz, 3m distance:

At 625MHz the clock drift is easily seen.

This shows etherify 4 at 250MHz, 2m distance:

Note that the space signal is stronger than the mark signal, ie the dots and dashes are where the signal isn’t present.

I’ve had success running the demo at 10m distance, however i couldn’t replicate this later. I suspect that in a quiet location, with a better receive setup (directional antenna, preamp, bandpass filtering, better receiver) the distance can be increased to at least tens of meters.

Discussion

While the previous etherify demos used Raspberry PI 4,  this shows that it is possible to run etherify from normal ethernet hardware, such as a laptop.

This is easily portable to other network hardware such as a switch or router, either via snmp, or using some embedded scripting (such as tclsh in cisco switches). This would enable transmission of data from an interface that is closer to the receiver, or radiates better (due to asymetry in the ethernet cable, bad hardware etc).

The “software” side is intentionally a very primitive silly hack.

Happy air-gap jumping 🙂

If you cite this, please include the webpage address and attribute Jacek Lipkowski (SQ5BPF). Email can be sent to my_callsign @ this_domain.