6LoWHAM

Logs from the 6LoWHAM project

6LoWHAM: TCP over sensor networks

I stumbled across this article regarding the use of TCP over sensor networks. Now, TCP has been done with AX.25 before, and generally suffers greatly from packet collisions. Apparently (I haven’t read more than the first few paragraphs of this article), implementations TCP can be tuned to improve performance in such networks, which may mean TCP can be made more practical on packet radio networks.

Prior to seeing this, I had thought 6LoWHAM would “tunnel” TCP over a conventional AX.25 connection using I-frames and S-frames to carry TCP segments with some header prepended so that multiple TCP connections between two peers can share the same AX.25 connection.

I’ve printed it out, and made a note of it here… when I get a moment I may give this a closer look. Ultimately I still think multicast communications is the way forward here: radio inherently favours one-to-many communications due to it being a shared medium, but there are definitely situations in which being able to do one-to-one communications applies; and for those, TCP isn’t a bad solution.

Comments having read the article

So, I had a read through it. The take-aways seem to be this:

TCP was historically seen as “too heavy” because the MCUs of the day (circa 2002) lacked the RAM needed for TCP data structures. More modern MCUs have orders of magnitude more RAM (32KiB vs 512B) today, and so this is less of an issue.
- For 6LoWHAM, intended for single-board computers running Linux, this will not be an issue.
A lot of early experiments with TCP over sensor networks tried to set a conservative MSS based on the actual link MTU, leading to TCP headers dominating the lower-level frame. Leaning on 6LoWPAN’s ability to fragment IP datagrams lead to much improved performance.
- 6LoWHAM uses AX.25 which can support 256-byte frames; vs 128-byte 802.15.4 frames on 6LoWPAN. Maybe gains can be made this way, but we’re already a bit ahead on this.
Much of the document considered battery-powered nodes, in which the radio transceiver was powered down completely for periods of time to save power, and the effects this had on TCP communications. Optimisations were able to be made that reduced the impact of such power-down events.
- 6LoWHAM will likely be using conventional VHF/UHF transceivers. Hand-helds often implement a “battery saver” mode — often this is configured inside the device with no external control possible (thus it will not be possible for us to control, or even detect, when the receiver is powered down). Mobile sets often do not implement this, and you do not want to frequently power-cycle a modern mobile transceiver at the sorts of rates that 802.15.4 radios get power-cycled!
Performance in ideal conditions favoured TCP, with the article authors managing to achieve 30% of the raw link bandwidth (75kbps of a theoretical 250kbps maximum), with the underlying hardware being fingered as a possible cause for performance issues.
- Assuming we could manage the same percentage; that would equate to ~360bps on 1200-baud networks, or 2.88kbps on 9600-baud networks.
With up to 15% packet loss, TCP and CoAP (its nearest contender) can perform about the same in terms of reliability.
A significant factor in effective data rate is CSMA/CA. aioax25 effectively does CSMA/CA too.

Its interesting to note they didn’t try to do anything special with the TCP headers (e.g. Van Jacobson compression). I’ll have to have a look at TCP and see just how much overhead there is in a typical segment, and whether the roughly double MTU of AX.25 will help or not: the article recommends using MSS of approximately 3× the link MTU for “fair” conditions (so ~384 bytes), and 5× in “good” conditions (~640 bytes).

It’s worth noting a 256-byte AX.25 frame takes ~2 seconds to transmit on a 1200-baud link. You really don’t want to make that a habit! So smaller transmissions using UDP-based protocols may still be worthwhile in our application.

6LoWHAM: Thoughts on how to distribute context and applications

So, one evening I was having difficulty sleeping, so like some people count sheep, turned to a different problem…6LoWPAN relies on all nodes sharing a common “context”. This is used as a short-hand to “compress” the rather lengthy IPv6 addresses for allowing two nodes to communicate with one another by substituting particular IPv6 address subnets with a “context number” which can be represented in 4 bits.

Fundamentally, this identifier is a stand-in for the subnet address. This was a sticking-point with earlier thoughts on 6LoWHAM: how do we agree on what the context should be? My thought was, each network should be assigned a 3-bit network ID. Why 3-bit? Well, this means we can reserve some context IDs for other uses. We use SCI/DCI values 0-7 and leave 8-15 reserved; I’ll think of a use for the other half of the contexts.

The node “group” also share a SSID; the “group” SSID. This is a SSID that receives all multicast traffic for the nodes on the immediate network. This might be just a generic MCAST-n SSID, where n is the network ID; or it could be a call-sign for a local network coordinator, e.g. I might decide my network will use VK4MSL-0 for my group SSID (network 0). Probably nodes that are listening on a custom SSID should still listen for MCAST-n traffic, in case a node is attempting to join without knowing the group SSID.

AX.25 allows for 16 SSIDs per call-sign, so what about the other 8? Well, if we have a convention that we reserve SSIDs 0-7 for groups; that leaves 8-15 for stations. This can be adjusted for local requirements where needed, and would not be enforced by the protocol.

Joining a network

How does a new joining node “discover” this network? Firstly, the first node in an area is responsible for “forming” the network — a node which “forms” a network must be manually programmed with the local subnet, group SSID and other details. Ensuring all nodes with “formation” capability for a given network is beyond the scope of 6LoWHAM.

When a node joins; at first it only knows how to talk to immediate nodes. It can use MCAST-n to talk to immediate neighbours using the fe80::/64 subnet. Anyone in earshot can potentially reply. Nodes simply need to be listening for traffic on a reserved UDP port (maybe 61631; there’s an optimisation in 6LoWPAN for 61616-61631). The joining node can ask for the network context, maybe authenticate itself if needed (using asymmetric cryptography – digital signatures, no encryption).

The other nodes presumably already know the answer, but for all nodes to reply simultaneously, would lead to a pile-up. Nodes should wait a randomised delay, and if nothing is heard in that period, they then transmit what they know of the context for the given network ID.

The context information sent back should include:

Group SSID
Subnet prefix
(Optional) Authentication data:
- Public key of the forming network (joining node will need to maintain its own “trust” database)
- Hash of all earlier data items
- Digital signature signed with included public key

Once a node knows the context for its chosen network, it is officially “joined”.

Routing to non-local endpoints

So, a node may wish to send a message to another node that’s not directly reachable. This is, after-all, the whole point of using a routing protocol atop AX.25. If we knew a route, we could encode it in the digipeater path, and use conventional AX.25 source routing. Nodes that know a reliable route are encouraged to do exactly that. But what if you don’t know your way around?

APRS uses WIDEN-n to solve this problem: it’s a dumb broadcast, but it achieves this aim beautifully. n just stands for the number of hops, and it gets decremented with each hop. Each digipeater inserts itself into the path as it sends the frame on. APRS specs normally call for everyone to broadcast all at once, pile-up be damned. FM capture effect might help here, but I’m not sure its a good policy. Simple, but in our case, we can do a little better.

We only need to broadcast far enough to reach a node that knows a route. We’ll use ROUTE-n to stand for a digipeater that is no more than n hops away from the station listed in the AX.25 destination field. n must be greater than 0 for a message to be relayed. AX.25 2.0 limits the number of digipeaters to 8 (and 2.2 to 2!), so naturally n cannot be greater than 8.

So we’ll have a two-tier approach.

Routing from a node that knows a viable route

If a node that receives a ROUTE-n destination message, knows it has a good route that is n or less hops away from the target; it picks a randomised delay (maybe 0-5 seconds range), and if no reply is heard from another node; it relays the message: the ROUTE-n is replaced by its own SSID, followed by the required digipeater path to reach the target node.

Routing from a node that does not know a viable route

In the case where a node receives this same ROUTE-n destination message, does not know a route, and hasn’t heard anyone else relay that same message; it should pick a randomised delay (5-10 second range), and if it hasn’t heard the message relayed via a specific path in that time, should do one of the following:

If `n` is greater than 1:

Substitute ROUTE-n in the digipeater path with its own SSID followed by ROUTE-(n-1) then transmit the message.

If `n` is 1 (or 0):

Substitute ROUTE-n with its own SSID (do not append ROUTE-0) then transmit the message.

Routing multicast traffic

Discovering multicast listeners

I’ll have to research MLD (RFC-3810 / RFC-4604), but that seems the sensible way forward from here.

Relaying multicast traffic

If a node knows of downstream nodes that ordinarily rely on it to contact the sender of a multicast message, and it knows the downstream nodes are subscribers to the destination multicast group, it should wait a randomised period, and forward the message on (appending its SSID in the digipeater path) to the downstream nodes.

Application thoughts

I think I have done some thoughts on what the applications for this system may be, but the other day I was looking around for “prior art” regarding one-to-many file transfer applications.

One such system that could be employed is UFTP. Yes, it mentions encryption, but that is an optional feature (and could be useful in emcomm situations). That would enable SSTV-style file sharing to all participants within the mesh network. Its ability to be proxied also lends itself to bridging to other networks like AMPRnet, D-Star packet, DMR and other systems.

2021/09/16 by Redhatter (VK4MSL) 6LoWHAM Amateur Radio Emergency Communications Projects Public Syndication Thinktank 0

6LoWHAM: Working towards connected-mode operation in aioax25

The past few months have been quiet for this project, largely because Brisbane WICEN has had my spare time soaked up with an RFID system they are developing for tracking horse rides through the Imbil State Forest for the Stirling’s Crossing Endurance Club.

Ultimately, when we have some decent successes, I’ll probably be reporting more on this on WICEN’s website. Suffice to say, it’s very much a work-in-progress, but it has proved a valuable testing ground for aioax25. The messaging system being used is basically just plain APRS messaging, with digipeating thrown in as well.

Since I’ve had a moment to breathe, I’ve started filling out the features in aioax25, starting with connected-mode operation. The thinking is this might be useful for sending larger payloads. APRS messages are limited to a 63 character message size with only a subset of ASCII being permitted.

Thankfully that subset includes all of the Base64 character set, so I’m able to do things like tunnel NTP packets and CBOR blobs through it, so that stations out in the field can pull down configuration settings and the current time.

As for the RFID EPCs, we’re sending those in the canonical hexadecimal format, which works, but the EPC occupies most of the payload size. At 1200 bits per second, this does slow things down quite a bit. We get a slight improvement if we encode the EPCs as Base64. We’d get a 200% efficiency increase if we could send it as binary bytes instead. Sending a CBOR blob that way would be very efficient.

The thinking is that the nodes find each-other via APRS, then once they’ve discovered a path, they can switch to connected mode to send bulk transfers back to base.

Thus, I’ve been digging into connected mode operation. AX.25 2.2 is not the most well-written spec I’ve read. In fact, it is down-right confusing in places. It mixes up little-endian and big-endian fields, certain bits have different meanings in different contexts, and it uses concepts which are “foreign” to someone like myself who’s used to TCP/IP.

Right now I’m making progress, there’s an untested implementation in the connected-mode branch. I’m writing unit test cases based on what I understand the behaviour to be, but somehow I think this is going to need trials with some actual AX.25 implementations such as Direwolf, the Linux kernel stack, G8BPQ stack and the implementation on my Kantronics KPC3 and my Kenwood TH-D72A.

Some things I’m trying to get an answer to:

In the address fields at the start of a frame, you have what I’ve been calling the ch bit.
On digipeater addresses, it’s called H and it is used to indicate that a frame has been digipeated by that digipeater.
When seen in the source or destination addresses, it is called C, and it describes whether the frame is a “command” frame, or a “response” frame.

An AX.25 2.x “command” frame sets the destination address’s C bit to 1, and the source address’s C bit to 0, whilst a “response” frame in AX.25 does the opposite (destination C is 0, source C is 1).

In prior AX.25 versions, they were set identically. Question is, which is which? Is a frame a “command” when both bits are set to 1s and a “response” if both C bits are 0s? (Thankfully, I think my chances of meeting an AX.25 1.x station are very small!)
In the Control field, there’s a bit marked P/F (for Poll/Final), and I’ve called it pf in my code. Sometimes this field gets called “Poll”, sometimes it gets called “Final”. It’s not clear on what occasions it gets called “Poll” and when it is called “Final”. It isn’t as simple as assuming that pf=1 means poll and pf=0 means final. Which is which? Who knows?
AX.25 2.0 allowed up to 8 digipeaters, but AX.25 2.2 limits it to 2. AX.25 2.2 is supposed to be backward compatible, so what happens when it receives a frame from a digipeater that is more than 2 digipeater hops away? (I’m basically pretending the limitation doesn’t exist right now, so aioax25 will handle 8 digipeaters in AX.25 2.2 mode)
The table of PID values (figure 3.2 in the AX.25 2.2 spec) mentions several protocols, including “Link Quality Protocol”. What is that, and where is the spec for it?
Is there an “experimental” PID that can be used that says “this is a L3 protocol that is a work in progress” so I don’t blow up someone’s station with traffic they can’t understand? The spec says contact the ARRL, which I have done, we’ll see where that gets me.
What do APRS stations do with a PID they don’t recognise? (Hopefully ignore it!)

Right at this point, the Direwolf sources have proven quite handy. Already I am now aware of a potential gotcha with the AX.25 2.0 implementation on the Kantronics KPC3+ and the Kenwood TM-D710.

I suspect my hand-held (Kenwood TH-D72A) might do the same thing as the TM-D710, but given JVC-Kenwood have pulled out of the Australian market, I’m more like to just say F### you Kenwood and ignore the problem since these can do KISS mode, bypassing the buggy AX.25 implementation on a potentially resource-constrained device.

NET/ROM is going to be a whole different ball-game, and yes, that’s on the road map. Long-term, I’d like 6LoWHAM stations to be able to co-exist peacefully with other stations. Much like you can connect to a NET/ROM node using traditional AX.25, then issue connect commands to jump from there to any AX.25 or NET/ROM station; I intend to offer the same “feature” on a 6LoWHAM station — you’ll be able to spin up a service that accepts AX.25 and NET/ROM connections, and allows you to hit any AX.25, NET/ROM or 6LoWHAM station.

I might park the project for a bit, and get back onto the WICEN stuff, as what we have in aioax25 is doing okay, and there’s lots of work to be done on the base software that’ll keep me busy right up to when the horse rides re-start in 2020.

2019/11/24 by Redhatter (VK4MSL) 6LoWHAM Amateur Radio Emergency Communications Projects Public Syndication Thinktank WICEN 0

6LoWHAM: AX.25 Python library and addressing thoughts

Lately, I had a need for a library that would talk to a KISS TNC and allow me to exchange UI frames over an AX.25 network.

This is part of a project being undertaken by Brisbane Area WICEN Group. We’ve been tasked with the job of reporting scans from RFID tag readers back to base… and naturally we’ll be using the AX.25 network we’re already familiar with. The plan is to use APRS messaging (to keep things simple) to submit the location, time and hardware address of each RFID read.

For this, I needed something I also need for this project, a tool to encode and decode the UI frames. I had initially thought of just using LinBPQ or similar to provide the interface to AX.25, but in the end, it was easier for me to write my own simple AX.25 stack from scratch.

aioax25 obviously is nowhere near a replacement for other AX.25 stacks in that it only encodes and decodes frames, but it’s a first step in that journey. This library is written for Python 3.4 and up using the asyncio module and pyserial. At the moment I have used it to somewhat crudely send and receive APRS messages, and so with a bit of work, it’ll suffice for the WICEN project.

That does mean I’m not shackled in terms of what bits I can set in my AX.25 headers. One limitation I have with my mapping of 6LoWHAM addresses to AX.25 addresses is that I cannot represent all characters or the “group” bit.

This lead to the limitation that if I defined a group called VK4BWI-0, that group may not have a participant with the call-sign of VK4BWI-0 because I would not be able to differentiate group messages from direct messages.

By writing my own AX.25 stack, I potentially can side-step that limitation: I can utilise the reserved bits in a call-sign/SSID to represent this information. I avoided their use before because the interfaces I planned on using did not expose them, but doing it myself means they’re directly accessible. The AX.25 protocol documentation states:

The bits marked “r” are reserved bits. They may be used in an agreed-upon manner in individual networks. When not implemented, they should be set to one.
https://www.tapr.org/pub_ax25.html

Now, the question is, if I set one to 0, would it reach the far end as a 0? If so, this could be a stand-in for the group bit — stored inverted so that a 1 represents a unicast destination and 0 represents a group.

The other option is to just prepend the left-over bits to the start of the message payload. This has the bonus that I can encode the full-callsign even if that call-sign does not fit in a standard AX.25 message.

So a message sent to VK4FACE-6 (let’s pretend F-calls can use packet for the sake of an example) would be sent to AX.25 SSID VK4FAC-6, and the first few bytes would encode the missing E and the group/unicast bit. If the station VK4FAC were also on frequency, the software stack at their end would need to filter based on those initial payload bytes.

We support 8-character call-signs, so we need to represent 2 left-over characters plus a group bit. Add space for two-more characters for the source call-sign (which may not be a group), we require about 3 bytes.

At this point we might as well use 4, store the extra bytes as 7-bit ASCII, with the spare MSBs of each byte encoding the group bit and one spare bit. An extra 8 bits is bugger all really even at 1200 baud.

Obviously, NET/ROM has no knowledge of this. Stations that are on the other side of a non-6LoWHAM digipeater need to explicitly source-route their hops to reach the rest of a mesh network, and the nodes the other side need to “remember” this source route.

This latter scheme also won’t work for connected mode, as there’s no scope to shoehorn those bytes in the information field and still remain AX.25 compatible — it will only work for 6LoWHAM UI frames.

Anyway, it’s food for thought.

2019/04/11 by Redhatter (VK4MSL) 6LoWHAM Amateur Radio Emergency Communications Projects Public Syndication Thinktank WICEN 0

6LoWHAM: Dissecting packets in Python

Recently, I’ve been looking at the problem of how to retrieve IPv6 traffic from the network stack of my workstation and manipulate it for transmission over AX.25.

My last experiments focussed on the TUN/TAP interface in Linux. Using this interface, I could create a virtual network interface that piped its traffic to a file descriptor in a program written in C.

One advantage of using the C language for this is that, as binding to the TAP interface requires root privileges, the binary could be installed setuid root. Thus, any time it started, it would be running as root. From there, it could do what it needed, then drop privileges back to a regular user.

The program would just run as a child process… when there was traffic received from the kernel, it would just spit that out to stdout. If my parent application had something to send, it would feed that into stdin.

6lhagent is an implementation of that idea. It’s pretty rough, but it seems to work. It uses a simple protocol to frame the Ethernet packets so that it can maintain synchronisation with the parent process. All frames are ACKed or NAKed, depending on whether they were understood or not. The protocol is analogous to KISS or SLIP in concept. The framing is very different to these protocols, but the concept is that of frames delimited by a byte sequence, with occurrences of the special byte sequences replaced with place-holders to prevent the parser getting confused.

I then wrote this Python script which uses the asyncio IO loop to run 6lhagent and dump the packets it receives:

$ python3 demo/dumper.py 
Interface data: b'V\xc7\x05\\yA\x05\x00\x00\x00\x00\xca\x04tap0'
Interface: MAC=[86, 199, 5, 92, 121, 65] MTU=1280 IDX=202 NAME=tap0
Ethernet traffic: b'33330000001656c7055c794186dd600000000024000100000000000000000000000000000000ff0200000000000000000000000000163a000502000001008f00f5ec0000000104000000ff0200000000000000000001ff5c7941'
From: 33:33:00:00:00:16
To:   56:c7:05:5c:79:41
Protocol: 86dd
IPv6: Priority 0, Flow 000000
From: ::
To:   ff02::16
Length: 36, Next header: 0, Hop Limit: 1
Payload: b':\x00\x05\x02\x00\x00\x01\x00\x8f\x00\xf5\xec\x00\x00\x00\x01\x04\x00\x00\x00\xff\x02\x00\x00\x00\x00\x00\x00\x00\x00\x00\x01\xff\\yA'
Ethernet traffic: b'33330000001656c7055c794186dd600000000024000100000000000000000000000000000000ff0200000000000000000000000000163a000502000001008f00f5ec0000000104000000ff0200000000000000000001ff5c7941'
From: 33:33:00:00:00:16
To:   56:c7:05:5c:79:41
Protocol: 86dd
IPv6: Priority 0, Flow 000000
From: ::
To:   ff02::16
Length: 36, Next header: 0, Hop Limit: 1
Payload: b':\x00\x05\x02\x00\x00\x01\x00\x8f\x00\xf5\xec\x00\x00\x00\x01\x04\x00\x00\x00\xff\x02\x00\x00\x00\x00\x00\x00\x00\x00\x00\x01\xff\\yA'
Ethernet traffic: b'3333ff5c794156c7055c794186dd6000000000203aff00000000000000000000000000000000ff0200000000000000000001ff5c79418700bebb00000000fe8000000000000054c705fffe5c79410e01a02d5c9a6698'
From: 33:33:ff:5c:79:41
To:   56:c7:05:5c:79:41
Protocol: 86dd
IPv6: Priority 0, Flow 000000
From: ::
To:   ff02::1:ff5c:7941
Length: 32, Next header: 58, Hop Limit: 255
ICMP Type 135, Code 0, Checksum bebb
Data: b'\x00\x00\x00\x00\xfe\x80\x00\x00'
Payload: b'\x00\x00\x00\x00T\xc7\x05\xff\xfe\\yA\x0e\x01\xa0-\\\x9af\x98'
Ethernet traffic: b'33330000001656c7055c794186dd6000000000240001fe8000000000000054c705fffe5c7941ff0200000000000000000000000000163a000502000001008f0025070000000104000000ff0200000000000000000001ff5c7941'
From: 33:33:00:00:00:16
To:   56:c7:05:5c:79:41
Protocol: 86dd
IPv6: Priority 0, Flow 000000
From: fe80::54c7:5ff:fe5c:7941
To:   ff02::16
Length: 36, Next header: 0, Hop Limit: 1
Payload: b':\x00\x05\x02\x00\x00\x01\x00\x8f\x00%\x07\x00\x00\x00\x01\x04\x00\x00\x00\xff\x02\x00\x00\x00\x00\x00\x00\x00\x00\x00\x01\xff\\yA'
Ethernet traffic: b'33330000001656c7055c794186dd6000000000240001fe8000000000000054c705fffe5c7941ff0200000000000000000000000000163a000502000001008f009cab0000000104000000ff0200000000000000000000000000fb'
From: 33:33:00:00:00:16
To:   56:c7:05:5c:79:41
Protocol: 86dd
IPv6: Priority 0, Flow 000000
From: fe80::54c7:5ff:fe5c:7941
To:   ff02::16
Length: 36, Next header: 0, Hop Limit: 1
Payload: b':\x00\x05\x02\x00\x00\x01\x00\x8f\x00\x9c\xab\x00\x00\x00\x01\x04\x00\x00\x00\xff\x02\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xfb'

The thinking is that the bulk of the proof-of-concept will be done in Python. My reasoning for this is that it’s usually easier to prototype in a higher-level language than in C, and in this application, speed is not important. At best our network interface will be running at 9600 baud — Python will keep up just fine. Most of it will be at 1200 baud.

The Python code will do some packet filtering (e.g. filtering out the multicast NS messages, which are a no-no in RFC-6775) and to add options where required. It’ll also be responsible for rate-limiting the firehose-like output of the tap interface from the host so the AX.25 network doesn’t get flooded.

The proof of concept is coming together. Next steps are to implement an IPv6 stack of sorts in Python to dissect the datagrams.

2019/01/19 by Redhatter (VK4MSL) 6LoWHAM Amateur Radio Emergency Communications Projects Public Syndication WICEN 0

6LoWHAM: IP Addressing

For 6LoWHAM, it could work that we just use the link-local address space to directly communicate between stations and leave it at that.

If I want to send a message to VK4BWI-5 from my station VK4MSL-9, I could just fire off a packet to fe80::6894:49ff:feae:7318 directed to my 6LoWHAM interface and be done with it. This then requires one of two things:

that VK4BWI-5 can directly communicate with me
that the intermediate stations know to forward my message on to that station

(1) is easy enough. (2) raises the question of “what is local”?

Supposing that this protocol took off, and suddenly the WIA decides to earmark special frequencies on a few bands for 6LoWHAM, with a fairly complete network stretching up the eastern seaboard of Australia. If my station sends a router solicitation from my home QTH in Brisbane, does someone in Melbourne really care to hear it? I’d wager this is a recipe for a very clogged packet network!

In Thread, the “link local” scope only gets you as far as the nodes that can directly hear you. It does mean that protocols like mDNS, which rely on the “link-local” multicast scope aren’t going to reach all nodes, but it also means that far flung nodes don’t need to listen to all the low-level chatter. For communications between nodes, an “on-mesh” prefix is used, and for mesh-wide multicast, a “realm-local” prefix of ff03::/64 is defined.

In truth, it’s highly unlikely that we’d have “one” single network. More likely it’ll be a mesh of interconnected networks with trunk links going via some other band (or perhaps VPNs over the Internet). For that to work, we can’t rely on just link-local networking, we actually need a routable network address for the mesh.

The Thread “mesh local” prefix is actually defined by the network’s extended IEEE-802.15.4 PAN ID, which is a 64-bit number that you define when setting up the network. Thread simply takes the most significant 40 bits of this, slaps fd in front and pads it out with zeros to 64-bits. The PAN ID 0x0123456789abcdef forms the subnet fd01:2345:6789::/64. This can be seen in the OpenThread sources.

This wastes 16-bits of address space normally reserved for the ULA subnet ID and throws away 24-bits of the PAN ID. For our network, we don’t need 16-bits worth of subnets, we just need one. We also don’t have a PAN ID in AX.25.

The thinking is, we’ll use a “group” address. This will be a regular AX.25 SSID, which will translate to a MAC which has the group bit set. (Exactly how I’ll differentiate between a station SSID and a group SSID I’m not sure. Probably will look at the destination IP, if it’s multicast then the group bit gets set.)

Supposing we were to use this for the International Rally of Queensland (an event which is now defunct), we might create a 6LoWHAM network with a group address of “IROQ19”. The MAC address used for group-wide communications would be 03:01:cd:e5:a9:f8.

We can derive a prefix from this MAC address. A ULA normally consists of a 7-bit ULA prefix, a 1-bit “global/local” bit, a 40-bit global ID, and a 16-bit subnet ID.

The ULA prefix is fc::/7. The global/local bit is always set to 1 (local) because no one has come up with a way that ULAs can be globally administered. 40 bits is a bit tight, we could truncate our MAC to 40 bits and ignore the subnet ID like Thread do, that gives us a subnet of fd03:1cd:5ea9::/64.

The last 3 bits of the SSID though, are like a subnet ID. So if we move those 3 bits to set the last 3 bits of the prefix, we can make some use of that subnet ID, but still waste 13 bits with zeros.

Alternatively, we can consider the global ID and subnet ID to be one 56-bit field. We effectively shrink the subnet ID to 3 bits. That gives us a 53-bit global ID, which now fits the remaining 45-bits of our MAC and leaves us with 8 bits left over.

We can discard the lowest two bits in the first byte of the MAC as those (the group and local bits) will be the same for all groups, so that gives us another two bits. 10 bits isn’t a lot, but it’s enough to encode “AR” (amateur radio) in ITA-2, thus giving us a recognisable subnet mask for all 6LoWHAM networks. We wind up with the following:

┌─ULA─┐L┌──"AR"──┐┌───────────── Network Address ──────────────┐
1111110100010010100000000000000111001101111001011010100111111000
└──┼───┼───┼───┼───┼───┼───┼───┼───┼───┼───┼───┼───┼───┼───┼───┤
   f   d   1   2 : 8   0   0   1 : c   d   e   5 : a   9   f   8 /64

This actually has me thinking whether the call-sign part of the SSID should be right-padded out to make the network address consistent. Maybe my SSID to MAC algorithm could do with a tweak there as it may make routing easier as it’ll put all those zeros to the right.

In Thread, the mesh-local prefix isn’t route-able beyond the mesh, there’s a separate prefix handed out by border routers for that. In our case, I don’t think there’s any point in complicating matters by having more than one route-able prefix for a mesh. If a station participates in two networks that share a frequency, then sure, that node may have an address on each network, but each network should share a common identity.

Thus in the contrived example of having a large network along the coastline: it’d be an “inter-network” of smaller meshes, linked together via router nodes which know how to hop between them. Those routes may be via point-to-point microwave links, HF, Internet tunnels, etc.

The subnets used for these other networks may be assigned a “context identifier” which is 4-bits. I’ll have to figure out if there’s a sane way to do that on a given network. Most 802.15.4 networks have a “PAN co-ordinator” which could be looking after that. Thread networks elect a “leader” node.

Given the small number of identifiers, and the low probability of this being used, this should be manually administered. Even without a context ID being assigned, one can still route between the subnets, just that the full IPv6 address needs to be given for the foreign node, so you incur a 16-byte penalty doing so. Thus the context IDs will probably be handed out for “popular routes”, with the mesh prefix being “context 0”.

I haven’t yet given thought to how this “context” would be disseminated over the mesh or kept updated. That is a can of worms for another day.

2019/01/12 by Redhatter (VK4MSL) 6LoWHAM Amateur Radio Emergency Communications Projects Public Syndication WICEN 0

6LoWHAM: Exploring the TUN/TAP interface

One of the aims of 6LoWHAM was to provide a means to send IPv6 traffic between user applications and the AX.25 network.

In order to do this, the applications have to have some way of injecting their IP traffic. The canonical way this is done is through the operating system’s TCP/IP stack. This requires that we have an interface to the operating system kernel in order to receive that IP traffic destined for the airwaves.

Now, we could write a kernel driver for this, but it’s going the long way around to do it. Especially as we intend to interface to software that runs in userspace for the actual transmission. Our driver at best would be just taking the raw Ethernet frame, extracting the IP part, and forwarding that back to our program running in userspace.

There’s a driver that does that for us: TUN/TAP. This driver can either create a TUNnel device, which forwards IP datagrams, or a TAP device, which forwards Ethernet frames. We’ll focus on the TUN mode of this driver here.

The idea is this will create an IP tunnel, with one side exposing a network device to the kernel, and the other side being a file descriptor in a userspace application that just reads and writes raw IP frames. How it generates and processes those frames is entirely up to the software author. Most famous uses for this device are VPNs, so taking the IP datagram, encrypting it, then encapsulating it in an IP datagram (usually UDP) to be sent over the Internet to some other peer, which reverses the process and writes the original packet to its tunnel file descriptor.

In our case, we’ll be dissecting it a bit to extract the key fields, then applying our own “compression” defined in the 6LoWHAM specs, then forwarding it on to our AX.25 stack (probably LinBPQ or Direwolf) to be sent as an AX.25 UI frame.

The first step in this journey was actually figuring out what the packets look like on a tunnel device. I created this little program to explore the idea.

It just needs the usual C toolchain and libraries on a Linux system. I tested with Gentoo and Linux kernel 4.15. Building it is a simple make command. If you then run the resulting binary as root, you’ll find a tun0 device (or maybe some other number) created.

Bring the interface up, and you should start to see some traffic as the host tries to talk to is new (and very much mute) peer:

RC=0 stuartl@rikishi ~/projects/6lowham/packetdumper $ make 
cc    -c -o linuxtun.o linuxtun.c
cc    -c -o main.o main.c
cc -o packetdumper linuxtun.o main.o
RC=0 stuartl@rikishi ~/projects/6lowham/packetdumper $ sudo ./packetdumper 
Password: 
^Z
[1]+  Stopped(SIGTSTP)        sudo ./packetdumper
RC=148 stuartl@rikishi ~/projects/6lowham/packetdumper $ sudo ip link set dev tun0 up
RC=0 stuartl@rikishi ~/projects/6lowham/packetdumper $ fg
sudo ./packetdumper
Flags: 0x0000  Protocol: 0x86dd
  48:  0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15
   0: 60 00 00 00 00 08 3a ff fe 80 00 00 00 00 00 00
  16: 5e be 89 41 7b 19 d5 60 ff 02 00 00 00 00 00 00
  32: 00 00 00 00 00 00 00 02 85 00 44 bd 00 00 00 00
Flags: 0x0000  Protocol: 0x86dd
  48:  0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15
   0: 60 00 00 00 00 08 3a ff fe 80 00 00 00 00 00 00
  16: 5e be 89 41 7b 19 d5 60 ff 02 00 00 00 00 00 00
  32: 00 00 00 00 00 00 00 02 85 00 44 bd 00 00 00 00

I didn’t bother to decode the IP datagram further, but if you look at the Wikipedia IPv6 Packet article, it isn’t difficult to see what’s going on. In this case, we can see it’s an IPv6 packet both from the Protocol field (0x86dd is the Ethertype for IPv6), and from the first 4 bits of the frame payload.

The traffic class and flow label are both 0s here. The IPv6 payload length is just 8 bytes, so most of this is in fact IPv6 header data. Next header is type 0x3a (IPv6 ICMP) and the hop limit is 255. This is followed by the source address (my laptop’s link-local address fe80::5ebe:8941:7b19:d560) and the destination address (all link-local routers multicast address ff02::2).

The ICMPv6 message is the last 8 bytes; and in this case, it’s type is 0x85 (router solicitation), the code is 0x00, the two bytes after that are the checksum and the message (4 bytes) is all zeros.

Quite how that address was chosen is something I’ll have to get to grips with. Yes, it’s SLAAC, but where did it get the hardware address from? That I’ll have to figure out.

The alternative is to use a TAP interface, which means I choose the MAC address, and thus can control what the SLAAC-derived address becomes. Ohh, and it goes without saying that the privacy extensions will be a big no no on the air: we’re relying on the fact that we can derive the IPv6 address from the SSID of the station both for technical reasons and to legally meet the requirements for stations to “identify” who they are and whom they are talking to. SLAAC privacy will make a mess of that.

So controlling this link-local address is a must. I guess next stop: let’s look at a tap device. I’ve just made some changes to explore the differences from the application end. There isn’t a lot of difference here.

RC=130 stuartl@rikishi ~/projects/6lowham/packetdumper $ sudo ./packetdumper -tap
Password: 
^Z
[1]+  Stopped(SIGTSTP)        sudo ./packetdumper -tap
RC=148 stuartl@rikishi ~/projects/6lowham/packetdumper $ sudo ip link set tap0 up
RC=0 stuartl@rikishi ~/projects/6lowham/packetdumper $ fg
sudo ./packetdumper -tap
Flags: 0x0000  Protocol: 0x86dd
  90:  0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15
   0: 33 33 00 00 00 16 ce 65 0c 34 48 34 86 dd 60 00
  16: 00 00 00 24 00 01 00 00 00 00 00 00 00 00 00 00
  32: 00 00 00 00 00 00 ff 02 00 00 00 00 00 00 00 00
  48: 00 00 00 00 00 16 3a 00 05 02 00 00 01 00 8f 00
  64: 27 22 00 00 00 01 04 00 00 00 ff 02 00 00 00 00
  80: 00 00 00 00 00 01 ff 34 48 34
Flags: 0x0000  Protocol: 0x86dd
  86:  0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15
   0: 33 33 ff 34 48 34 ce 65 0c 34 48 34 86 dd 60 00
  16: 00 00 00 20 3a ff 00 00 00 00 00 00 00 00 00 00
  32: 00 00 00 00 00 00 ff 02 00 00 00 00 00 00 00 00
  48: 00 01 ff 34 48 34 87 00 af 03 00 00 00 00 fe 80
  64: 00 00 00 00 00 00 cc 65 0c ff fe 34 48 34 0e 01
  80: 61 78 48 c1 ac aa

The big difference is now we have an Ethernet header prepended. The proto field in the packet information now duplicates what we can see in the Ethernet frame header (bytes 12 and 13), and the IPv6 packet starts from byte 14.

I think this is the mode 6LoWHAM will use. It’s possible to set the MAC address on the created tap0 device to whatever 46 bits we like, the remaining two bits in the MAC address are for defining whether the address is global or local (we’ll set ours to “local”), and the other sets whether this is a multicast or unicast address. The SLAAC address will closely match this address with two differences:

The MAC will have the bytes 0xff 0xfe inserted into the middle.
The “global/local” bit is inverted. So for the 2001:db8::/64 prefix:
- aa:bb:cc:dd:ee:ff becomes 2001:db8::a8bb:ccff:fedd:eeff
- a8:bb:cc:dd:ee:ff becomes 2001:db8::aabb:ccff:fedd:eeff

That latter point had me confused at first, I thought it might’ve been that a bit got cleared, but instead it’s just inverted, so completely reversible.

2019/01/12 by Redhatter (VK4MSL) 6LoWHAM Amateur Radio Emergency Communications Projects Public Syndication WICEN 0

6LoWHAM: Route discovery thoughts

Thinking about the routing problem a little more… if I wanted to do a purely “native” routing scheme not involving Net/ROM routing update broadcasts, one has to wonder what such a system would look like.

Net/ROM L3 is really just intended to “bootstrap” things… there’s the prospect of using Net/ROM L4 for tunnelling TCP traffic, but really it’s the L3 part that interests me as a way of hopping between fragments of the mesh that may be linkable via a non-6LoWHAM capable digipeater.

Net/ROM’s periodic broadcasts are inefficient, divulging a node’s entire routing table is not an ideal situation. So what’s the alternative? IPv6 nodes already send a “neighbour discovery” packet when they don’t know the MAC address of a neighbour, this is a trigger for a “neighbour advertisement” response.

I’m thinking 6LoWHAM will send NAs periodically anyway. ACMA rules require identifying every 10 minutes. Since the NA will include the call-sign of the station (in bit-shifted ASCII), doing that every 10 minutes takes care of the ACMA requirement. An IPv6 NA message is not a big payload.

Given this will be sent to the ff02::1 multicast group, all nodes able to hear the beaconing station will receive it. Unlike a IEEE 802.11 or 802.3 network though, not all nodes on the mesh will hear it.

The same is true of ND messages. If the neighbour is in ear-shot and able to respond, it likely will, but that isn’t a guarantee. Something in the link-local scope will likely be the answer, probably a daemon listening on a UDP port and sending to the ff02::1 group.

Unicast routing

When a station wishes to make contact with a station that’s not an immediate neighbour, I’m thinking of a broadcast similar to how APRS does things. APRS uses special call-signs WIDEn-m, where the hop-limit is encoded in those messages.

A UDP message would be constructed asking “Who can reach X within N hops?” and sent to ff02::1 to some “well-known” port.

The first second is reserved for responses from nodes that know a route, either through Net/ROM, or maybe they’ve been in contact with that station before. They respond something along the lines of “X via A,B,C, quality Q”, where A, B, C are digipeaters and Q is some link quality value.

Not sure how I’ll derive Q just yet. Possibly based on packet loss… we’ll think of something.

If no responses are heard, the routers that heard the message re-broadcast it and listen for replies. In the re-broadcast, each router appends its 48-bit 6LoWHAM address and a link quality to the message payload. The hop limit would also get decremented. That way, it can break cycles, and it gives a direct unicast path for the distant node to respond.

The same algorithm applies: wait a second for immediate responses, then any routers downstream append their addresses/link quality values, decrement the hop limit, and re-broadcast.

Again, any node that overhears the message (including the target node), may respond. It does so via a direct unicast, sent using conventional AX.25 digipeating. Any router en route that relays the message may also cache the result. The “mesh” gets to learn of where everyone is as-required rather than by default with Net/ROM.

If the hop limit reaches zero, no further re-broadcasts are made, the message stops there.

When the source node hears the replies, each reply resets a 100msec timer. 100msec after the last reply, it chooses three “best” routes, and sends a ICMPv6 ND message via each one to the target station. The station replies to all three back via those routes with an ICMPv6 NA. If a message is lost via one of those routes, that route is demoted in quality.

Once replies have arrived back at the source, it picks the best route based on the updated quality information, and begins communications via that route.

Multicast routing

This, is more tricky. I think the link-local should mean what it means on Thread… that is ff02::/16 just gets processed by immediate neighbours that are in direct RF range.

Realm-local (RFC-7346), ff03::/16 should be used for stuff that’s mesh-wide. Those messages may be repeated by routers provided those routers have at least one subscriber for the given multicast group/port listening.

Multicast Listener Discovery looks to be the tool for that, although it could do with some 6LoWPAN-style optimisation.

I’m thinking the first time a router hears a datagram destined for a particular group, it should send a query out asking “who is listening” to the said group.

Following that first message, it should be up to the downstream node to inform the local routers that it intends to receive messages from a given group. This should be periodic, maybe hourly, so that routers are not re-broadcasting messages for a node that has gone off-air.

Routers that have no listeners for a group, do not rebroadcast that group’s traffic. Similarly, if the hop limit has been exhausted, the messages do not get rebroadcast.

2018/11/21 by Redhatter (VK4MSL) 6LoWHAM Amateur Radio Emergency Communications Projects Public Syndication WICEN 0

6LoWHAM: Digging into LinBPQ

So today I was meant to be helping re-build a deck, but that got postponed to next weekend. Thus, I had an extra free day I wasn’t counting on.

I wound up looking at LinBPQ in detail, to see if I can get it to run. I downloaded the sources, and sure enough, they do compile on my x86-64 laptop, but does it work? Not a chance. Starts parsing the configuration file, then boompa, SEGFAULT.

I run the binary through gdb, and see this:

GNU gdb (Gentoo 8.1 p1) 8.1
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://bugs.gentoo.org/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /home/stuartl/projects/6lowham/linbpq/linbpq...done.
(gdb) r
Starting program: /home/stuartl/projects/6lowham/linbpq/linbpq 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
G8BPQ AX25 Packet Switch System Version 6.0.17.1 November 2018
Copyright � 2001-2018 John Wiseman G8BPQ
Current Directory is /var/lib/linbpq

Configuration file Preprocessor.
Using Configuration file /var/lib/linbpq/bpq32.cfg
Conversion (probably) successful


Program received signal SIGSEGV, Segmentation fault.
0x00005555555f8a7b in Start () at cMain.c:1190
1190                    *(ptr3++) = *(ptr2++);
(gdb) bt full
#0  0x00005555555f8a7b in Start () at cMain.c:1190
        cfg = 0x555555b91c40
        ptr1 = 0x555555ba60c0
        PORT = 0x5555558f6aa0 
        FULLPORT = 0x558f7928
        NEXTPORT = 0x5555558f6de0 <DATAAREA+832>
        EXTPORT = 0x7ffff6eb7953 <_IO_file_overflow+291>
        APPL = 0x5555558f49e0 
        ROUTE = 0x559085e8
        DEST = 0x870b07e2ddd5f300
        CMD = 0x5555558d79e0 
        PortSlot = 2
        ptr2 = 0x555555ba6849 "K4MSL Test station \r"
        ptr3 = 0x55912549 
        ptr4 = 0x5555558d7183 <COMMANDS+1667> "         \003"
        CWPTR = 0x5555558f6b18 <DATAAREA+120>
        i = 0
        n = 119
        int3 = 1435466024
#1  0x000055555563e35c in main (argc=1, argv=0x7fffffffe518) at LinBPQ.c:598
        i = 1
        user = 0x0
        conn = 0x7ffff7ffa298
        STAT = {st_dev = 140737354131120, st_ino = 140737488347784, st_nlink = 140737488347780, st_mode = 4160741648, 
          st_uid = 32767, st_gid = 4143745959, __pad0 = 32767, st_rdev = 140737488348192, st_size = 140737488347784, 
          st_blksize = 1700966438, st_blocks = 26577600, st_atim = {tv_sec = 140737354113688, tv_nsec = 140737488348000}, 
          st_mtim = {tv_sec = 140737354113448, tv_nsec = 140737488347780}, st_ctim = {tv_sec = 140737488347984, 
            tv_nsec = 140737354131160}, __glibc_reserved = {1, 4150715120, 0}}
        PORTVEC = 0x7ffff7ffe6b0

Ookay then… so invalid pointers, what fun! More to the point, have a close look at the underlined addresses… I’m beginning to understand why it was called BPQ32.

The culprit for this wound up being little gems like this:

			//	Round to word boundary (for ARM5 etc)

			int3 = (int)ptr3;
			int3 += 3;
			int3 &= 0xfffffffc;
			ptr3 = (UCHAR *)int3;

There were a few other instances of this, and variations on the theme too, but one way or the other, linbpq basically assumes that all pointers are 32-bits, and so are ints.

Four hours later, I finally had something that started, but there are probably lots of landmines for anyone running the binary to inadvertently stomp on. The code is pointer-arithmetic city! Much of the time, code is casting pointers to unsigned int, or back again. If I submitted code like that at work, they’d have me hauled ’round the back of the building and shot!

I’m left wondering if it’s worth getting to understand, or should I shove it in a VM, write some code based on my understanding of the protocols, do some integration testing with it, then abandon LinBPQ for something I can have confidence in.

The use and re-use of certain variables makes me wonder if the code is actually a port from the DOS-based BPQCode which was likely written in 8086 assembler. This would make a lot of sense as to why I’m seeing the sorts of software coding patterns I’m seeing in that code. The logic seems to have been ported to C just enough to get it to compile and work like the assembly version.

Reasonable enough… but there’s a lot of technical debt there still waiting to be paid back. On paper, there’s a lot of benefit in using LinBPQ as the back-end, and I am thankful that John Wiseman made the decision to release the code under the GPLv3 so that I can at least investigate the possibility of using that code here.

I’ve thrown what I’ve got up on Github for now, and there’s a Gentoo overlay for installing it. Add the overlay and run emerge linbpq, and you should find yourself with an installation of LinBPQ that just needs some OpenRC scripts and some work with an editor on /var/lib/linbpq/bpq32.cfg to get going.

If I get further on the code front, I might look at some init scripts, both OpenRC and systemd ones, then I can produce a few Debian binaries so you can run apt-get install linbpq on your Raspberry Pi and have a packet station going quickly.

2018/11/18 by Redhatter (VK4MSL) 6LoWHAM Amateur Radio Emergency Communications Projects WICEN 0

6LoWHAM: A draft protocol specification

Today, I decided to get cuddly with the relevant RFCs and see if I could adapt them into something that would work for AX.25. The following roughly describes how one might stuff IPv6 datagrams into AX.25.

Much of this is heavily influenced by RFC-4944 and RFC-6282, the latter of which looks to be the heart-and-soul of Thread.

Stateless Automatic Addressing

We have a mechanism by which an AX.25 call+SSID can be losslessly mapped to a 48-bit MAC address. This is built on Radix-50 and can work as a stand-in for the EUI-48. The pseudo EUI-48 procedure mentioned in section 6 of the RFC-4944 standard is not required.

An EUI-64 is generated from an EUI-48 by chopping the EUI-48 in half and inserting the bytes ff:fe in the middle. So the EUI-48:

00:11:22:33:44:55

becomes the following EUI-64:

00:11:22:ff:fe:33:44:55

SLAAC therefore will work the same way it does for Ethernet.

Frame format

1. AX.25 UI Frame header

Size: (17 + (D*7) bytes, where D is the number of digipeaters being used

PID = 1100 0101 (tentative) IPv6
Control = 0000 0011
- Frame type: UI, P/F = 0 (final)
Must contain source and destination AX.25 callsigns, may contain up to 8 digipeater AX.25 callsigns.

For a direct station-to-station contact:

  0   1   2   3   4   5   6   7   8   9  10  11  12  13  14  15
├───┴───┴───┴───┴───┴───┴───┴───┼───┴───┴───┴───┴───┴───┴───┴───┤
│       AX.25 Flag (0x7e)       │ Destination AX.25 Call+SSID   │
├───────────────────────────────┴ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┤
│                                                               │
├ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┤
│                                                               │
├ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┤
│                                                               │
├───────────────────────────────────────────────────────────────┤
│ Source AX.5 Call+SSID                                         │
├ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┤
│                                                               │
├ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┤
│                                                               │
├ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┬───────────────────────────────┤
│                               │          AX.25 PID            │
├───────────────────────────────┴───────────────────────────────┤
╎             AX.25 UI frame payload starts here                ╎
└╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌┘

or for contact via a few digipeaters:

  0   1   2   3   4   5   6   7   8   9  10  11  12  13  14  15
├───┴───┴───┴───┴───┴───┴───┴───┼───┴───┴───┴───┴───┴───┴───┴───┤
│       AX.25 Flag (0x7e)       │ Destination AX.25 Call+SSID   │
├───────────────────────────────┴ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┤
│                                                               │
├ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┤
│                                                               │
├ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┤
│                                                               │
├───────────────────────────────────────────────────────────────┤
│ Source AX.5 Call+SSID                                         │
├ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┤
│                                                               │
├ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┤
│                                                               │
├ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┬───────────────────────────────┤
│                               │    Digipeater 1 Call+SSID     │
├───────────────────────────────┴ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┤
│                                                               │
├ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┤
│                                                               │
├ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┤
│                                                               │
├───────────────────────────────────────────────────────────────┤
│ Digipeater 2 Call+SSID                                        │
├ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┤
│                                                               │
├ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┤
│                                                               │
├ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┬───────────────────────────────┤
│                               │          AX.25 PID            │
├───────────────────────────────┴───────────────────────────────┤
╎             AX.25 UI frame payload starts here                ╎
└╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌┘

2. Mesh Addressing Header

To be used when two stations are not able to directly communicate, or when multicasting.

In this scenario, the AX.25 frame source and destination indicate the addresses of the directly-communicating nodes (e.g. source and digipeater, intermediate digipeaters, or digipeater and destination), and the fields given here will be the addresses of the source and destination AX.25 stations.

e.g. sending from VK4MSL-0 to VK4MDL-9 via
VK4RZB-0 and VK4RZA-0:

First transmission:
- AX.25 Src: VK4MSL-0
- AX.25 Dst: VK4RZB-0
- Mesh Src: VK4MSL-0
- Mesh Dst: VK4MDL-9
- Hops: 7
Intermediate hop:
- AX.25 Src: VK4RZB-0
- AX.25 Dst: VK4RZA-0
- Mesh Src: VK4MSL-0
- Mesh Dst: VK4MDL-9
- Hops: 6
Final delivery:
- AX.25 Src: VK4RZA-0
- AX.25 Dst: VK4MDL-9
- Mesh Src: VK4MSL-0
- Mesh Dst: VK4MDL-9
- Hops: 5

Unlike 802.15.4, we do not have 16-bit short addresses. Since these bits would otherwise always be set to 0, we will use these to provide a 6-bit “hops left” field. We shall use the value 63 (0x3f) to indicate when there are 63 or more hops remaining.

We will use the raw 48-bit addresses here. In keeping with amateur radio conventions, the source and destinations are flipped compared to RFC-4944.

Header format (13 bytes):

  0   1   2   3   4   5   6   7   8   9  10  11  12  13  14  15
├───┴───┼───┴───┴───┴───┴───┴───┼───┴───┴───┴───┴───┴───┴───┴───┤
│ 1   0 │       Hops Left       │      Destination Address      │
├───────┴───────────────────────┴ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┤
│                                                               │
├ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┤
│                                                               │
├ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┬───────────────────────────────┤
│                               │         Source Address        │
├───────────────────────────────┴ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┤
│                                                               │
├ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┤
│                                                               │
├ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┬───────────────────────────────┤
│                               │    Remaining AX.25 Payload    │
├───────────────────────────────┴ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┤
╎                                                               ╎
└╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌┘

4. Fragmentation header

To be used when a IPv6 datagram is greater than L bytes, where L may be defined to be between 64 and 216 bytes.

This part is identical to that of RFC-4944 (section 5.3). I’ll come back to this bit.

5. IPv6 datagram

This can be encoded in a number of ways depending on requirements:

5.1. Raw IPv6 datagram

  0   1   2   3   4   5   6   7   8   9  10  11  12  13  14  15
├───┴───┼───┴───┴───┴───┴───┴───┼───┴───┴───┴───┴───┴───┴───┴───┤
│ 0   1 │       6LP_IPV6        │                               │
├───────┴───────────────────────┴ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┤
╎                  Raw IPv6 datagram with payload.              ╎
└╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌┘

6LP_IPV6 is the value 0x01, as per RFC-4944. The IPv6 datagram is encoded as per RFC-2460, and includes its payload.

The AX.25 frame is finished off with the frame-check sequence.

5.2. Compressed IPv6 datagram

In this format, the datagram fields are compressed, either through making static assumptions, or by deriving them from things such as the AX.25 header, or a previously agreed-to context.

The first field in such payloads is the 6LP_IPHC field:

  0   1   2   3   4   5   6   7   8   9  10  11  12  13  14  15
├───┴───┴───┼───┴───┴───┴───┴───┴───┴───┴───┴───┴───┴───┴───┴───┤
│ 0   1   1 │               6LP_IPV6 with CID=1                 │
├───────────┴───────────────────┬───────────────────────────────┤
│        Context ID Byte        │                               │
├───────────────────────────────┴ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┤
╎             Compressed IPv6 datagram with payload.            ╎
└╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌┘

or without the context ID

  0   1   2   3   4   5   6   7   8   9  10  11  12  13  14  15
├───┴───┴───┼───┴───┴───┴───┴───┴───┴───┴───┴───┴───┴───┴───┴───┤
│ 0   1   1 │               6LP_IPV6 with CID=0                 │
├───────────┴───────────────────────────────────────────────────┤
╎             Compressed IPv6 datagram with payload.            ╎
└╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌┘

The 6LP_IPHC field is a 13-bit field, optionally followed by a context ID extension byte. The bit allocations are as follows:

  0   1   2   3   4   5   6   7   8   9  10  11  12
├───┴───┼───┼───┴───┼───┼───┼───┴───┴───┼───┼───┼───┤
│  TF   │ NH│ HLIM  │CID│SAC│  SAM      │ M │DAC│DAM│
└───────┴───┴───────┴───┴───┴───────────┴───┴───┴───┘

(MSB) 0-1: TF Traffic Class, Flow Label. See 5.2.1 below.
2: NH Next Header encoding
- =0: Given explicitly
- =1: Encoded using 6LP_NHC
3-4: HLIM Hop Limit
- =00: Given explicitly
- =01: is set to 1
- =10: is set to 64
- =11: is set to 255
5: CID Context Identifier Extension
- =0: No CID byte follows
- =1: A CID byte follows
6-8: SAC Source Address Compression / SAM Mode
- =000: No compression applied, whole address given
- =001: Prefix is link-local prefix, remaining bits are given.
- =x10: Not used in 6LoWHAM (we don’t support 16-bit addresses)
- =011: Prefix is link-local, figure the rest out from the source address in the AX.25 header.
- =100: Unspecified address ::
- =101: See the context for the prefix, remaining bits are given.
- =111: Figure out the address from the AX.25 header and context.
(LSB) 9-12: M Multicast, DAC Destination Address Compression
DAM Mode
- =0000: No compression, not multicast, whole address given
- =0001: Prefix is link-local prefix, remaining bits are given. Not multicast.
- =xx10: Not used in 6LoWHAM (we don’t support 16-bit addresses)
- =0011: Prefix is link-local, figure the rest out from the destination address in the AX.25 header. Not multicast.
- =0100: Reserved
- =0101: See the context for the prefix, remaining bits are given. Not multicast.
- =0111: Figure out the address from the AX.25 header and context. Not multicast.
- =1000: No compression, multicast address, whole address given
- =1001: 48-bits of multicast address given, fill in the blanks: ff__::00__:____:____.
- =1010: 32-bits of multicast address given, fill in the blanks: ff__::00__:____.
- =1011: 8-bits of multicast address given, fill in the blanks: ff02::00__.
- =1100: 48-bits RFC-3306/RFC-3956 address, ff__:__LL:PPPP:PPPP:PPPP:PPPP:____:____ where P and L come from the context.
- =1101: Reserved
- =1110: Reserved
- =1111: Reserved

The context ID extension byte has the following format:

  0   1   2   3   4   5   6   7
├───┴───┴───┴───┼───┴───┴───┴───┤
│      SCI      │      DCI      │
└───────────────┴───────────────┘

(MSB) 0-3: Source Context Identifier
(LSB) 4-7: Destination Context Identifier

These two sub-fields indicate which specific context is being used to fill in the blanks.

5.2.1: Traffic Class and Flow Label

These may be partially or completely omitted depending on the TF setting in the previous field.

TF=00:

  0   1   2   3   4   5   6   7   8   9  10  11  12  13  14  15
├───┴───┼───┴───┴───┴───┴───┴───┼───┴───┴───┴───┼───┴───┴───┴───┤
│  ECN  │         DCSP          │ 0   0   0   0 │               │
├───────┴───────────────────────┴───────────────┴ ─ ─ ─ ─ ─ ─ ─ ┤
│                          Flow Label                           │
└───────────────────────────────────────────────────────────────┘

TF=01:

  0   1   2   3   4   5   6   7   8   9  10  11  12  13  14  15
├───┴───┼───┴───┼───┴───┴───┴───┴───┴───┴───┴───┴───┴───┴───┴───┤
│  ECN  │ 0   0 │                                               │
├───────┴───────┴ ─ ─ ─ ─ ─ ─ ─ ┬───────────────────────────────┤
│           Flow Label          │                               │
├───────────────────────────────┴ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┤
╎                   Remainder of IPv6 datagram.                 ╎
└╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌┘

TF=10:

  0   1   2   3   4   5   6   7   8   9  10  11  12  13  14  15
├───┴───┼───┴───┴───┴───┴───┴───┼───┴───┴───┴───┴───┴───┴───┴───┤
│  ECN  │         DCSP          │                               │
├───────┴───────────────────────┴ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┤
╎                   Remainder of IPv6 datagram.                 ╎
└╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌┘

TF=11: Flow label, ECN and DCSP are set to 0.

5.2.2: Next Header

If 6LP_NHC is not explicitly enabled, the next header byte will appear next.

5.2.3: Hop Limit.

Again, if not explicitly defined in the 6LP_IPHC header, the hop-limit byte will appear next.

5.2.4: Source address

The format here is determined by the values of SAC/SAM:

000: Entire IPv6 address, 16 bytes given here.
x01: Last 8-bytes of the address given here
For all other values, the source address is omitted.

5.2.5: Destination address

The format here is determined by the values of M/DAC/DAM:

x000: Entire IPv6 address, 16 bytes given here.
0x01: Last 8-bytes of the address given here.
1001: 6-bytes of address given here, fill-in-the-blanks.
1010: 4-bytes of address given here, fill-in-the-blanks.
1011: Last byte of address given here, fill-in-the-blank.
1100: 6-bytes of address given here, fill-in-the-blanks.
For all other values, the destination address is omitted.

6. 6LoWPAN Next Header

This is used to encode selected IPv6 extensions or L4 protocol headers.

6.1. IPv6 extension headers

A select number of IPv6 extensions may be encoded by replacing the usual “Next Header” byte with the following:

  0   1   2   3   4   5   6   7
├───┴───┴───┴───┼───┴───┴───┼───┤
│ 1   1   1   0 │    EID    │ N │
└───────────────┴───────────┴───┘

where EID (bits 4-6) is one of:

=0 IPv6 Hop-By-Hop options
=1 IPv6 Routing
=2 IPv6 Fragment
=3 IPv6 Destination Options
=4 IPv6 Mobility
=7 IPv6 Header

and N (bit 7) indicates whether the header’s payload is followed by another 6LowPAN Next Header, or a regular IPv6 Next Header (with its “Next Header” byte). For EID=7, N MUST be 0.

Length fields within the header payload should be counted in bytes instead of 8-byte blocks.

7. Datagram payload

7.1. Non-UDP payloads

For payloads other than UDP packets, these should be inserted into the AX.25 payload as-is following the extensions.

UDP packets with uncompressed headers should also be inserted
in this manner.

7.2. UDP payloads with header compression

For these payloads, the following UDP header should be used:

  0   1   2   3   4   5   6   7   8   9  10  11  12  13  14  15
├───┴───┴───┴───┴───┼───┼───┴───┼───┴───┴───┴───┴───┴───┴───┴───┤
│ 1   1   1   1   0 │ C │   P   │           Source Port         │
├───────────────────┴───┴───────┴ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┤
╎                                                               ╎
├───────────────────────────────────────────────────────────────┤
╎                         Destination Port                      ╎
├ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┤
╎                                                               ╎
├───────────────────────────────────────────────────────────────┤
│                     Checksum (unless C=1)                     │
└───────────────────────────────────────────────────────────────┘

(MSB): bits 0-4: Compressed UDP header marker. Literal 11110₂
Bit 5: C Compressed UDP checksum
- 0= UDP checksum is given (recommended value)
- 1= UDP checksum is omitted

Bits 6-7: P Ports

00=Both source and destination addresses are
given in full

  0   1   2   3   4   5   6   7   8   9  10  11  12  13  14  15
├───┴───┴───┴───┴───┴───┴───┴───┴───┴───┴───┴───┴───┴───┴───┴───┤
│                         Source Port                           │
├───────────────────────────────────────────────────────────────┤
│                      Destination Port                         │
└───────────────────────────────────────────────────────────────┘

01=Source port is given in full, Least significant 8-bits of destination given, destination port is 0xff00-0xffff (65280-65535)

  0   1   2   3   4   5   6   7   8   9  10  11  12  13  14  15
├───┴───┴───┴───┴───┴───┴───┴───┴───┴───┴───┴───┴───┴───┴───┴───┤
│                         Source Port                           │
├───────────────────────────────┬───────────────────────────────┤
│       Destination Port        │                               │
├───────────────────────────────┴ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┤
╎                    Remainder of UDP packet                    ╎
└╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌┘

10=Destination port is given in full, Least significant 8-bits of source given, source port is 0xff00-0xffff (65280-65535)

  0   1   2   3   4   5   6   7   8   9  10  11  12  13  14  15
├───┴───┴───┴───┴───┴───┴───┴───┼───┴───┴───┴───┴───┴───┴───┴───┤
│          Source Port          │        Destination Port       │
├───────────────────────────────┼───────────────────────────────┤
│    Destination Port (cont.)   │                               │
├───────────────────────────────┴ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┤
╎                    Remainder of UDP packet                    ╎
└╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌┘

11=Only least significant 4-bits of source and destination ports are given. Port LSB range is 0xf0b0-0xf0bf (61616-61631)

  0   1   2   3   4   5   6   7   8   9  10  11  12  13  14  15
├───┴───┴───┴───┴───┴───┴───┴───┼───┴───┴───┴───┴───┴───┴───┴───┤
│         Source Port           │       Destination Port        │
└───────────────────────────────┴───────────────────────────────┘

The C bit should only be set if the upper-level application asks for it. Whilst 802.15.4 does its own CRC as does AX.25, the field is mandatory in UDP and the recommendation is to only drop it if the application says it’s okay.

2018/11/17 by Redhatter (VK4MSL) 6LoWHAM Amateur Radio Emergency Communications Projects WICEN 0