Hi all, A silly question, is the destination address in a UI frame case-sensitive?
Reason I ask is I'm looking at a way I can differentiate between a SSID used to identify a *station*, versus a SSID that is being used by multiple stations as a "multicast" address. The thinking here is if I want to send a message to a station, VK4BWI-0, if it's just to that station, I'd address it to "VK4BWI-0" as normal. However, supposing a few of us in Brisbane WICEN had a little chat group on our digipeater network, and we wished to have a common UI frame destination address that we all listen for to receive real-time messages. At the moment I'm not focussing on the content of these UI frames. In the future it might be some compressed UDP/IP network traffic, but right now let's say they're just plain-text. I've got from what I can see, there are a few places where I can mark an AX.25 frame as being destined to a "group" of stations instead of a single station: 1. Using the reserved bits. There's two bits in the last octet of each SSID, which are normally set to '1'. I could use one of those to indicate this is a "unicast" address; setting that to 0 would mean the message is being "multicasted" or "broadcasted". Interfaces like AGWPE's TCP socket protocol abstract these bits. No idea if those would be preserved when passed through other AX.25 stacks. 2. The command/response bits. These also reside in the SSID fields and from what I've seen, have no special meaning in UI frames. These bits are also abstracted in some interfaces. 3. Encode the destination call-sign as lower-case. The AX.25 2.0 spec says the call-sign should consist of upper-case letters and digits. A group name, which may not necessarily be a call-sign, could be encoded as lower-case. I have no idea how existing AX.25 stacks (Linux kernel, G8BPQ, AGWPE, TheNet, TNCs, etc) would react to such frames, whether they'd discard them, strip the lower-case bits in the SSIDs, or pass the SSIDs through as-is. 4. Use a different PID. One for "unicast" and the other for "multicast". 5. Rely on the payload content. Obviously the one that's most likely to work is (5), so maybe a byte at the start indicates if the message is being unicast or multicast; and all stations treat the message as multicast until they see that first byte. I'm still considering the other options… the most elegant to my mind is just using lowercase for a group name, as the destination SSID is the very first field you come across in an AX.25 frame after the initial flag byte. Long term some replacement for AX.25 may be the ultimate answer as it would solve this problem and also allow for 7-character call-signs, but right now it's what we've got. Hence my aim to try to work within its constraints. Regards, -- Stuart Longland (aka Redhatter, VK4MSL) I haven't lost my mind... ...it's backed up on a tape somewhere.
signature.asc
Description: OpenPGP digital signature
