Status of AX.25 in 2.5 / 2.6

Status of AX.25 in 2.5 / 2.6

[Ralf Baechle]

Forgive if I'm missing any developments on this list; I've been (again ...)
unsubscribed by one of Mati's scripts ...

No substancial changes have been done to the AX.25 kernel stack in a extended
period of time.  As the result it is still doing crude stuff like globally
enabling and disabling interrupts, has no understanding of shared skb, isn't
fully multithreaded and probably plenty more problems I haven't spotted yet.
Now that we're about to remove global cli() / sti() from the kernel this
means the AX.25 stack will soon break entirely.

Is there any ongoing development I'm not aware of?  Just in case I've
started doing some cleanup last night ...

73 de DO1GRB op Ralf

--
Loc. JN47BS / CQ 14 / ITU 28 / DOK A21

Re: Status of AX.25 in 2.5 / 2.6

[Tomi Manninen OH2BNS]

On Fri, 26 Jul 2002, Ralf Baechle wrote:

> No substancial changes have been done to the AX.25 kernel stack in a extended
> period of time.  As the result it is still doing crude stuff like globally
> enabling and disabling interrupts, has no understanding of shared skb, isn't
> fully multithreaded and probably plenty more problems I haven't spotted yet.
> Now that we're about to remove global cli() / sti() from the kernel this
> means the AX.25 stack will soon break entirely.
> 
> Is there any ongoing development I'm not aware of?  Just in case I've
> started doing some cleanup last night ...

As far as I know there is no development going on. Or if there is, people
have hidden it pretty well. So I think everyone will warmly welcome your
efforts!

-- 
Tomi Manninen           Internet:  oh2bns@sral.fi
OH2BNS                  AX.25:     oh2bns@oh2rbi.fin.eu
KP20ME04                Amprnet:   oh2bns@oh2rbi.ampr.org

Re: Status of AX.25 in 2.5 / 2.6

[Ralf Baechle DO1GRB]

On Fri, Jul 26, 2002 at 03:16:03PM +0300, Tomi Manninen OH2BNS wrote:

> > No substancial changes have been done to the AX.25 kernel stack in a
> > extended period of time.  As the result it is still doing crude stuff
> > like globally enabling and disabling interrupts, has no understanding
> > of shared skb, isn't fully multithreaded and probably plenty more
> > problems I haven't spotted yet. Now that we're about to remove global
> > cli() / sti() from the kernel this means the AX.25 stack will soon break
> > entirely.
> > 
> > Is there any ongoing development I'm not aware of?  Just in case I've
> > started doing some cleanup last night ...
> 
> As far as I know there is no development going on. Or if there is, people
> have hidden it pretty well. So I think everyone will warmly welcome your
> efforts!

Cute.  I started hacking on it because I'm interested in packet but I'm
not even QRV in packet right now.  While I'm killing another bit of forest
by printing the AX.25 spec, anybody got me a pointer to some sort of DAMA
spec?

73 de DO1GRB op Ralf

--
Loc. JN47BS / CQ 14 / ITU 28 / DOK A21

mkiss problem in kernel 2.5

[Arnau Sánchez]

Hello,

    I wanted to test ax25 of the latest kernel version so I downloaded it
from bitkeeper. I compiled it without problems but after that I got an error
when trying to do a "modprobe mkiss" (I need it because I use soundmodem).
It has unresolved functions (cli, save_flags and restore_flags), I imagine
that in kernel 2.5 this system-calls are being removed...

    Is anybody working (or will be working) on mkiss and the rest of
hamradio drivers to adopt this changes? is it difficult to do?

thanks,

arnau

Re: Status of AX.25 in 2.5 / 2.6

[Steven Whitehouse]

Hi,

> 
> Forgive if I'm missing any developments on this list; I've been (again ...)
> unsubscribed by one of Mati's scripts ...
> 
> No substancial changes have been done to the AX.25 kernel stack in a extended
> period of time.  As the result it is still doing crude stuff like globally
> enabling and disabling interrupts, has no understanding of shared skb, isn't
> fully multithreaded and probably plenty more problems I haven't spotted yet.
> Now that we're about to remove global cli() / sti() from the kernel this
> means the AX.25 stack will soon break entirely.
> 
> Is there any ongoing development I'm not aware of?  Just in case I've
> started doing some cleanup last night ...
> 
> 73 de DO1GRB op Ralf
>
I started a little. Untested yet, but for what its worth:

http://www.chygwyn.com/~steve/kpatch/ax25/ax25-uid-2.5.25.diff

Please feel free to use as much/little as you like of this patch. It would
be nice to do enough tidying to these protocols that we can get rid of
things like deliver_to_old_ones() from the core code. I can't spare a
lot of time, but I'll help where I can.

I spoke to Dave Jones at the recent UKUUG conference and he mentioned that
it appeared that nobody was doing any work on AX.25 and associated
protocols which was why I started something. It would be a good idea to
drop him a line to let him know that you are working on it,

Steve.
G7RRM

Re: Status of AX.25 in 2.5 / 2.6

[Ralf Baechle DO1GRB]

On Fri, Jul 26, 2002 at 01:50:45PM +0100, Steven Whitehouse wrote:

> I started a little. Untested yet, but for what its worth:
> 
> http://www.chygwyn.com/~steve/kpatch/ax25/ax25-uid-2.5.25.diff
> 
> Please feel free to use as much/little as you like of this patch. It would
> be nice to do enough tidying to these protocols that we can get rid of
> things like deliver_to_old_ones() from the core code. I can't spare a
> lot of time, but I'll help where I can.
> 
> I spoke to Dave Jones at the recent UKUUG conference and he mentioned that
> it appeared that nobody was doing any work on AX.25 and associated
> protocols which was why I started something. It would be a good idea to
> drop him a line to let him know that you are working on it,

I took a look at your code; it's orthogonal to what I did so far.  I
consider the removal of global cli/sti & co the most immediate problem,
so I started redoing the whole locking in net/ax25/.  Some of that stuff
was unbelievably bad wrt. to SMP machines.

73 de DO1GRB op Ralf

--
Loc. JN47BS / CQ 14 / ITU 28 / DOK A21

Re: Status of AX.25 in 2.5 / 2.6

[Craig Small]

On Fri, Jul 26, 2002 at 01:42:16PM +0200, Ralf Baechle wrote:
> No substancial changes have been done to the AX.25 kernel stack in a extended
> period of time.  As the result it is still doing crude stuff like globally
> enabling and disabling interrupts, has no understanding of shared skb, isn't
> fully multithreaded and probably plenty more problems I haven't spotted yet.
> Now that we're about to remove global cli() / sti() from the kernel this
> means the AX.25 stack will soon break entirely.
> 
> Is there any ongoing development I'm not aware of?  Just in case I've
> started doing some cleanup last night ...

No, if there is something going on I don't know about it, which is not
that surprising anyway.  If you're doing only internal stuff than go
right ahead.  If you want to fiddle with anything that changes the API
let me know so that the libraries and programs can handle it.

  - Craig
-- 
Craig Small VK2XLZ  GnuPG:1C1B D893 1418 2AF4 45EE  95CB C76C E5AC 12CA DFA5
Eye-Net Consulting http://www.eye-net.com.au/        <csmall@eye-net.com.au>
MIEEE <csmall@ieee.org>                 Debian developer <csmall@debian.org>

Re: Status of AX.25 in 2.5 / 2.6

[Ralf Baechle DO1GRB]

On Sat, Jul 27, 2002 at 09:24:26AM +1000, Craig Small wrote:

> No, if there is something going on I don't know about it, which is not
> that surprising anyway.  If you're doing only internal stuff than go
> right ahead.  If you want to fiddle with anything that changes the API
> let me know so that the libraries and programs can handle it.

At the moment I just intend to dust off the code.  Anything else we can
talk about later.  Unless there is already a list of bugs or wishes?

73 de DO1GRB op Ralf

--
Loc. JN47BS / CQ 14 / ITU 28 / DOK A21

RE: Status of AX.25 in 2.5 / 2.6

[Robert Jenkins]

Hi Ralf & all,


There is one item on my Wishlist which I've mentioned a couple of times
in the group;

This is the addition of a 'visible' (accessible) total retries counter
for each port.

The count of total frames transmitted is already stored and is visible
via ifconfig.
Having the total retries for the port in addition to this would allow
monitoring of links, and it gives an early warning of antenna or radio
degredation.

This is the one feature that Dos BPQ had that I miss with the Linux
software.


From looking through the kernel AX25 code, the retry count is only
incremented in three places. If a 'total errors' counter could be
incremented at the same time, this would do the job.

The ifconfig display includes a TX errors count, which seems to be
unused on my particular setup, but so far I've not had the time to work
through the sources & find where it's stored.

Also, while it's not used with my configuration (using only KISS tncs),
I don't know if it's used with any other interfaces (SCC cards etc) so
it may need to be configurable in the appropriate header file.


Regards,

Robert Jenkins, G8TBF / G0WTK.

mailto:g8tbf@nndg.org

Re: Status of AX.25 in 2.5 / 2.6

[Ken Koster]

On Saturday 27 July 2002 04:10, Robert Jenkins wrote:
> Hi Ralf & all,
>
>
> There is one item on my Wishlist which I've mentioned a couple of times
> in the group;

And a couple on mine that I've done on my local systems.

The count of total bytes sent and received.  The net_device_stats structure
has a place for rx and tx_bytes, but mkiss and other drivers don't make use
of them.  In the case of mkiss the mod is simple and I'm sure it's not that
hard for other device drivers.

Also, mkiss, and probably other drivers are not initializing the interface
flags correctly.  They need to indicate that these drivers can do broadcasts.
The change is a one liner.

It sounds like we have several people who've been digging into the kernel 
code.  Do we perhaps need to make a real project of this, with a common 
place for the code and CVS to keep track of the changes?  We could do this 
as a sourceforge project, or if everyone would rather keep this small, at 
least setup a CVS account somewhere that could keep track of changes.  I 
could probably be talked into hosting such if needed.

Ken,  N7IPB 

Re: Status of AX.25 in 2.5 / 2.6

[Ralf Baechle DO1GRB]

On Sat, Jul 27, 2002 at 06:38:43AM -0700, Ken Koster wrote:

> It sounds like we have several people who've been digging into the kernel 
> code.  Do we perhaps need to make a real project of this, with a common 
> place for the code and CVS to keep track of the changes?  We could do this 
> as a sourceforge project, or if everyone would rather keep this small, at 
> least setup a CVS account somewhere that could keep track of changes.  I 
> could probably be talked into hosting such if needed.

I have server space but before I'm going to show off what we have I think
we first need to have something.  Unfortunatley the number of race
conditions in that code are just frightening and the longer I'm hacking
the code the more I discover.  Basically you can't run AX.25 on a system
with untrusted users ...

73 de DO1GRB op Ralf

--
Loc. JN47BS / CQ 14 / ITU 28 / DOK A21

Re: Status of AX.25 in 2.5 / 2.6

[Riley Williams]

Hi Ralf, Ken.

>> It sounds like we have several people who've been digging into the
>> kernel code. Do we perhaps need to make a real project of this, with
>> a common place for the code and CVS to keep track of the changes? We
>> could do this as a sourceforge project, or if everyone would rather
>> keep this small, at least setup a CVS account somewhere that could
>> keep track of changes. I could probably be talked into hosting such
>> if needed.

> I have server space but before I'm going to show off what we have I
> think we first need to have something. Unfortunatley the number of
> race conditions in that code are just frightening and the longer I'm
> hacking the code the more I discover. Basically you can't run AX.25
> on a system with untrusted users ...

It sounds like the first thing we need is a list of the problems that
need dealing with. Perhaps you could summarise the source files you've
looked at and the number of problems you've found in each one?

=======================================================================

I've just searched SourceForge for AX25 and have found six existing
projects...

 1. ax25 Libraries and Utilities - this one does not have any
    form of description but appears to be the source of the
    ax25-apps, ax25-tools and libax25 packages.

 2. LinKT - A packet radio terminal for the Linux ax25 stack
    and the KDE.

 3. AX25 Mail Utilities - A set of utilities for packet radio
    mail exchange with the BBS.

 4. ax25 config utility - A utility simplifying the config
    of the Linux ax25 subsystem.

 5. linbbs - A little packet hamradio BBS for Linux ax25.

 6. Linux/SCS PTC-II gateway - A daemon that gateways ROSE
    network connections to the PTC-II WA8DED extended host
    mode channels to allow PACTOR and AX.25 packet radio
    users to gateway into a rose network or onto locally
    hosted applications via rose, and for rose users to
    gateway out.

...none of which appear to be connected to this. As a result, I would
presume that there's nowhere in SourceForge that we could join rather
than creating a new project.

Best wishes from Riley G7GOD / KB8PPG.

Re: Status of AX.25 in 2.5 / 2.6

[Jason Flynn G7OCD]

Ralf Baechle DO1GRB wrote:
>  Unfortunatley the number of race conditions in that code are
 > just frightening and the longer I'm hacking the code the more
 > I discover.

Anyone examined NEWAX25 stuff to see if it is any better?
I'm sure I heard someone starting to port it to 2.4.
I'm happy to help on a clean-up exercise (based on the
either old or new ax25 code) but it's a big job and would
need a coordinated team effort.
It's been done with the user-mode stuff, and I think it
made a big difference to that. Maybe the same rigor applied
to the kernel stuff could weed out some of the funnies that
rear their heads now and then.
I still get unexplained things happening and I have to
brush them under the carpet when trying to woo someone
into runnig Linux as their AX25 system and I'd like to
be in a more confident position than that...

	J

Re: Status of AX.25 in 2.5 / 2.6

[Tomi Manninen]

On Sat, 27 Jul 2002, Ralf Baechle DO1GRB wrote:

> At the moment I just intend to dust off the code.  Anything else we can
> talk about later.  Unless there is already a list of bugs or wishes?

Not a list but I'd sure be glad if someone finally found the reason why
the AX.25 stack sometimes breaks and starts repeating some packet over and
over or gets stuck ack'ing some packet endlessly. It's been a while since
myself saw this but I think this is what happened to Arnau Sanchez a while
ago. See:

 http://hes.iki.fi/archive/linux-hams/200207/0046.html

At least earlier I could trigger this sort of behaviour almost at will by 
switching IP VC mode on.

-- 
Tomi Manninen           Internet:  oh2bns@sral.fi
OH2BNS                  AX.25:     oh2bns@oh2rbi.fin.eu
KP20ME04                Amprnet:   oh2bns@oh2rbi.ampr.org

Re: Status of AX.25 in 2.5 / 2.6

[Craig Small]

On Sat, Jul 27, 2002 at 03:07:00AM +0200, Ralf Baechle DO1GRB wrote:
> At the moment I just intend to dust off the code.  Anything else we can
> talk about later.  Unless there is already a list of bugs or wishes?

If you're looking for something later, you may want to solve the ancient
"why does an AX.25 interface need an IP address" question.  The answer
used to be "because it does", I'm not sure if that is still the case,
I've got ports sitting on a Linux computer over *there* (points to
rowlf) that don't have IP addresses or have 0.0.0.0

  - Craig
-- 
Craig Small VK2XLZ  GnuPG:1C1B D893 1418 2AF4 45EE  95CB C76C E5AC 12CA DFA5
Eye-Net Consulting http://www.eye-net.com.au/        <csmall@eye-net.com.au>
MIEEE <csmall@ieee.org>                 Debian developer <csmall@debian.org>

Re: Status of AX.25 in 2.5 / 2.6

[Tomi Manninen OH2BNS]

On Mon, 29 Jul 2002, Craig Small wrote:

> If you're looking for something later, you may want to solve the
> ancient "why does an AX.25 interface need an IP address" question.  
> The answer used to be "because it does", I'm not sure if that is still
> the case, I've got ports sitting on a Linux computer over *there*
> (points to rowlf) that don't have IP addresses or have 0.0.0.0

I think it's still the case. If an interface doesn't have an IP address,
it won't show up in the "list of known interfaces" from the kernel
(SIOCGIFCONF I think). So the utils/apps will never find it...

I did some digging a couple of years ago and also did a patch (with code
mostly stolen from Matt's/Jens' new-ax.25). See:

 http://hes.iki.fi/archive/dev-hams/2000/0055.html

I never got an answer.

Oh, by the way. Has anyone done anything with the NEW-AX.25 patch lately?
I think it has some potential but unfortunately seems it's now completely
unmaintained.

-- 
Tomi Manninen           Internet:  oh2bns@sral.fi
OH2BNS                  AX.25:     oh2bns@oh2rbi.fin.eu
KP20ME04                Amprnet:   oh2bns@oh2rbi.ampr.org

Re: Status of AX.25 in 2.5 / 2.6

[Iain Young - G7III]

On Mon, Jul 29, 2002 at 03:16:32PM +0300, Tomi Manninen OH2BNS wrote:

> Oh, by the way. Has anyone done anything with the NEW-AX.25 patch lately?
> I think it has some potential but unfortunately seems it's now completely
> unmaintained.

I haven't, but I do have a request if anyone decides to 'Take Up The 
Challenge".

Currently (IIRC), the patch routes all IP traffic destined for radio
links (44/8) down the ipax0 device, and then decides the best layer 2
(AX25) interface to throw it out.

I _personally_ believe that this is not the way it should be, I don't
actually like this, but unfortunatley the ipax0 device actually
encapsulates the IP packet, and puts the AX25 header on etc..

Before the patch became unmaintained, I was thinking of modifying
the ipax code, so that:

a) It was a module in its own right.
b) It would only speak to one named AX25 interface (eg ipax0==ax0,
ipax1==ax1 etc)

Of course, being a module, you would be able to load one per interface.
and route different parts of net 44 to different interfaces. This way
'we' can run layer 3 routing protocols.  (Yeah, Im a sick puppy)

Alternatively, you could still do the current NEW-AX25 behaviour of
everything going down ipax0...


I never did the needed mods, as the whole patch became unmaintained,
but if someone takes up the challenge (I dont have the time, or really
the skills to be a 'full-time' maintainer), I would be prepared to
have another look.

Until it's actually maintained, I personally can't see the point in
creating the patch (Im not using it, and the last kernel it was ported to,
was quite a while ago)

(Note that I haven't looked closely, but from thr last time I looked,
it shouldn't be all that hard to do what I want - certainly making it
a module shouldn't be hard at all)


All the Best

Iain

Re: Status of AX.25 in 2.5 / 2.6

[Tomi Manninen OH2BNS]

On Mon, 29 Jul 2002, Iain Young - G7III wrote:

> Currently (IIRC), the patch routes all IP traffic destined for radio
> links (44/8) down the ipax0 device, and then decides the best layer 2
> (AX25) interface to throw it out.
> 
> I _personally_ believe that this is not the way it should be, I don't
> actually like this, but unfortunatley the ipax0 device actually
> encapsulates the IP packet, and puts the AX25 header on etc..

Out of curiosity (and without having any strong personal opinion of my
own) why do you think this not the way to go? I know it breaks ARP but I
suppose that could be corrected somehow.

-- 
Tomi Manninen           Internet:  oh2bns@sral.fi
OH2BNS                  AX.25:     oh2bns@oh2rbi.fin.eu
KP20ME04                Amprnet:   oh2bns@oh2rbi.ampr.org

Re: Status of AX.25 in 2.5 / 2.6

[Iain Young - G7III]

Hi Tomi,

You Wrote:

> Out of curiosity (and without having any strong personal opinion of my
> own) why do you think this not the way to go? I know it breaks ARP but I
> suppose that could be corrected somehow.

To be honest, it is just network 'purity', and my own personal
preference.

To me, Layer 2 (AX25 in our case) should not dictate the Layer 3 (IP)
routing decisions. Layer 3 routing should be the domain of Layer 3.

Letting Layer 2 make the decision, while in most cases will get you
the shortest path, may not give you the path you actually want
(Again, network purity and my personal opinion)

I like to be able to say things like 44.0/16 should be routed via
g7iii-1, 44.128/16 via dummy0 (black hole), 44.130 via g7iii-2,
and route of last resort, 44/8 via g7iii-3 etc.

(You can probably guess that I deal with networks, DNS, etc etc
for a living :>)

Of course, I do understand that I am probably the odd-ball case here,
and for most AX25 users, the KJD stack behaviour is fine.

Which is of course why I considered modifying the ipax device to
be a module, and only talk to a named layer 2 interface, and load
several modules, so i could route 44.0/16 via ipax0, 44.128/16
via dummy0, 44.130 via ipax1, and the last resort of 44/8 via
ipax2.


All the Best

Iain

Re: Status of AX.25 in 2.5 / 2.6

[Ken Koster]

On Wednesday 31 July 2002 10:53, Iain Young - G7III wrote:
> Hi Tomi,
>
> You Wrote:
> > Out of curiosity (and without having any strong personal opinion of my
> > own) why do you think this not the way to go? I know it breaks ARP but I
> > suppose that could be corrected somehow.
>
> To be honest, it is just network 'purity', and my own personal
> preference.

And mine as well,  let's not muck with the layers at least not in such an
egregious way.  And fixing ARP may not be that easy.

> To me, Layer 2 (AX25 in our case) should not dictate the Layer 3 (IP)
> routing decisions. Layer 3 routing should be the domain of Layer 3.
>
> Letting Layer 2 make the decision, while in most cases will get you
> the shortest path, may not give you the path you actually want
> (Again, network purity and my personal opinion)
>
> I like to be able to say things like 44.0/16 should be routed via
> g7iii-1, 44.128/16 via dummy0 (black hole), 44.130 via g7iii-2,
> and route of last resort, 44/8 via g7iii-3 etc.
>
> (You can probably guess that I deal with networks, DNS, etc etc
> for a living :>)
>
> Of course, I do understand that I am probably the odd-ball case here,
> and for most AX25 users, the KJD stack behaviour is fine.

You're not the only one, our whole Puget Sound network is configured with
ax25 as just a simple link level protocol, no netrom, rose or other protocols.
Each lan is independant and RIP2 is used for dynamic routing between
lan's.  If the KJD stack behaviour gets in our way it won't be finding it's way
into any kernel we build.

>
> Which is of course why I considered modifying the ipax device to
> be a module, and only talk to a named layer 2 interface, and load
> several modules, so i could route 44.0/16 via ipax0, 44.128/16
> via dummy0, 44.130 via ipax1, and the last resort of 44/8 via
> ipax2.

That would probably work for us as well.

Ken,  N7IPB

Re: Status of AX.25 in 2.5 / 2.6

[Craig Small]

On Mon, Jul 29, 2002 at 07:50:37PM +0100, Iain Young - G7III wrote:
> On Mon, Jul 29, 2002 at 03:16:32PM +0300, Tomi Manninen OH2BNS wrote:
> 
> > Oh, by the way. Has anyone done anything with the NEW-AX.25 patch lately?
> > I think it has some potential but unfortunately seems it's now completely
> > unmaintained.
> 
> I haven't, but I do have a request if anyone decides to 'Take Up The 
> Challenge".
> 
> Currently (IIRC), the patch routes all IP traffic destined for radio
> links (44/8) down the ipax0 device, and then decides the best layer 2
> (AX25) interface to throw it out.
> 
> I _personally_ believe that this is not the way it should be, I don't
> actually like this, but unfortunatley the ipax0 device actually
> encapsulates the IP packet, and puts the AX25 header on etc..
I think that's actually a very interesting idea myself.  Very interesting to 
have the AX.25 stuff sitting down in layer 2 and the IP sitting on a
different interface.  It sounds a lot like Linux bridges which have a
br0 interface, you might even be able to nick that code.

This is my set of interfaces on my firewall bridge:

 /sbin/ip addr show
1: lo: <LOOPBACK,UP> mtu 16436 qdisc noqueue
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host
2: eth0: <BROADCAST,MULTICAST,PROMISC,UP> mtu 1500 qdisc pfifo_fast qlen 100
    link/ether 00:50:bf:7a:05:88 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::250:bfff:fe7a:588/10 scope link
3: eth1: <BROADCAST,MULTICAST,PROMISC,UP> mtu 1500 qdisc pfifo_fast qlen 100
    link/ether 00:50:ba:88:b4:8e brd ff:ff:ff:ff:ff:ff
    inet6 fe80::250:baff:fe88:b48e/10 scope link
4: gre0@NONE: <NOARP> mtu 1476 qdisc noop
    link/gre 0.0.0.0 brd 0.0.0.0
5: sit0@NONE: <NOARP> mtu 1480 qdisc noop
    link/sit 0.0.0.0 brd 0.0.0.0
8: br0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue
    link/ether 00:50:ba:88:b4:8e brd ff:ff:ff:ff:ff:ff
    inet 172.16.42.22/24 brd 172.16.42.255 scope global br0
    inet6 fe80::250:baff:fe88:b48e/10 scope link

Ignore the IPv6 (inet6) addresses, you can see eth0 and eth1 have no IP
address but there is a br0 interface which does.

Of course I bet noone thinks running spanning tree over radio is a good
idea :)

  - Craig
-- 
Craig Small VK2XLZ  GnuPG:1C1B D893 1418 2AF4 45EE  95CB C76C E5AC 12CA DFA5
Eye-Net Consulting http://www.eye-net.com.au/        <csmall@eye-net.com.au>
MIEEE <csmall@ieee.org>                 Debian developer <csmall@debian.org>

Re: Status of AX.25 in 2.5 / 2.6

[Chuck Gelm]

Dear Sirs:
 The eth1 device associated with my pppoe modem
had no IP address, yet is is displayed with
root@firewall:/# ifconfig
command. Somehow my smtp, pop, web browser,
ftp, ... all seem to find it.
:-|
Chuck nc8q

Tomi Manninen OH2BNS wrote:
> 
> On Mon, 29 Jul 2002, Craig Small wrote:
> 
> > If you're looking for something later, you may want to solve the
> > ancient "why does an AX.25 interface need an IP address" question.
> > The answer used to be "because it does", I'm not sure if that is still
> > the case, I've got ports sitting on a Linux computer over *there*
> > (points to rowlf) that don't have IP addresses or have 0.0.0.0
> 
> I think it's still the case. If an interface doesn't have an IP address,
> it won't show up in the "list of known interfaces" from the kernel
> (SIOCGIFCONF I think). So the utils/apps will never find it...
> 
> I did some digging a couple of years ago and also did a patch (with code
> mostly stolen from Matt's/Jens' new-ax.25). See:
> 
>  http://hes.iki.fi/archive/dev-hams/2000/0055.html
> 
> I never got an answer.
> 
> Oh, by the way. Has anyone done anything with the NEW-AX.25 patch lately?
> I think it has some potential but unfortunately seems it's now completely
> unmaintained.
> 
> --
> Tomi Manninen           Internet:  oh2bns@sral.fi
> OH2BNS                  AX.25:     oh2bns@oh2rbi.fin.eu
> KP20ME04                Amprnet:   oh2bns@oh2rbi.ampr.org
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-hams" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: Status of AX.25 in 2.5 / 2.6

[Robert Jenkins]

Hi,

Another couple of points with the present AX25 which I (and I believe
others) find annoying:-

1: The insistance on a separate call+ssid for each port.

Every port is allocated a unique name in axports anyway, so why the need
for the unique call as well???

(This is WAY more annoying to me than the requirement for an IP address
- at least it will accept the same IP on multiple ports!)


It certainly does not seem to be a requirement for AX25, as the Dos BPQ
node works fine with one call for the whole system. Being able to use
the same callsign/ssid for multiple ports would greatly simplify some
more comnplex configs.

As far as I know, the callsigns / aliases that the AX25 code uses for
incoming connects are the ones set in ax25d.conf and have no connection
to the 'axports' callsigns; these are used for outgoing connects only.



2: The apparent requirement for two or more Netrom ports / aliases for
the Netrom system to work correctly? Most of the docs on setting up
netrom say separate ports are needed for incoming and outgoing connects.
Why???
Again, it's not a fundamental requirement for Netrom, it's an oddity in
the Linux implementation.





One other request to anyone doing updates; please keep adding comments &
useage notes to the sources! 

Some functions do have brief descriptions, others have 'to do' notes or
nothing at all. It makes it hard to do anything productive with the code
when you can only spend short periods of time on it, and spend most of
that time just trying to refresh your memory of what does what.


Regards,

Robert Jenkins.

RE: Status of AX.25 in 2.5 / 2.6

[Tomi Manninen OH2BNS]

On Mon, 29 Jul 2002, Robert Jenkins wrote:

> Every port is allocated a unique name in axports anyway, so why the need
> for the unique call as well???

The names in axports are simply directly mapped to those callsigns by the
ax25-utils (libax25 to be exact). Kernel does not know anything about the
axports names, it deals with the ifconfig callsigns. They have to be
unique.

> As far as I know, the callsigns / aliases that the AX25 code uses for
> incoming connects are the ones set in ax25d.conf and have no connection
> to the 'axports' callsigns; these are used for outgoing connects only.

They are used for IP traffic and as default callsigns for other stuff. So
if you don't use IP on a port and have configured stuff properly, the
ifconfig callsigns don't have to be valid callsigns. They could be PORT-1,
PORT-2 or whatever.

However you are right in that this a bit annoying feature. The kernel now
supports BINDTODEV and it should be possible to get rid of all this.

> 2: The apparent requirement for two or more Netrom ports / aliases for
> the Netrom system to work correctly? Most of the docs on setting up
> netrom say separate ports are needed for incoming and outgoing connects.

It's actually: one port for internode traffic (using NET/ROM protocol) and
one port for user access.

> Why???
> Again, it's not a fundamental requirement for Netrom, it's an oddity in
> the Linux implementation.

No. It's a bug in AX.25 protocol specification if anything.

The AX.25 SABM packet does not have a protocol ID. So when receiving an
incoming connect request the system can not know (without hackery and
guesswork) what kind of connection is requested. The main problem with
this is that if you use the same netrom port, you will risk getting bad
interaction with your neighbor netrom nodes. Note that I said "risk"; you
don't _have_to_ use two netrom ports, _if_ you know what you are doing. If
you don't know what you are doing, you can cause trouble.

Other implementations use all kinds of hacks to circumvent the problem but
I don't think there is any really clean solution (if there is please
educate me). Jonathan didn't want to include those hacks to Linux and I
quite agree to his decision.

-- 
Tomi Manninen           Internet:  oh2bns@sral.fi
OH2BNS                  AX.25:     oh2bns@oh2rbi.fin.eu
KP20ME04                Amprnet:   oh2bns@oh2rbi.ampr.org

RE: Status of AX.25 in 2.5 / 2.6

[Robert Jenkins]

Hi Tomi,

Thanks for the info on callsign useage and the netrom 'oddities'.

I must admit that I'm not that well up on the details of netrom
encapsulation.

My only thought re. the problem you mention with the SABM frame not
having a protocol ID is that surely this applies equally to IP via ax25
etc.? 

Is there no mechanism here that can be duplicated for Netrom? 
(And apologies in advance if I'm talking total rubbish :)




Ps. One mod to the utils which I'm in the process of implementing
myself, if it is of interest to anyone else:

An addition to mheardd / mheard, in combination with the 'distance.c'
code from DigiNed by Henk, PE1DNN, to give distance & bearing to any
station with recognisable location info in it's beacon.

This is a feature I saw in a demo of the Dos PZT Node software by Paula,
G8PZT. I thought it was a rather neat idea & worth adding to the Linux
utils.


Regards,

Robert Jenkins, G8TBF.

RE: Status of AX.25 in 2.5 / 2.6

[Tomi Manninen]

On Mon, 29 Jul 2002, Robert Jenkins wrote:

> My only thought re. the problem you mention with the SABM frame not
> having a protocol ID is that surely this applies equally to IP via ax25
> etc.? 

Yes. That is why you should not have any user services (that are called
with plain AX.25) like LinuxNode or a BBS using the same callsign as you 
have in ifconfig/axports.

-- 
Tomi Manninen           Internet:  oh2bns@sral.fi
OH2BNS                  AX.25:     oh2bns@oh2rbi.fin.eu
KP20ME04                Amprnet:   oh2bns@oh2rbi.ampr.org

Re: Status of AX.25 in 2.5 / 2.6

[Jason Flynn G7OCD]

Tomi Manninen wrote:
> Yes. That is why you should not have any user services (that are called
> with plain AX.25) like LinuxNode or a BBS using the same callsign as you 
> have in ifconfig/axports.

  I'm aware fully of the reasons behind this, but when you are running
a system with 13 AX25 ports you start running out of SSIDs for your
services. I've had to start naming services with names that aren't
valid callsigns like 'MARTCONV' and 'SDGBBS' because before long I'm
going to have used all the SSIDs for ports...
It's limiting but we just have to put up with it or choose a new
L2 addressing scheme.

	J

PS Anyone still not conviced about different L2 callsigns and
IP addresses needed for each amateur port should think about
the MACs and IPs on an internet router...
Then the light should switch on :-)

Re: Status of AX.25 in 2.5 / 2.6

[Tomi Manninen OH2BNS]

On Tue, 30 Jul 2002, Jason Flynn G7OCD wrote:

>   I'm aware fully of the reasons behind this, but when you are running
> a system with 13 AX25 ports you start running out of SSIDs for your
> services. I've had to start naming services with names that aren't
> valid callsigns like 'MARTCONV' and 'SDGBBS' because before long I'm
> going to have used all the SSIDs for ports...

Yep, this is definitely a problem.

We should try to get rid of the need for an unique callsign-ssid for each
AX.25 interface. In fact it might be possible already (with SO_BINDTODEV).

However I still strongly believe that we need (want) a separate callsign
for the L3 traffic. Ultimately it might be possible to use one callsign
for all L3 protocol traffic (NET/ROM, ROSE, IP). Then a typical system
could run with a minimum of two callsigns.

-- 
Tomi Manninen           Internet:  oh2bns@sral.fi
OH2BNS                  AX.25:     oh2bns@oh2rbi.fin.eu
KP20ME04                Amprnet:   oh2bns@oh2rbi.ampr.org

Re: Status of AX.25 in 2.5 / 2.6

[Chuck Gelm]

ditto on the note from Robert Jenkins  :-)
...
and use the same keyword|token|name for the same thing
in all configuration files:

An excerpt from a message dated 3/12/02 8:56 AM
"  What I noticed was the different token names.  
Many applications and 'man' pages refer to the same thing, 
but use a different token 'name'.

 To make it easier for newbies, wouldn't it be great if all
applications, documentation, and configuration files all
used the same token name for the same thing?

Token name      Place where used
-----           ----
name            man axports
port            man kissattach
<port_name>     AX25-HOWTO/x1474.html
portname        AX25-HOWTO/x495.html#AEN1143
Port Name       man ax25d
-----           ----

 It seems to me that "<port_name>", "portname", and "Port Name" 
are close enough, but "port" (kissattach) and "name" ('axports')
are too dissimilar to tell that they both refer to the same thing.
:-|
Chuck nc8q
Espouse Elucidation, Eschew Obfuscation."

Robert Jenkins wrote:
> 
> Hi,
> 
> Another couple of points with the present AX25 which I (and I believe
> others) find annoying:-
> 
> 1: The insistance on a separate call+ssid for each port.
> 
> Every port is allocated a unique name in axports anyway, so why the need
> for the unique call as well???
> 
> (This is WAY more annoying to me than the requirement for an IP address
> - at least it will accept the same IP on multiple ports!)
> 
> It certainly does not seem to be a requirement for AX25, as the Dos BPQ
> node works fine with one call for the whole system. Being able to use
> the same callsign/ssid for multiple ports would greatly simplify some
> more comnplex configs.
> 
> As far as I know, the callsigns / aliases that the AX25 code uses for
> incoming connects are the ones set in ax25d.conf and have no connection
> to the 'axports' callsigns; these are used for outgoing connects only.
> 
> 2: The apparent requirement for two or more Netrom ports / aliases for
> the Netrom system to work correctly? Most of the docs on setting up
> netrom say separate ports are needed for incoming and outgoing connects.
> Why???
> Again, it's not a fundamental requirement for Netrom, it's an oddity in
> the Linux implementation.
> 
> One other request to anyone doing updates; please keep adding comments &
> useage notes to the sources!
> 
> Some functions do have brief descriptions, others have 'to do' notes or
> nothing at all. It makes it hard to do anything productive with the code
> when you can only spend short periods of time on it, and spend most of
> that time just trying to refresh your memory of what does what.
> 
> Regards,
> 
> Robert Jenkins.
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-hams" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: Status of AX.25 in 2.5 / 2.6

[Stewart Wilkinson]

On Mon, 29 Jul 2002, Tomi Manninen wrote:

> On Mon, 29 Jul 2002, Robert Jenkins wrote:
> 
> > My only thought re. the problem you mention with the SABM frame not
> > having a protocol ID is that surely this applies equally to IP via ax25
> > etc.? 
> 
> Yes. That is why you should not have any user services (that are called
> with plain AX.25) like LinuxNode or a BBS using the same callsign as you 
> have in ifconfig/axports.

Other Programs such as BPQ and PZT's Xrouter manage to do AX25, NETROM,
TCP/IP (and now APRS) using the same callsign on ALL Radio Ports and if I
am not mistaken JNOS & TNOS do too.

Surley if they can do it, then with the correct programming it could also
be done in Linux ?

I seem to recall seeing a flow diagram that described how one of those
other programs managed to cope with such things, I don't remember which
one, or the full details.

As I recall its starts something like this:

	Station A wants to send some as yet unknown Frame Type to (or via)
	Station B:

	Station A sends AX25 SABM request to Station B

	Station B responds with an AX25 UA and waits for further frames
	from Station A.

	Station A sends a Frame with L4:
	
		Oh we know how to handle that.

	Station A sends a Fram with IP:

		Oh we can handle that too.

	Station A sends a Frame with just AX25 Data:

		We can handle that too.

Now I don't (at 01.30) see any problem ?

---
Stewart G0LGS
g0lgs@gb7lgs.co.uk

RE: Status of AX.25 in 2.5 / 2.6

[Tomi Manninen OH2BNS]

On Mon, 29 Jul 2002, Stewart Wilkinson wrote:

> Station A wants to send some as yet unknown Frame Type to (or via)
> 	Station B:
> 
> 	Station A sends AX25 SABM request to Station B
> 
> 	Station B responds with an AX25 UA and waits for further frames
> 	from Station A.
> 
> 	Station A sends a Frame with L4:
> 		Oh we know how to handle that.
> 
> 	Station A sends a Fram with IP:
> 		Oh we can handle that too.

These are no problem. Linux can handle these quite nicely as is.

> 	Station A sends a Frame with just AX25 Data:
> 		We can handle that too.

This is the potential problem. Here we need to know whether to launch a
user interface to serve a user or not. Remember that in linux the protocol
handling (including the L4 and IP cases above) is done in kernel space and
the user interface in, well, user space. With programs like BPQ, TheNet
(the TNC firmware) and maybe PZT (I really don't know) this separation
isn't probably really an issue. Since they effectively have control of the
whole hardware alone and the whole software is one monolithic thingy where
such things as proper protocol layering don't count, it isn't a problem to
do whatever (possibly ugly things) they do to accomplish it.

Actually I think most of them resort to just waiting for the first
information packet to arrive from the connectee. That means there won't be
any welcoming texts or such. The poor user is blindly connected somewhere
and needs to start using the system without knowing where he is... This is
something that probably _could_ be implemented in Linux.

In xNOS (which I last looked at something like 7-8 years ago) there used
to be all sorts of weird hacks like "mbox jumpstart" or "look at nodes
list" etc. to guess which incoming connects are from users and which from
other network elements. Then someone finally found the ultimate solution:
lets give the mbox a different callsign!!! Things might of course have
changed since...

In _my_ opinion the only viable solution would be (an option) to wait for
the first I-packet. Can it be done in kernel space? To be honest I don't
know. One thing is for sure: if it needs changes outside the AX.25
protocol stack (like in the socket API), it will never be accepted in the
official kernel.

Can it be done in user space? Probably ax25d could handle it somehow.
Without much thought I'd say it is possible but probably not too simple.
But if someone feels like it, go ahead, start coding! I dare you to... ;)

-- 
Tomi Manninen           Internet:  oh2bns@sral.fi
OH2BNS                  AX.25:     oh2bns@oh2rbi.fin.eu
KP20ME04                Amprnet:   oh2bns@oh2rbi.ampr.org