In the last post, I looked at running APRS over LoRa using two RNodes. APRS is a relatively simple application, where data is mostly flowing from mobile stations, beaconing their position to fixed stations (which may in turn rebroadcast these beacons). As such, the system is largely unidirectional, and no fast-switching bi-directional communication takes places. As such, APRS is not very demanding from a hardware or software standpoint to support.
For this test, I wanted to try something that would push the RNodes a bit more. I decided I’d try to see if I could create a useable SSH link over a distance of 15 kilometres, with just two RNodes, and no intermediaries. I scouted out a location with a distance of 15 kilometers to my home station, and found a pretty good spot. The total distance is actually 15.75 kilometres.
The terrain profile for the RF path is absolutely not ideal. To be honest, I was doubting it would work at all, with those hills in between, but I wanted to give it a try either way. As I said, I wanted to push the limits of these things a bit. Sometimes, you get positively surprised though!
To use SSH, we need IP. Luckily it’s easy to set up an RNode as a generic network card. Under Linux, you will need a few packages. If you haven’t already got them, use your package manager to install the following packages:
sudo apt install ax25-apps ax25-tools
You should also use the RNode Config Utility to put the RNodes into TNC mode. The command I used in this case was:
./rnodeconf /dev/ttyUSB0 -T --freq 433700000 --bw 125000 --txp 14 --sf 8 --cr 6
The above setup yields an on-air bitrate of 2.6 kbps. It’s a bit low for interactive full-screen apps (unless you’re the patient type), but works fine for simple stuff. At bitrates from about 5.7 kbps, interactive apps like htop or nano starts to work better.
With packages installed and RNodes configured, you will need to edit the /etc/ax25/axports file and add an interface for your RNode. Add a line like the following. Replace MYCALL with the callsign of your station. The 1152000 is the serial baud rate, 484 is the MTU, and 5 is the packet window. You can experiment with different window sizes, but don’t change the MTU, it is intentionally set at that value (even though it might seem strange if you’re used to “normal” ethernet).
rnode MYCALL 115200 484 5 RNode interface
After you’ve added the line to the configuration file, you’re ready to bring up the interface. Use a command like the following. Remember to change /dev/ttyUSB0 to whatever serial port the RNode is connected to. Also change the IP address to whatever you want it to be.
sudo kissattach /dev/ttyUSB0 rnode 10.189.77.12
Repeat the setup on the other computer, and make sure to set an IP address in the same subnet, so that the two hosts can communicate with each other. If the kissattach command completes successfully, you should be able to see the configured interface with ifconfig. Check that each host can ping each other to verify that everything is set up correctly!
$ ifconfig ax0 ax0: flags=67
mtu 484 inet 10.189.77.12 netmask 255.255.255.0 broadcast 10.255.255.255 ax25 OZ7TMD-4 txqueuelen 10 (AMPR AX.25) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
At this point I connected one RNode to an omnidirectional Diamond X200 antenna outside my house, and packed the other one along with a laptop and drove off. The antenna I used this time around was the Diamond NR770 that I’ve got mounted on my car. Here it is, with a view towards the home station. Somewhere, almost 16 kilometers in that general direction is another RNode listening for a signal.
So lets get started! To test whether there was any kind of connection, I tried pinging the other node. Success! I got ICMP replies immediately. Or, almost immediately. With a round-trip time of about 880ms, it is slow, but still totally useable for our purpose. At the higher bitrates, RTT is much more comfortable. At 21.8 kbps for example, RTT is about 170ms. Reminds me of the early days of 3G.
After that I simply ran ssh -v 10.189.77.12, with the -v (verbose) flag so I could more closely see what was going on while it was connecting. After about 40 seconds of connection setup and key exchanges, I was greeted by the login prompt.
Enter password, and there you go, logged in to the other box remotely from 15.75 kilometres away, using only two devices and 25mW of transmit power. Pretty fun stuff! As said earlier, full-screen interactive programs were too slow to be practical on just 2.7kbps, but the command line and simple stuff is fine.
I stayed connected for about 10 minutes and played around, and the connection was stable and functional during that time. I later tried faster bitrates at shorter distances, and at the higher bitrates, like 21.8 kbps, everything is very useable, and even full screen apps are comfortable enough to use. Here’s a short video showing the entire connection and login process. Admittedly, it is not very exciting, but it does show exactly how SSH works over a 2.7 kbps link 🙂
The astute reader will probably notice that I am a ham radio operator, and that I’ve used a ham frequency for this. As is tradition, I am sure someone will (understandably) point out, that encryption is a no-no over ham radio frequencies. Fortunately, this is not the case where I live, so even heavily encrypted things like SSH are perfectly fine in ham radio here.