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.
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. I am currently working on a solution.
This is a bug that has likely caused hours of frustration and troubleshooting among users, and I apologize for not catching it sooner. A fix has been uploaded to the server and the problem should be resolved.
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.
There were a few options considered, but in the end I went with the third from the list below.
- 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 aliases from 1 to 15 bidirectionally but embed alphanumeric aliases in the body of the message.