Re: Is AX.25 UI frame destination address case-sensitive?
Hi Stuart, On Sun, 20 Jan 2019, at 2:32 PM, Stuart Longland (VK4MSL) wrote: >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. libax25's ax25_aton_entry (and by extension the widely used ax25_aton) uses toupper(), which might frustrate your attempts depending how exactly you're constructing and sending the frames. I think that working contrary to the spec would create doubt observing traffic with existing tooling as to whether a callsign is "really" capitalised or not. > 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. Perhaps more so than the other ideas, this type of usage is blessed in the spec for "Destination Subfield Encoding": > 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. I can't speak to how well this is exposed by the various AX.25 stacks but on a theoretical level I agree with this option being at the top of your list. Sounds like a cool project. Cheers, Tom VK7NTK
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
OT: Global AX.25 status?
Hi all, As a newly-appointed Secretary of YU7/YT7 ham radio union, where I planned to revive AX.25 infrastructure, I faced to a strong opposition and (mis)belief claiming that the 'old-fashioned' packet mode is "dead". And yes, apart sporadic APRS activity, packet (in its 'connected' mode) is dead in YU7/YT7 area & its surroundings. In fact, except my own local city node & bbs, there are no nearby resources. However, WP database of my FBB returns many active callsigns - particularly in countries like USA, UK, Germany, France, etc. So I wonder about real status of nodes, bbs's, and related resources in your areas? Drop me your opinions off-line. Tnx! Misko YT7MPB
Re: [PATCH] NET:AX25:ROSE NULL ax25_cb kernel panic
On Sat, Jan 19, 2019 at 11:58 AM f6bvp wrote:
>
>
> [PATCH] [ROSE] NULL ax25_cb kernel panic
>
> When an internally generated frame is handled by rose_xmit(),
> rose_route_frame() is called:
>
> if (!rose_route_frame(skb, NULL)) {
> dev_kfree_skb(skb);
> stats->tx_errors++;
> return NETDEV_TX_OK;
> }
>
> We have the same code sequence in Net/Rom where an internally generated
> frame is handled by nr_xmit() calling nr_route_frame(skb, NULL).
> However, in this function NULL argument is tested while it is not in
> rose_route_frame().
> Then kernel panic occurs later on when calling ax25cmp() with a NULL
> ax25_cb argument as reported many times and recently with syzbot.
>
> We need to test if ax25 is NULL before using it.
>
> Here is the patch:
>
> diff --git a/net/rose/rose_route.c b/net/rose/rose_route.c
> index 77e9f85a2c92..7f075255a372 100644
> --- a/net/rose/rose_route.c
> +++ b/net/rose/rose_route.c
> @@ -850,6 +850,7 @@ void rose_link_device_down(struct net_device *dev)
>
> /*
> * Route a frame to an appropriate AX.25 connection.
> + * a NULL ax25_cb indicates an internally generated frame.
> */
> int rose_route_frame(struct sk_buff *skb, ax25_cb *ax25)
> {
> @@ -867,6 +868,10 @@ int rose_route_frame(struct sk_buff *skb, ax25_cb
> *ax25)
>
> if (skb->len < ROSE_MIN_LEN)
> return res;
> +
> + if (!ax25)
> + return rose_loopback_queue(skb, NULL);
> +
> frametype = skb->data[2];
> lci = ((skb->data[0] << 8) & 0xF00) + ((skb->data[1] << 0) & 0x0FF);
> if (frametype == ROSE_CALL_REQUEST &&
>
> Signed-off-by: Bernard Pidoux, f6bvp
Please also add:
Reported-by: syzbot+1a2c456a1ea08fa5b...@syzkaller.appspotmail.com
It's this report we are fixing, right?
https://syzkaller.appspot.com/bug?id=fd0b0b00fc26abb4b35663a0e2f1c91d8e6e5725
[PATCH] NET:AX25:ROSE NULL ax25_cb kernel panic
[PATCH] [ROSE] NULL ax25_cb kernel panic
When an internally generated frame is handled by rose_xmit(),
rose_route_frame() is called:
if (!rose_route_frame(skb, NULL)) {
dev_kfree_skb(skb);
stats->tx_errors++;
return NETDEV_TX_OK;
}
We have the same code sequence in Net/Rom where an internally generated
frame is handled by nr_xmit() calling nr_route_frame(skb, NULL).
However, in this function NULL argument is tested while it is not in
rose_route_frame().
Then kernel panic occurs later on when calling ax25cmp() with a NULL
ax25_cb argument as reported many times and recently with syzbot.
We need to test if ax25 is NULL before using it.
Here is the patch:
diff --git a/net/rose/rose_route.c b/net/rose/rose_route.c
index 77e9f85a2c92..7f075255a372 100644
--- a/net/rose/rose_route.c
+++ b/net/rose/rose_route.c
@@ -850,6 +850,7 @@ void rose_link_device_down(struct net_device *dev)
/*
* Route a frame to an appropriate AX.25 connection.
+ * a NULL ax25_cb indicates an internally generated frame.
*/
int rose_route_frame(struct sk_buff *skb, ax25_cb *ax25)
{
@@ -867,6 +868,10 @@ int rose_route_frame(struct sk_buff *skb, ax25_cb
*ax25)
if (skb->len < ROSE_MIN_LEN)
return res;
+
+ if (!ax25)
+ return rose_loopback_queue(skb, NULL);
+
frametype = skb->data[2];
lci = ((skb->data[0] << 8) & 0xF00) + ((skb->data[1] << 0) & 0x0FF);
if (frametype == ROSE_CALL_REQUEST &&
Signed-off-by: Bernard Pidoux, f6bvp
