Re: Is AX.25 UI frame destination address case-sensitive?
Hello Stuart, 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. So you're looking to use unconnected UI frames to communicate to multiple people at the same time? Are you looking to have those remote stations listen and *only* selectively show the traffic either to their own callsign+ssid or to a specific "multicast" group? In my area, we have a weekly UI net where different HAMs essentially send beacons along a 7-hop digi path to chat. Everyone monitors the channel in a promiscuous method to hear everyone's traffic. It's not an ideal system as we see all the other traffic on the channel as well but it does work well enough. If you wanted to filter on this traffic to only your net, you could have everyone send their traffic to a specific destination across your digipeaters and filter all promiscuous traffic to a specific destination address, say "vk4cht-0". If you're looking for a guaranteed delivery transport, you could do something at the application layer to put a sequence number in the UI payload to identify missing packets and re-request a re-transmit. This is something that D-RATS had developed years ago. That could become a challenge in a lossy multi-point network but it it works fine when someone is acting as a net control. In the TCP/IP world, Pragmatic General Multicast (PGM) attempts to solve this problem: https://en.wikipedia.org/wiki/Reliable_multicast --David KI6ZHD
Re: Is AX.25 UI frame destination address case-sensitive?
On 21/1/19 3:56 am, David Ranch wrote: Hello Stuart, 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. So you're looking to use unconnected UI frames to communicate to multiple people at the same time? Are you looking to have those remote stations listen and *only* selectively show the traffic either to their own callsign+ssid or to a specific "multicast" group? Essentially, yes, the stations ideally will be just listening out for traffic to a couple of SSIDs: - their own SSID (for unicast traffic) - the "group" SSID (for multicast traffic) Long term, the actual chatting will be done on a higher layer with a protocol built on AX.25 being used as the transport mechanism. It may also include encoded forms (perhaps CBOR-encoding to make things compact) for sending welfare-type information. e.g. the "base station" for an emergency comms net might transmit a form to be filled out by operators at the "checkpoints"; this would be sent multicast (with each station then unicasting an ACK when they receive it) … the operators could then fill the form in and their replies would be sent back unicast to the base. In my area, we have a weekly UI net where different HAMs essentially send beacons along a 7-hop digi path to chat. Everyone monitors the channel in a promiscuous method to hear everyone's traffic. It's not an ideal system as we see all the other traffic on the channel as well but it does work well enough. If you wanted to filter on this traffic to only your net, you could have everyone send their traffic to a specific destination across your digipeaters and filter all promiscuous traffic to a specific destination address, say "vk4cht-0". It's promising to hear the concept can work. I guess the aim here is to try and build on that concept. If you're looking for a guaranteed delivery transport, you could do something at the application layer to put a sequence number in the UI payload to identify missing packets and re-request a re-transmit. This is something that D-RATS had developed years ago. That could become a challenge in a lossy multi-point network but it it works fine when someone is acting as a net control. Sequence numbering could be done at a higher layer for sure. I figure it's up to the higher-level application to guarantee delivery. In the TCP/IP world, Pragmatic General Multicast (PGM) attempts to solve this problem: https://en.wikipedia.org/wiki/Reliable_multicast I'll definitely have a look at that. This could be interesting. -- Stuart Longland (aka Redhatter, VK4MSL) I haven't lost my mind... ...it's backed up on a tape somewhere.
Re: Is AX.25 UI frame destination address case-sensitive?
On 21/1/19 2:17 am, Martin Cooper wrote: A silly question, is the destination address in a UI frame case-sensitive? From the AX.25 2.2 spec, section 2.2.13, Address-Field Encoding: "Except for the Secondary Station Identifier (SSID), the address field should be made up of /upper-case alpha/ and numeric ASCII characters only." (Emphasis mine.) Yes, I had read the spec. My question was one of, does the software enforce that. Thomas Karpiniec's email pretty much said, "yes", in the Linux AX.25 stack's case, it feeds it all through `toupper`, which basically will clear that extra bit (0x61 becomes 0x41). -- Stuart Longland (aka Redhatter, VK4MSL) I haven't lost my mind... ...it's backed up on a tape somewhere.
Re: Is AX.25 UI frame destination address case-sensitive?
On 21/1/19 3:15 am, Thomas Osterried wrote: => Even if you try to use lowercase characters (what will break supposely every existing packet-radio-software), due to the left shift, you won't be able to encode letters p-z. That I find interesting… it's a 7-bit ASCII character in an 8-bit field. 'p' is 0x70 (0b0111) according to `man ascii`, which left shifted with be 0xe0 (0b1110). 'z' is 0x7a (0b0010), which left shifted would be 0xf4 (0b0100). Why wouldn't it be possible to encode those letters? -- Stuart Longland (aka Redhatter, VK4MSL) I haven't lost my mind... ...it's backed up on a tape somewhere.
Re: Is AX.25 UI frame destination address case-sensitive?
On Sun, Jan 20, 2019 at 08:22:32AM -0800, Martin Cooper wrote: > Hi Stuart, > > > A silly question, is the destination address in a UI frame case-sensitive? > > From the AX.25 2.2 spec, section 2.2.13, Address-Field Encoding: > > "Except for the Secondary Station Identifier (SSID), the address field > should be made up of upper-case alpha and numeric ASCII characters > only." And: The HDLC address field is extended beyond one octet by assigning the least-significant bit of each octet to be an "extension bit". The extension bit of each octet is set to zero, to indicate the next octet contains more address information, or one, to indicate this is the last octet of the HDLC address field. To make room for this extension bit, the amateur Radio call sign information is shifted one bit left. https://tapr.org/pub_ax25.html => Even if you try to use lowercase characters (what will break supposely every existing packet-radio-software), due to the left shift, you won't be able to encode letters p-z. > > 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". > > I'll note that the AX.25 'listen' source code uses these two bits in > decoding. One is used to identify "EAX25" and the other "DAMA". It > might be worth looking into what those are all about before reusing > either or both of these bits. Btw, Destination QST-0 (and in many implementations NODES-0 (for netrom protocol) is defined as multicast address. vy 73, - Thomas dl9sau
Re: Is AX.25 UI frame destination address case-sensitive?
Hi Stuart, > A silly question, is the destination address in a UI frame case-sensitive? >From the AX.25 2.2 spec, section 2.2.13, Address-Field Encoding: "Except for the Secondary Station Identifier (SSID), the address field should be made up of upper-case alpha and numeric ASCII characters only." > 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". I'll note that the AX.25 'listen' source code uses these two bits in decoding. One is used to identify "EAX25" and the other "DAMA". It might be worth looking into what those are all about before reusing either or both of these bits. Hope that helps. Martin. KD6YAM > -- > Stuart Longland (aka Redhatter, VK4MSL) > > I haven't lost my mind... > ...it's backed up on a tape somewhere.
Is AX.25 UI frame destination address case-sensitive?
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
