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

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  netmask  broadcast
        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, 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.

15 thoughts on “15 kilometre LoRa SSH link with RNode

  1. Super cool! Thanks for sharing and keep the nice articles coming in!

    1. Thanks! Will do! I have lots of interesting things planned with these devices.

  2. I did this once using AX25 and AFSK1200 with somewhat poor results. It seems this works quite well and I’m very interested to try it myself.

    1. I did so too! Had the same experience as you. It just barely worked, but very slow and unreliable. This is still slow of course, but definitely much more useable.

      I subscribed to your YouTube channel btw! Lot’s of good stuff you’ve got there, I’m looking forward to going through it all 🙂

  3. What? Where are the link details? Antenna types and gain in dBi on BOTH ends of the link, Transmit connector power and EIRP. Target error rate and specified Eb/No? LoRa ModCod settings you used? Etc…

    1. Hi David. You seem a bit offended that I left out those details, I like your attitude 😉 You’ll find the LoRa settings are actually in the article, along with transmit connector power. I agree it’s quite an important detail that both antennas were omnis, so I added that (previously only one antenna was specified in the post). I’d happily talk for pages and pages about all the specifics, but this post is not meant for that. It’s intended as an easy read and an introduction for people who are new to LoRa, and to RNode. Either way, I actually think EIRP is a bit of a moot point here. This is not a lab setup, and I have no way of accurately measuring real-world EIRP. I could give an estimate based on transmission line loss, attenuation in connectors, adapters, coax surge-protectors and antenna gain, but it’s likely to be pretty far removed from the physical truth. There’s also plenty of things in the home stations antennas near field that are going to change the radiation pattern, and I can only calculate line loss as a very rough estimate. For some of the connectors and adapters I used, I don’t even know what their specified insertion loss is. So for me, the takeaway here is that trying to do justice to those estimates would likely end up taking twice the paragraph space of the current article for something that is only of primary interest for a few people. Even though I myself agree that it is very interesting!

  4. You really need to start a youtube channel, if you don’t already have one. I’m very much interested in your experiments.

    Keep up the good work!


    1. Thanks! Yes, I really should 🙂 I’ve been thinking about making some good videos to accompany the posts I write, but I always end up just writing. I promise I’ll put in more effort and try and make some videos for future posts!

  5. You should look into using mosh next time. The mosh client and server create a kind of virtual frame buffer and only send changes of the terminal. Plus it’s connection less and uses UDP so very resilient on slow and unpredictable links. I really want to try this as well.

    1. I actually did try using mosh after writing this post, but quite surprising to me, the performance was worse than just using plain SSH. I didn’t quite get to the bottom of why, but I have a feeling that the somewhat low (in ethernet terms) MTU of 500 bytes might be the problem. Unfortunately I didn’t get to the bottom of the problem. I really liked the idea of using mosh over LoRa.

  6. I was recently experimenting with two ESP32 and LoRa RA-01 modules, where one module was behaving as APRS-IS iGate server (connecting to home WiFi) and another as a client (was just receiving data from APRSDroid through the bluetooth similar to micromodem).

    Got around 13 km maximum when there was line of sight from some higher elevated place and around 4 km from the pedestrian level. Was using 20 kHz bandwidth and 10 spreading factor.

    These are really cool toys for APRS, received the packet which was -13 dB below the noise floor, this is almost FT8! Also made server appending signal level into the APRS comment, so can see signal level in different points, how cool is that!

  7. next time – could you please try at one point if mosh server/client would give better experience compared to plain ssh? on low bandwidth links it’s usually better when it comes to ‘how laggy it feels’

    1. I actually tried this at one point, and for some reason it didn’t work out too well. Would have expected it to work very nicely, but something is not apparantly.

Leave a Reply

Your email address will not be published. Required fields are marked *