If you just want the most minimal-effort setup guide on how to run ethernet and IP over packet radio TNCs, skip down to the last section: “One to Many, Many to One”.

The Old Ways

Running IP applications over packet radio TNCs and similar hardware has traditionally been possible, albeit in a somewhat limited form, using the Linux AX.25 kernel modules and utilities like kissattach. Recent bugs have prevented this method from working correctly in new versions of Debian (and derivatives), and there is even a discussion about removing kernel AX.25 support altogether.

While the kissattach method of IP networking over packet radio traditionally worked relatively well, it also has the drawback of having to encapsulate everything in AX.25 frames, and thus not supporting standard ethernet, while incurring overhead that is entirely unnecessary for IP networking.

A Cleaner Solution

With all that in mind, I found it was probably time to offer an alternative, so I wrote tncattach. It’s a small program that replaces the functionality from kissattach, and doesn’t require any special kernel modules.

With tncattach you can attach any KISS-compatible TNC as a fully ethernet-compatible network interface in Linux. It also supports more “lightweight” tunnel interfaces, for point-to-point links (where you don’t need the overhead of ethernet). And it of course fully supports both RNode and OpenModem.

After writing tncattach, I optimised the buffering and queues in the device firmwares, so be sure to update your RNode to at least version 1.16, and your OpenModem to version 1.05 or above for the best results.

Creating an interface with tncattach

To create an interface with tncattach, you will first need to download the program to your system. Please read the download and install instructions here.

For the sake of this tutorial, we will go through creating two different setups, first a point-to-point link between two devices, and next a point-to-multipoint setup that can support many individual devices communicating on the same channel.

The tncattach program offers a range of options to be given on the command line, and I’d suggest you read about them by entering the command:

tncattach --help

I won’t go over them all here, but I will explain the importance of some of them as we move through the tutorial.

It’s also worth noting, that if you are using tncattach with RNodes, you should put them into TNC mode with the rnodeconf program before running tncattach, as tncattach will not configure radio parameters, but expects the hardware to be ready to receive and transmit when it attaches.

Point-to-Point Links

For tncattach to create an interface, it needs to know at minimum what serial port the TNC is connected to, and what the baud-rate of the port is. For the rest of this tutorial, I will assume that a TNC is connected to each system, and available on serial port /dev/ttyUSB0, using a baud-rate of 115200. A minimal command for achieving this could look like:

sudo tncattach /dev/ttyUSB0 115200

Which will create and bring up a point-to-point interface on our system:

ifconfig
tnc0: flags=337<UP,POINTOPOINT,RUNNING,PROMISC> mtu 329
unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 txqueuelen 500 (UNSPEC)
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

Great! We actually have a usable, although unconfigured interface. In most cases, we probably want to specify a few options, though. Let’s enable the built-in IPv6 filter, so we don’t spam the channel with router solicitations and similar, and also tell tncattach that we will manually bring up the interface after creation, which is useful when making point-to-point links.

The default MTU of 329 bytes should work on almost all TNCs, but in most cases it can be increased. Let’s assume the connected TNC is an OpenModem, which supports an MTU of 576 bytes. We need to subtract any framing overhead from that, since that is the raw packet MTU of the device. For tncattach point-to-point interface the framing overhead is 4 bytes. For ethernet interfaces it is usually 18 bytes, but can be as high as 22, if you want to support VLAN tagging. So as a rule of thumb, subtract 4 bytes for point-to-point links and 22 bytes for ethernet links from the TNCs MTU. Aplpying this, we get an mtu of 572 bytes for OpenModem.

As a last consideration, we’ll tell tncattach to daemonize it’s process after creating the interface, so it will run in the background as a system process. This is achieved with the -d switch.

We can now put the above considerations together into the following command:

sudo tncattach /dev/ttyUSB0 115200 -d --noipv6 --noup --mtu 572

This will create the interface tnc0 as a point-to-point interface, but it will not yet be active. We’ll configure the point-to-point link with 10.0.0.1 being the local IP address, and 10.0.0.2 being the remote address, and bring the interface up:

sudo ifconfig tnc0 10.0.0.1 pointopoint 10.0.0.2

The interface is now up and running, and ready to communicate with the remote end:

ifconfig

tnc0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST> mtu 496
inet 10.0.0.1 netmask 255.255.255.255 destination 10.0.0.2
unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 txqueuelen 500 (UNSPEC)
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

On the remote system, the configuration commands would be similar, with only the order of IP-addresses changed:

sudo tncattach /dev/ttyUSB0 115200 -d --noipv6 --noup --mtu 572
sudo ifconfig tnc0 10.0.0.2 pointopoint 10.0.0.1

In the next example, we’ll setup a network that can support many devices communicating with each other on the same channel, using ethernet, which is suprisingly much simpler than point-to-point links.

One to Many, Many to One

Let’s assume that we have 10 TNC devices, all connected to the same radio channel, and we want everyone to be able to talk to everyone else. Setting up point-to-point links between everyone will get tedious very fast, so let’s use something else: Ethernet.

Setting up ethernet devices with tncattach is a surprisingly simple one-liner. Assuming we are still using OpenModems, and considering the MTU calculations from above, we can bring up an interface and configure it with the following command:

sudo tncattach /dev/ttyUSB0 115200 -d -e --noipv6 --mtu 554 --ipv4 10.91.0.1/24

The interface will now be created, have an IPv4 address configured and brought up. In this case we use the -e switch to specify we want a full ethernet device, not just a point-to-point link. We also use the –ipv4 switch to specify what IPv4 address the interface should be assigned. Please that you must supply addresses complete with a subnet mask in CIDR notation for the –ipv4 switch (hence the /24 at the end).

The interface is now up and running, and ready for use:

ifconfig

tnc0: flags=611<UP,BROADCAST,NOTRAILERS,RUNNING,ALLMULTI> mtu 554
inet 10.91.0.1 netmask 255.255.255.0 broadcast 10.91.0.255
ether 62:2a:60:89:a2:3a txqueuelen 1000 (Ethernet)
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

Repeat the same command on any other hosts, replacing the IP address with a unique address in the same subnet for every system, and every system can now talk to everyone else.

Since this is ethernet, you could easily set up a DHCP server on one system, and have that assign IP-addresses, instead of manually specifying them on each system. Or do anything you would normally be able to, really.

20 thoughts on “Ethernet and IP over Packet Radio TNCs with tncattach

  1. Mark,
    This is fantastic! I have been fooling around with this kissattach for some time and never really got anywhere. I am anxious to try tncattach.
    Could you elaborate on how to use this with either Kantronics kpc3, or MFJ 1270 TNCs?
    I can get them into kissmode, but am not sure if the mtu is preset. If the mtu is preset, then it sounds like I have to configure tncattach for the preset rate minus the 4 and 22 byte overheads…?
    Thanks for a very interesting motivator in ham radio!
    B

    1. Hi Bruce,
      If you can get the KPC3 into KISS mode you should more or less be good to go. I couldn’t find any documentation on what the maximum packet size it supports is, but the default that tncattach uses is relatively low, so maybe you don’t even have to specify it. I can’t remember what the default serial port speed of the KPC3 is, but lets assume it’s 9600 baud, and that it’s connected to a serial port called /dev/ttyUSB0. In that case, you could use the following command to get it up and running:

      sudo tncattach /dev/ttyUSB0 9600 –ethernet –noipv6 –ipv4 192.168.1.10/24

      That would bring up the tnc0 interface, disable ipv6 and set an ipv4 address for you. It should also set the MTU to 329 by default. If you find that it doesn’t work when sending large packets, you can try lowering the MTU to 250 for example:

      sudo tncattach /dev/ttyUSB0 9600 –ethernet –noipv6 –ipv4 192.168.1.10/24 –mtu 250

      It’s more or less the same procedure with the MFJ TNCs, as long as it’s in KISS mode and you know the right port and serial baud rate, it should more or less just work. Only caveat is you might have to adjust the MTU.

      Unfortunately I couldn’t find anything in either the Kantronics or MFJ manuals specifying what their MTU actually is! It should be pretty safe to assume that they can support at least around 330 though, since that’s the minimum size required for full AX.25 support.

  2. Where I can buy ready device?
    simple plug to usb (program to change firmware, setup language, parameter etc) and working

    In my opinion You must decide network similar Matrix or protocol mastodon

    1. Hi there
      I have two different devices for sale myself, RNode and OpenModem, you can take a look at them here on the page. Regarding software, I am working on a protocol called Reticulum, you might be interested in checking it out.

  3. Thanks Mark,
    Here is what I discovered so far….
    I am using a RPi 3b+ with a ftdi USB to rs232 adapter cable going into a Kantronics kpc3, and out to an old Kenwood vhf radio.
    I have had the setup working , both with the pUTTY/Kantronics interface, and set in kissmode using kissattach/axcall/axlisten. I
    even have had a limited success sending pings between two pi/Kantronics tnc/radio setups.
    So here are some of the foibles of using a set up like this,
    A kpc3 tnc will not accept programming or queries after it is kissmode if one is using an ftdi converter cable because the converter chip doesn’t seem to be able to make the correct character, to change INTFACE back to COMMAND, or NEWUSER. The result is that, one must program all the parameters into the tnc before changing INTFACE to KISSMODE. Or do a hard reset.
    Also because of the converter chip, there is no backspace key when in command mode, or while typing messages in the qso mode.
    Finally, the kpc3 sometimes locks up or jams when sending ip/tcp packets in kissmode (requiring a hard reset to become usuable again).
    Why write all this? Because, I have been trying this for some years now, and understand this can be a compound set of problems to over come.
    Mark, I followed your instructions and went to the github site. I first, simply downloaded the binaries for RPi, but failed to get anything to happen. Next, I followed your instructions and compiled the program, and it worked immediately. I don’t know what I forgot to do, to use the precompiled binaries, but perhaps you can add some obvious instructions to help the forgetful.

    Next, I would tell anyone trying this with an old tnc, to set up the tnc in kissmode first, with pUTTy or whatever command line editor, because once I initiated tncattach, I could no longer communicate with the tnc.

    Also, is “control Z” the correct command to stop tncattach?

    I used the tncattach parameters given in the example, for the openmodem. The internal baud rate was too fast, I believe, and so there was no communication between the RPi and the tnc. No problem, when I go try again, I will use 9600 as my internal baud rate, like you have directed.
    So, let’s imagine, I configure everything correctly, and the tnc hears, and responds to tncattach. Let’s say I try point to point. In the example for an old tnc, you wrote the address 192.168.1.10/24. I assume that’s just a random static address for the example. So the other point could be 192.168.1.12/24. If this is right, then a fair test might be to ping each point from the other, or run nmap 192.168.1.1-20?
    I want to get this far with my understanding before I commit to buying a pair of open modems.
    One thing I want to discover is what happens to file transfers @9600 baud. Is there a time out problem because the baudrate is so slow? I want start by simply transferring an image captured from the pi camera (nothing hi-resolution).
    Anyhow, thanks for doing this good work!
    A labor of love.
    Bruce

    1. Thanks for writing up all of this Bruce. That’s some invaluable information for anyone else attempting to do it with a similar setup.

      If you use Ctrl-Z, tncattach will just be suspended into the background, so to exit it, you should use Ctrl-C. That will tell tncattach to shut down nicely and release the serial port and network interface. You can also give the “-d” option to tncattach, which will make it a daemon process. This means that if it starts up successfully, it will go into the background but continue running. In this case, you won’t be able to exit it with Ctrl-C, you will have to use something like “killall tncattach”.

      And you are right regarding IP-addresses, they are just random addresses I choose (that are within the same subnet). So anything should do, as long as they are in the same subnet, they will be able to communicate. You can of course get fancy with DHCP servers and routes and such, but for the sake of this, keeping it simple is probably easier.

      The baud-rate specified to the tncattach command is the serial baudrate from the computer to the modem (and vice versa) only, so it will not affect on-air bitrate. But it must match what the modem expects (some TNCs can autodetect it, but most require a set rate, 9600 or 115200 for example).

      I’ve successfully transferred files over FTP with OpenModem. It’s of course slow, but very functional and useful. Since FTP uses TCP and IP, the TCP layer will automatically adjust to the link characteristics, and you can actually reliably transfer even relatively large files, as long as you have the time to wait for it. So small low-res pictures should be perfectly doable.

      I hope these comments clarified it even more.

      Kind regards,
      Mark

    2. Also, I forgot to ask you, could it be that you downloaded the “amd64” zip file instead of the “armhf” zip file? For Raspberry Pi, you need the “armhf” one. If you did indeed get that one, could you please let me know what the output of the following command is:

      cat /etc/os-release

      That will help me figure out why it isn’t running 🙂

  4. @Mark, is tncattach work with MicroModemGP firmware and MicroModem hardware ?

    1. It will work, but probably not too well, since the limited RAM of the atmega328p means there is not much room for packet buffering. For this kind of stuff, the best option is really to use the OpenModem platform instead.

        1. It’s funny, because it was my original intention for tncattach to work on both Linux and OSX. In fact I wrote the first part of the program on OSX. And most of the code is actually compatible with OSX. But when I found out how badly documented the network interface control calls are in the OSX kernel, I decided to only make it for Linux for now.

          I think it’s probably still possible to make it work on OSX, but I will need a few days of poking around at the kernel to figure out how all the undocumented stuff works 😉

          Also, regarding the modems, even though there is a small packet buffer in the atmega328p modems, I did implement a “flow control” feature in the latest versions of the firmware. After receiving a packet over the serial port, the modem will send a READY command back, if it has room for another packet in the buffer. If the host does not get a READY, it should wait sending more packets to the modem until it receives a READY. Using this feature, the packet buffering can be moved to the host instead of the modem, and the ram limitation is no problem then. This method is not supported in tncattach yet, but could be implemented in the future.

  5. Mark,
    I cannot find the forums. I think it might be a good idea to move this to the forum. I know we need some “buzz” to get people interested in doing this, (and ultimately, buy an open modem). But, the comments will get pretty long…what ever you wish is fine with me.
    I down loaded armf not amd64. I actually only use pi3s for packet…I am off grid and like the low power consumption, whereby I can leave everything on.
    I will completely retry loading the software on a different sd card for a different Pi and get some output for you. I have to do my homework too, though, I need to remember how to load binaries and start them.
    It’s very important to break the networking down to it’s simplest level, because hams of a certain age are amazingly tech adverse, and we need them to get interested in this.
    I am located in grid EN57G and we have a huge legacy packet network, so this new protocol would lend itself well here. Open mesh, or microwave meshnetworking is a fail here because of the terrain. VHF, on the other hand, is very effective.
    Thanks for your reply,
    B

    1. The forums are here: https://unsigned.io/forum/
      There should also be a link up in the menu bar, but I recently redid the website, so it it’s not visible on your computer, let me know and I’ll try to figure out why.

      But yeah, totally agree, this is better suited for a forum thread! After you register, your user will be locked (to prevent spam. So many spambots trying to post stuff). Just make a single post in the “Introductions” thread, and your user will be unlocked after a short time.

      Yeah, I can imagine microwave links are a bit of a pain up there. I’ve spent 4 years doing microwave links here in Denmark, and even in our flat little land it can be a challenge.

      Thanks for the info, I’ll check it out. I probably need to statically link everything for the Raspberry version then, I’ll try and update the binaries soon.

  6. Android phones using Chrome, will not display the menu choices under the “Unsigned io” title.
    This is why I could not find the Forum.
    I found the forum when I used the browser on my Raspberry Pi.
    If one clicks the Chrome menu bar, and chooses “desktop site”, then the forum menu choice is displayed.
    KE8DCJ

    1. Ah, so that’s what went wrong! Thank you very much for figuring it out for me. I’ll get that fixed.

    1. Very cool work on Arrow. I hope you’ll find the time to add a PA and start selling them!

      With regards to batman-adv, both no and yes. I haven’t used batman-adv with tncattach, but I do have some prior experience with it. In general I think most of the IP- and ethernet-based meshing protocols are a little on the heavy side for working over slow packet radio links, which was one of the motivations for starting the Reticulum project. If you don’t know about it, it’s a complete networking stack build from the ground up for zero-conf mesh networks over high-latency links with throughput down to around 1000 bits per second. It’s also designed to be very easy to get up and running 🙂

      1. Thanks for complements! I think I made a mistake using the CC1200 and a custom PCB. :/ These SX1276 chips are sweet with their built in PA and LoRa support. I did a bit of digging and while the SX1276 doesn’t have an CFM mode like the the CC1200, I think it would still be possible to TX AFSK by sending a CW and adjusting the carrier, and RX AFSK by reading the AFC register.

        Reticulum looks very cool. I’ll be spending some time looking into your code soon!

        I tried tncattach during the week. The interface is very clean. I’m having an issue with Arrow receiving packets with it. I’ll have to study it a bit more, but I’m sure the issue is on my side. Transmission works just fine. It’s strange to me because kissattach works just fine?

        1. Hmm, that’s very interesting. If you figure out whats up with it, I’m very interested to hear it. If there’s some issue in tncattach, I’d love to fix it obviously 🙂

          Yep, the SX1276 chips are very nice. I’ve been thinking the same, and I’m going to attempt to get them de/modulating AFSK at some point as well. Next major version of the RNode firmware will have support for other modulations than LoRa as well, so it will be even more flexible.

Leave a Reply

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