Dev Log - 2 Feb 2020 - ax25 v0.2.0

I have one crate on crates.io—called ax25, it’s a library to support packet radio communication, and I uploaded 0.1.0 way back at the end of 2017. Although I had grander plans it was already functional enough to build a robust digipeater for Linux and since then I neglected it profoundly. A couple of months ago I received a drive-by pull request to fix a few warnings, which reminded me that the crate existed and started me thinking again about what I wanted to do with it.

That led to a bunch of coding this weekend and I released 0.2.0 on 02/02/2020. I didn’t plan for that but it’s a fun coincidence. :) This version adds support for using a KISS TNC over TCP, such as the server provided by Dire Wolf on port 8001. It also replaces my original Linux API with a unified Tnc interface. With this you can select any kind of TNC supported by the library by changing a simple configuration string, but otherwise your application code stays the same. Neato.

Since I’m a coder by day I often can’t be bothered after hours so I needed to do my best to reduce friction. The first good decision was to set up a good test bench. Above you can see my current “shack”. I have a Raspberry Pi 3 and a Raspberry Pi 4 each on the WiFi and connected to a Yaesu transceiver. The Pi3 is using a TNC-PI and the Pi4 is running Dire Wolf with USB sound and PTT. Having two machines always on and ready to test sending and receiving packets makes development far easier.

The Pi4 is surprisingly fast and it’s now where I do all of my development for this project. While I can find my way around in vim and emacs, TUI development has never been optimal for me so I needed a good way to work over the LAN. I remembered that VS Code released a Remote Development extension last year so I tried that. And you know what? It is superb. It connects over regular SSH. File changes in both directions are reflected almost instantly. The git integration even works seamlessly on the remote host. That was my second good decision—I’ve been able to do all my work from another room with VS Code and a few terminals.

This is one of the example applications included in 0.2.0, a barebones equivalent of axlisten. I’m running it twice and it appears to do the same thing both times. The difference is the first time it’s using a Linux socket interface to receive raw packets from the AX.25 interface ax0 (HW address “VK7NTK-2”). The second time it’s creating a TCP connection to Dire Wolf running on localhost. In the second example you could enter a different IP to use a TNC attached to a computer on the LAN. Then the Rust application could just as well run on a Windows or Mac host, or even built into an iPad app.

That’s where I want to go with this. If packet radio is to have a place in the 21st century the applications need to evolve. We no longer have the constraints of the 80s when computers were very slow and had limited storage. It would be easy to say “the internet won because it’s much more fast and available”—if that’s the case, why is there so much interest in LoRa and other IoT phenomena? Many technologies that are cool right now are radio-based and have less bandwidth than even VHF packet.

It’s just that nobody wants to use an FBB BBS any more. Packet is merely a data transfer mechanism. It’s not synonymous with the applications it had decades ago unless we perpetuate that idea. If you could take a library and write a cross-platform packet application for 2020, what would it do?