What were the reasons of having IP address at AX.25 interfaces ?

What were the reasons of having IP address at AX.25 interfaces ?

[Matti Aarnio]

Can anybody remember, why AX.25 interfaces in Linux kernel are
enforced to have IP addresses by tools such as KISSATTACH ?

I can well understand that the IP address is OPTIONAL, but
not that it is MANDATORY.


This came up as I am going over all related tools, and wondering
their behaviour justifications.

73 de Matti, OH2MQK

Re: What were the reasons of having IP address at AX.25 interfaces ?

[Matti Aarnio]

On Sun, Feb 03, 2008 at 06:39:19PM +0000, Glenn Wright wrote:
> For the HAMS like me that run TCP/IP.

Sure, but that does not mean that _all_ interfaces must have IP address.
In my specific present application scope the question is APRS -- those
radio channels do not run IP at all, and therefore forcing the interfaces
to have IP is superflous at best.

> Matti Aarnio wrote:
> > I can well understand that the IP address is OPTIONAL, but
> > not that it is MANDATORY.

Thus the question: is there a reason to have the IP address
as MANDATORY parameter for things like  kissattach ?


Related: at present there are no ready-made init-scripts for
AX.25/ROSE/etc.   Or perhaps I just have failed to spot any
in any Debian variations, or RedHat/SuSE...

Something like what there exists for IP settings.

73 de Matti, OH2MQK

Re: What were the reasons of having mandatory IP address at AX.25 interfaces ?

[Matti Aarnio]

.. the original reason was apparently that _ifconfig_ blew up
when it saw protocols that it didn't understand on network
interfaces.  Possibly when there was no IP protocol on an
interface.

This happened on DECNET, and apparently on others too.

Thus the  SIOCGIFCONF  ioctl is not returning much else
than interfaces with IP addresses on them, and to get
_all_ interfaces, one must read thru  /proc/net/dev  file.

Some reason like that is possibly behind the reason why
SIOCGIFCONF does not find anything but PF_INET sockets
even when it is run on  PF_AX25 type socket..


The "fun" part is that  ifconfig  does look for all devices
in /proc/net/dev.   Perhaps we should just make all devices
findable with  SIOCGIFCONF regardless of what protocols
they may support ?   And if the  ifconfig  blows up, the
bug is in ifconfig tool, not kernel.

Alternatively one could iterate all network devices of
protocol family X being enabled when  ioctl() is called
on socket with PF_x  (like PF_AX25.)


Can anyone recall any real reason why this would not be
acceptable ?

/Matti Aarnio

Re: What were the reasons of having mandatory IP address at AX.25 interfaces ?

[Andi Kleen]

Matti Aarnio <matti.aarnio@zmailer.org> writes:

> .. the original reason was apparently that _ifconfig_ blew up
> when it saw protocols that it didn't understand on network
> interfaces.  Possibly when there was no IP protocol on an
> interface.

It's not only ifconfig, a lot of programs use SIOCGIFCONF
to query ip addresses.

-Andi

Re: What were the reasons of having mandatory IP address at AX.25 interfaces ?

[Matti Aarnio]

On Mon, Feb 04, 2008 at 03:38:35PM +0100, Andi Kleen wrote:
> Matti Aarnio <matti.aarnio@zmailer.org> writes:
> 
> > .. the original reason was apparently that _ifconfig_ blew up
> > when it saw protocols that it didn't understand on network
> > interfaces.  Possibly when there was no IP protocol on an
> > interface.
> 
> It's not only ifconfig, a lot of programs use SIOCGIFCONF
> to query ip addresses.

So ?   My codes do too, and filter away things they are not
interested in.  (When they specifically look for IP addresses.)

Of course I may be in minority by expecting the unexpected,
and handling such "weird" multiprotocol systems...


I found original explanation for that mandatoryness finally.
It was in order to silence bug reports in certain cases when
real fix would have been to really find all interfaces instead
of complaining.

In the end I used same trick that  ifconfig  tool uses to find
all interfaces, and filter away those that AX.25 subsystems
are not interested in - end of  "SIOCGIFCONF problems".


netdev:ish developemnt thing would be, that we ( = myself probably )
make SIOCGIFCONF to return those devices that have addresses
in the protocol family that the socket used for the query has.

For PF_INET we might return also PF_INET6 values to lessen
the spanish-inquisition -impact...

.. or do you know any who looks up interface IP addresses with
PF_FILE ( = AF_UNIX ) socket ?

What do the competitor systems B, S, and W do ?

> -Andi

/Matti Aarnio

Re: What were the reasons of having IP address at AX.25 interfaces ?

[Ralf Baechle DL5RB]

On Sun, Feb 03, 2008 at 08:04:17PM +0200, Matti Aarnio wrote:

> Can anybody remember, why AX.25 interfaces in Linux kernel are
> enforced to have IP addresses by tools such as KISSATTACH ?

A while ago I was curious myself for why that is needed and dug into
the CVS history.  I found the IP address wasn't always enforced and the
commit message didn't really explain why the change was needed.

73 de DL5RB op Ralf

---
DL5RB / M0LRB / AB1IN
Loc.    JN47BS / CQ 14 / ITU 28 / DOK A21
Packet: DL5RB@DB0FHN.#BAY.DEU.EU

Re: What were the reasons of having IP address at AX.25 interfaces ?

[Matti Aarnio]

On Mon, Mar 31, 2008 at 10:50:48PM +0100, Ralf Baechle DL5RB wrote:
> On Sun, Feb 03, 2008 at 08:04:17PM +0200, Matti Aarnio wrote:
> > Can anybody remember, why AX.25 interfaces in Linux kernel are
> > enforced to have IP addresses by tools such as KISSATTACH ?
> 
> A while ago I was curious myself for why that is needed and dug into
> the CVS history.  I found the IP address wasn't always enforced and the
> commit message didn't really explain why the change was needed.
> 
> 73 de DL5RB op Ralf

I figured it eventually myself, and rewrote  libax25's
axconfig/rsconfig/nrconfig functions to not to require IP addresses
in AX.25/Netrom/Rose interfaces to be able to find all interface
currently defined.

> ---
> DL5RB / M0LRB / AB1IN
> Loc.    JN47BS / CQ 14 / ITU 28 / DOK A21
> Packet: DL5RB@DB0FHN.#BAY.DEU.EU

73 de Matti, OH2MQK

Re: What were the reasons of having IP address at AX.25 interfaces ?

[Thomas Osterried]

> > A while ago I was curious myself for why that is needed and dug into
> > the CVS history.  I found the IP address wasn't always enforced and the
> > commit message didn't really explain why the change was needed.
> > 
> > 73 de DL5RB op Ralf
> 
> I figured it eventually myself, and rewrote  libax25's
> axconfig/rsconfig/nrconfig functions to not to require IP addresses
> in AX.25/Netrom/Rose interfaces to be able to find all interface
> currently defined.

I think it was a design problem, because the used system call only
shows those interfaces which are up. 
My approach is, to use /proc to find them, inspired by the "ifconfig" tool
(if i remember correctly).
This simply enhances get_ax25_ifaces() by this method. The code is in
the CVS version, but not enabled by default (-DFIND_ALL_INTERFACES).

I hat no problems with it on kernel 2.6. But on kernel 2.4., i observed
that when an incoming SABM occurs, the kernel did panic.

73,
	- Thomas  dl9sau

Re: What were the reasons of having IP address at AX.25 interfaces ?

[Matti Aarnio]

On Tue, Apr 01, 2008 at 10:17:26AM +0200, Thomas Osterried wrote:
> > > A while ago I was curious myself for why that is needed and dug into
> > > the CVS history.  I found the IP address wasn't always enforced and the
> > > commit message didn't really explain why the change was needed.
> > > 
> > > 73 de DL5RB op Ralf
> > 
> > I figured it eventually myself, and rewrote  libax25's
> > axconfig/rsconfig/nrconfig functions to not to require IP addresses
> > in AX.25/Netrom/Rose interfaces to be able to find all interface
> > currently defined.
> 
> I think it was a design problem, because the used system call only
> shows those interfaces which are up. 

Are up and with IP addresses.  I am not 100% sure that the used ioctl()
misbehaves in this regard.

> My approach is, to use /proc to find them, inspired by the "ifconfig" tool
> (if i remember correctly).

I wrote similar code myself, and turned the logic of the whole axconfig.c
upside down in order to scan files only once, nor build 

> This simply enhances get_ax25_ifaces() by this method. The code is in
> the CVS version, but not enabled by default (-DFIND_ALL_INTERFACES).
> 
> I hat no problems with it on kernel 2.6. But on kernel 2.4., i observed
> that when an incoming SABM occurs, the kernel did panic.

And recently people have observed kernel panics with ROSE traffic..
Permanently avoiding using some machinery because it breaks for some
users is not a good thing in my mind ..  those broken things will never
get fixed if we don't find them, and report them.


I use only AX.25 UI traffic myself (APRS), thus those SABM problems do
not bite me, but for rare CONS users they are troublesome things indeed..


> 73,
> 	- Thomas  dl9sau

  /Matti Aarnio - OH2MQK

Re: What were the reasons of having IP address at AX.25 interfaces ?

[Thomas Osterried]

> I use only AX.25 UI traffic myself (APRS), thus those SABM problems do
> not bite me, but for rare CONS users they are troublesome things indeed..

exactly the same for me.
It was, when an OM, who was new to APRS, was connectecting my old kernel 2.4
box directly with his packet program.... oopsa ;)

But this kind of trouble could be solveable.

I really think, ax25 interfaces should not depend on an IP Address,
because there are reasons you may not need / want IP. Or IPv6. Or .. .

Without IP, you also have not nasty things (on misconfiguration)
like ARP, Samba Broadcasts, or the newest hypes: AVAHI mDNS broadcasts.

For this reason, kissattach's IP-address argument is now optional.
And: the brought up interface has not the "BROADCAST" flag set;
who needs broadcast, and likes kissattach to do the job, could use
the new "-b" option.

73,
	- Thomas  dl9sau

Re: What were the reasons of having IP address at AX.25 interfaces ?

[Bernard Pidoux]

Matti Aarnio a écrit :
>
> And recently people have observed kernel panics with ROSE traffic..
> Permanently avoiding using some machinery because it breaks for some
> users is not a good thing in my mind ..  those broken things will never
> get fixed if we don't find them, and report them.
>
>
>   
>   /Matti Aarnio - OH2MQK
>   
I agree with Matti.
Not reporting problems (that often mean bugs in the code) with AX25 or 
ROSE or any application is the best mean to prevent any progress.
We are lucky with Linux to have an open source operating system and most 
application programs are also open source.
So we must use this opportunity to help improving the code.
The result is that when a bug is identified and published there is much 
chance that it will be corrected fast.
Where to report such problems ? Well, on a list, such as linux-hams.
Then, if it is really a bug, then the report will be directed to the 
maintainer of the software and to a list of developers.
For example, I have been recently exchanging a lot of observations on 
Linux netdev list that allowed,  together with reports from others, to 
correct bugs in AX25 code and ROSE.
The last corrected bug is actually only two days old. And it concerned 
an important although probably very old bug in ROSE module.
This means that progress is still running on the bleeding edge of AX25 
packet, that is in Linux kernel.
Doing that, we can get a much more stable Linux with AX25 applications.
Next kernel releases, 2.6.25 and 2.6.26 will certainly provide a major 
step for AX25 support, as it will hopefully integrate those vital patches.
However this does not preclude to continue the adaptative work for AX25 
libraries, tools and applications available for everybody.

73 de Bernard, f6bvp

--
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