In the process of configuring and testing a fill-in digipeater with the local iGate, I discovered a bug with the SSID Alias feature in SMSGTE that has been there from it’s introduction.
After further investigation, this bug is not with SMSGTE but rather with some iGate implementations. When messages are gated from IP to RF, the iGate is supposed to send them as 3rd party messages. The gateway operation was reverted to it’s original function. It will be up to iGate operators and software developers to correct that behavior.
It turns out that alphanumeric SSID will work fine when messages are sent from RF to SMSGTE, however, responses from the gateway using the same alphanumeric SSID will not get gated properly to RF. This is due to the SSID limitation in the AX.25 packet.
Behind the Scenes
At the heart of the issue, is the format of the AX.25 frame. It is beyond the scope of this post to explain all of the fields in the frame, but for our purposes, we will focus on the Source Address.
As you can see in the image above, the source address is comprised of 7 bytes. 6 of those bytes represent the callsign. The 7th byte is used to represent the SSID, but only the first 4 bits are used, limiting the SSID value to a number between 0 and 15. 0 is the same as having no SSID.
When you’re sending a message, this is not a problem, because in APRS the Destination Address is not used to represent the destination of the message (that is encoded into the information field). For more on this, refer to the APRS Protocol Reference. Since the message destination is specified in the information field by 9 bytes, any two alphanumeric characters can be used.
When SMSGTE responds and appends an alphanumeric SSID to it’s callsign, a different situation emerges. If the message is destined for a station that only exists in APRS-IS (on the Internet), then no problem, because AX.25 frames are represented differently for transport over the Internet. When that message reaches an iGate to be relayed to RF, however, we have a problem. The alphanumeric SSID cannot be represented in 4 bits, therefore it is either omitted, or in most cases, the packet is never gated to RF because of the invalid SSID.
The issue described above only occurs when the iGate does not properly encapsulate the message as a 3rd party packet per the APRS specifications.
There were a few options considered, but in the end I went with the third from the list below as the error doesn’t lie with the way SMSGTE uses SSIDs, but the manor in which some iGates are gating message packets.
- Restrict SSID aliases to values from 1 to 15 (0 is reserved to represent no SSID)
- Continue to support alphanumeric SSID, but embed alias into message body in replies
- Continue to support alphanumeric SSID and leave it to the iGates to properly follow the specification.