Having discussed the idea with a few people, both on the linux-hams mailing list and off-list, I’m starting to formalise a few plans for how this might work.
One option is to augment existing software stacks and inter-operate not just over-the-air, but at an API level. Brisbane WICEN have a fleet of TNCs all running TheNet X1J, which was a popular Net/ROM software stack for TAPR TNC2-compatible TNCs in the early 90s. Slowly, these are being replaced with Raspberry Pis equipped with Pi-TNCs and running LinBPQ.
These two inter-operate quite well, and the plan looks to be, to slowly upgrade all the sites to LinBPQ nodes.
Now, 6LoWHAM on TNCs that are nearly as old as I am just isn’t going to fly, but if I can link up to LinBPQ, this alternate protocol can be packaged up and installed along-side LinBPQ in an unobtrusive manner.
There are two things I need to be able to do:
- Send and receive raw AX.25 frames
- Read the routing table from LinBPQ
Sending and receiving raw frames
Looking at the interfaces that LinBPQ (and BPQ32) offers, the most promising option looks to be the AGWPE-compatible interface. The protocol is essentially a TCP link over which the AX.25 frames are encapsulated and sent.
There’s a good description of the protocol here, and looking at the sources for LinBPQ (third link from the bottom of the page), it looks as if the necessary bits of the protocol are present to send and receive raw frames.
In particular, to send raw UI frames, I need to send these as ‘M’ (direct) or ‘V’ frames (via digipeater), and to receive them, I need to make use of the monitoring mode (‘m’ frame).
Reading the routing table
This, is where things will be “fun”. The AGWPE interface does offer a “heard” frame, which can report on what stations have been heard. This I think isn’t going to be the holy grail I’m after, although it’ll be a start, maybe.
Alternatively, a way around this might be to “eavesdrop” on the Net/ROM routing frames. In monitor mode, I should theoretically hear all traffic, including these Net/ROM beacons. It’s not as nice as being able to simply read LinBPQ’s routing table, but at least I don’t have to generate the Net/ROM messages.
The other way would be to connect to the terminal interface on LinBPQ, and use the NODES command, parsing that. Ugly, but it’ll get me by. On that same page is NRR… which looks to be similar in function to TCP/IP’s traceroute. The feature is also supported by JNOS 2.0, which was released in 2006. Not old by packet radio standards, but old enough.
Identifying if a remote station supports 6LoWHAM
Now, this is the tricky bit. Identifying an immediate neighbour is easy enough, you can simply send an ICMPv6 neighbour solicitation message and see if they respond. In fact, I’m thinking that could be the immediate first step. There’s no support for service discovery as such, but nodes could advertise an “alias” (just one).
The best bet may be a suck-it-and-see approach. We should be able to “digipeat” via intermediate nodes as if they were plain L2 AX.25 digipeaters, thus if we have a reason to contact a given node (i.e. there’s unicast traffic queued up to be sent there), we can just try routing an AX.25 frame with a ICMPv6 neighbour solicitation and see if we get a neighbour advertisement.
This carries a risk though: a station may not react well to unknown traffic and may try to parse the message as something it is not. Thus for unicast, it is not a fail-safe method.
Multicast traffic however will be a challenge, and much of IPv6 relies on multicast. The Net/ROM station will not know anything about this, as it simply wasn’t a concept back in the day.
For subnets like ff03::1, which on Thread networks usually means “all full-function Thread devices”, this could be sent via non-6LoWHAM digipeaters by broadcasting via that digipeater to the AX.25 station alias “6LHMC” (6LoWHAM Multicast).
This could be used to provide tunnelling of multicast traffic where a route to a station has been discovered via Net/ROM and we need to safely test whether the station can in fact understand 6LoWHAM traffic without the risk of crashing it.
I think the next step might be to look at how a normal IPv6 node would “register” interest in a multicast group so that routers between it and the sender of such a group know where to forward traffic. IPv6 does have such a mechanism, and I think understanding how multicast traverses subnets is going to be key to making this work.