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.
link_ssh
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.
20180630_133650
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.
rnping
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.
login
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.
ping
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.

23 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!
    Richard

    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.

  8. Hello,
    I come once again back to your article. This time with a question. I have seen a new Lora device online and would be interested if this would work too. Maybe with a Lora to IP gateway.
    https://pocket.popcorncomputer.com/
    Would greatly appreciate your opinion. I don’t know if you get my post twice, I had WiFi problems.

    1. I think it looks like a very interesting device, but it’s impossible to say yet whether it would be able to do something like this, since it seems it’s mostly still just a concept design, and they are doing a crowdfunding campaign to make it real.

      There’s no real photos of videos of the device yet, and all images on their site is renders. I hope they succeed in making it, it looks like a cool idea.

  9. Hello all,
    I just thought I would put this out there but it looks like raspbian buster dose not support ax25 or at least it did not work when I tried it. I have been useing stretch and the Rnodes work as they should. But when I upgrade to buster I could not get the Rnodes to connect at all!

    1. Thanks for posting this! That’s very interesting. I haven’t tried Buster yet, but will have to check out why this is the case. It looks like the packages are available (just looking at the Buster packaging archives on debian.org), so I don’t know what’s going on. I’ll have to try and install Buster myself and see what’s up.

      1. Here is my set up, pc with Ubuntu 18 and RPI with buster

        when I ping from Ubuntu to buster i get no host available. But, the LED on Ubuntu side rnode flashes orange. On RPI rnode it flashes blue. I think this means rnodes are talking. Rpi just dose not talk back.

        If I ping from buster to ubuntu 3 messages report a connection about 3sec loop. After this it just says buffer full.

        I notice when I install ax25-apps there are some depreciation warnings

  10. Hey Mark,
    Have you ever run Rhodes with bw:500000 txp:14 sp:7 cr:6 ?
    When I do it between laptop and rpi the pi stops tx after a few min when pinging

    1. Hi Brian
      I haven’t experienced that issue before. I’m trying to run two RNodes with that configuration right now to try and replicate it, but so far everything is working perfectly, unfortunately.

      Could you let me know exactly what operating systems you are using on both ends? Also, you say that the Pi stops TX, could you let me know whether you still see the USB activity indication light up, and only the orange TX light is not coming on? Or does the host completely stop sending data to the RNode?

    2. Hi again Brian
      Ok, so after remembering your previous comments about problems in Debian Buster, all is now a lot more clear I think. I’ll write you a mail with the details, but just wanted to give you a quick update. It seems quite a bit of the AX.25 stack (including kissattach) is broken in Buster (and any other OS that sources from Buster, so Ubuntu and Raspbian is affected too).

      I’m currently writing a new userspace driver for attaching KISS TNCs as network interfaces to replace kissattach. Upside is that it will work on macOS as well, and probably also every other POSIX OS.

Leave a Reply to Brian Duvall Cancel reply

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