BUGs into libax25

BUGs into libax25

[Bernard Pidoux]

Hi All,

I found a number of BUGs into libax25 that may affect nearly ALL AX25 
applications for it is in ax25_aton_entry() function that is used to 
translate a callsign into AX25 format.
Programs like kissattach, listen, ax25ipd, FPAC, xfbbd are concerned.

The code would return an error with 6 letters callsigns.


The second set of errors is in /proc/ax25/ timers format description.
since timers are now in millisec, they require a larger storage size.
This results in using unsigned long integers rather than unsigned short 
integers.

Ax25-tools and ax25-apps must be recompiled after recompilation and 
installation of this new libax25 version.
FPAC and LinuxFBB also.

I patched my own source of libax25 and uploaded it here :

http://f6bvp.free.fr/logiciels/ax25/libax25-0.0.11.5src_f6bvp.tgz

Here is the new ChangeLog entry :

libax25 0.0.11.5
         * BUG in axutils.c
           function ax25_aton_entry() was only testing 5 callsign 

           characters.
           A lot of ax25-tools and AX25 applications using this library
           function, including FPAC, could have problems with 6 letters
           callsigns. Corrected.

         * BUG in proc_ax25 structure timers members size declared in
           procutils.h. Since in kernel 2.6 the timers are now in 
milliseconds,
           they need more place to be saved (unsigned short --> unsigned 
long).
         * corrected, together with functions reading proc files in 
procutils.c.

  -- Bernard Pidoux <f6bvp@amsat.org>  Jun 1 2008


73 de bernard, f6bvp

Re: BUGs into libax25

[Mike McCarthy, W1NR]

As I recall, there is a limit to the size of a callsign in the AX.25 
protocol specification.  Will changing it create an incompatibility with 
standard TNC protocol stacks?

Mike, W1NR


Bernard Pidoux wrote:
> Hi All,
> 
> I found a number of BUGs into libax25 that may affect nearly ALL AX25 
> applications for it is in ax25_aton_entry() function that is used to 
> translate a callsign into AX25 format.
> Programs like kissattach, listen, ax25ipd, FPAC, xfbbd are concerned.
> 
> The code would return an error with 6 letters callsigns.
> 
> 
> The second set of errors is in /proc/ax25/ timers format description.
> since timers are now in millisec, they require a larger storage size.
> This results in using unsigned long integers rather than unsigned short 
> integers.
> 
> Ax25-tools and ax25-apps must be recompiled after recompilation and 
> installation of this new libax25 version.
> FPAC and LinuxFBB also.
> 
> I patched my own source of libax25 and uploaded it here :
> 
> http://f6bvp.free.fr/logiciels/ax25/libax25-0.0.11.5src_f6bvp.tgz
> 
> Here is the new ChangeLog entry :
> 
> libax25 0.0.11.5
>         * BUG in axutils.c
>           function ax25_aton_entry() was only testing 5 callsign
>           characters.
>           A lot of ax25-tools and AX25 applications using this library
>           function, including FPAC, could have problems with 6 letters
>           callsigns. Corrected.
> 
>         * BUG in proc_ax25 structure timers members size declared in
>           procutils.h. Since in kernel 2.6 the timers are now in 
> milliseconds,
>           they need more place to be saved (unsigned short --> unsigned 
> long).
>         * corrected, together with functions reading proc files in 
> procutils.c.
> 
>  -- Bernard Pidoux <f6bvp@amsat.org>  Jun 1 2008
> 
> 
> 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
> 

Re: BUGs into libax25

[Robin Gilks]

> As I recall, there is a limit to the size of a callsign in the AX.25
> protocol specification.  Will changing it create an incompatibility with
> standard TNC protocol stacks?
>
> Mike, W1NR
>

Copy to mailing list....

As I recall (from doing several AX25 implementations), the limit is 6
characters, at least one of which MUST be numeric. This would make 6
letters unsupported by the AX25 specification but not necessarily in
practice (but some TNCs etc may reject a connection).


-- 
Robin Gilks zl3rob/g8ecj

Re: BUGs into libax25

[Ralf Baechle DL5RB]

On Mon, Jun 02, 2008 at 12:26:19AM +0200, Bernard Pidoux wrote:

> I found a number of BUGs into libax25 that may affect nearly ALL AX25 
> applications for it is in ax25_aton_entry() function that is used to 
> translate a callsign into AX25 format.
> Programs like kissattach, listen, ax25ipd, FPAC, xfbbd are concerned.
>
> The code would return an error with 6 letters callsigns.
>
>
> The second set of errors is in /proc/ax25/ timers format description.
> since timers are now in millisec, they require a larger storage size.
> This results in using unsigned long integers rather than unsigned short 
> integers.
>
> Ax25-tools and ax25-apps must be recompiled after recompilation and 
> installation of this new libax25 version.
> FPAC and LinuxFBB also.

I guess that means we need to introduce symbol versions like glibc and a
few others.  Oh pleassure, oh fun.

  Ralf

Re: BUGs into libax25

[Ralf Baechle DL5RB]

On Sun, Jun 01, 2008 at 10:14:54PM -0400, Mike McCarthy, W1NR wrote:

> As I recall, there is a limit to the size of a callsign in the AX.25 
> protocol specification.  Will changing it create an incompatibility with 
> standard TNC protocol stacks?

Afaik the currently only user of 6-letter callsigns aside of special
event stations are Australien foundation license which look like VK3FABC
so 4-letter suffix and those are not permitted to use packet radio anyway.
I was wondering if Swaziland which only has a half-series assignment is
possibly using 3+3 calls.

Anyway, the maximum callsign length in the AX.25 spec is 6 characters and
(I looked into that ...) there is no way of extending that without causing
large scale software breakage :-(  It's almost like retrofitting 128-bit
addresses into IPv4 - it took a new protocol.

  Ralf

BUGs into libax25

[DL5DI]

This special event station callsign that we sometimes find like
DQ2008ANYEVENT will never work in packet radio.
The protocol header of ax25 frames only allows 6 bytes of callsign and 1
halfbyte of SSID.
Not only for the destiantion, also for all digipeaters inbetween.
We would need to change the whole protocol and all digipeaters and stations
using it worldwide to get that covered.
I expect that packet radio will be dead before that happens. :-)

73 de Hans, DL5DI

> -----Ursprüngliche Nachricht-----
> Von: linux-hams-owner@vger.kernel.org 
> [mailto:linux-hams-owner@vger.kernel.org] Im Auftrag von Ralf Baechle 
> DL5RB
> Gesendet: Montag, 2. Juni 2008 11:16
> An: Mike McCarthy, W1NR
> Cc: Bernard Pidoux; linux-hams; Ray Wells; Charlie k4gbb; Jerry 
> DeLong; F1TE; f8arr
> Betreff: Re: BUGs into libax25
> 
> On Sun, Jun 01, 2008 at 10:14:54PM -0400, Mike McCarthy, W1NR wrote:
> 
> > As I recall, there is a limit to the size of a callsign in
> the AX.25
> > protocol specification.  Will changing it create an incompatibility 
> > with standard TNC protocol stacks?
> 
> Afaik the currently only user of 6-letter callsigns aside of special 
> event stations are Australien foundation license which look like 
> VK3FABC so 4-letter suffix and those are not permitted to use packet 
> radio anyway.
> I was wondering if Swaziland which only has a half-series assignment 
> is possibly using 3+3 calls.
> 
> Anyway, the maximum callsign length in the AX.25 spec is 6 characters 
> and (I looked into that ...) there is no way of extending that without 
> causing large scale software breakage :-(  It's almost like 
> retrofitting 128-bit addresses into
> IPv4 - it took a new protocol.
> 
>   Ralf
> --
> 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
> 

--
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: BUGs into libax25

[Matti Aarnio]

On Mon, Jun 02, 2008 at 11:36:25AM +0200, DL5DI wrote:
> This special event station callsign that we sometimes find like
> DQ2008ANYEVENT will never work in packet radio.
> The protocol header of ax25 frames only allows 6 bytes of callsign and 1
> halfbyte of SSID.
> Not only for the destiantion, also for all digipeaters inbetween.
> We would need to change the whole protocol and all digipeaters and stations
> using it worldwide to get that covered.
> I expect that packet radio will be dead before that happens. :-)

Arbitrary long callsigns...   Only OSI stack can handle that, and even it
has some upper limits on address lengths.

On IPv6 the addresses are 16 bytes long, and low 8 bytes (64 bits) of them
are reserved for "link local" use.    Considering that..  one can encode
any callsign with 38 characters, add couple codes for things like
"no character here", and "next is ssid", that would be 40 codes.
Using 6 bits per character one could encode 10 characters + 4 bits on IPv6-
address "local half".  With arithmetic encoding (see APRS mic-e) maybe
17 code bytes.

Would that be AX.25 ?  Definitely not.  That would be IPv6.

On IPv6 the basic assumption is that link local area is /64 size slice,
and thus "AX.25 space" would be something smaller..  like  /32.

How could we implement smooth transition from AX.25 to IPv6 on data links ?
Very good question...  old legacy junk will want to live a long time.
(we are way too willing to recycle obsolete hardware...)

> 73 de Hans, DL5DI

73 de Matti, OH2MQK

Re: BUGs into libax25

[Bernard Pidoux]

Hi,

Sorry, I wrongly wrote 6 letters callsigns where I wanted to say 6 
characters. Not the same of course.
My typo leaded to an interesting discussion.
Somedays I dreamt that we could increase the SSID number up to 31.
But the necessary bytes are already taken by DAMA protocol and EAX25 flags.

Back to the bug.
With previous loop limit (<6) into the code, a callsign like KD4YAL-8 
would not be correctly translated into shifted ASCII AX25 code.
Actually, with this 6 characters callsign, SSID was truncated and an 
error message sent complaining about SSID not being correctly entered.
I had seen it very often in FPAC. I am glad I found the error while 
investigating on other bugs.

73 de Bernard, f6bvp

Matti Aarnio a écrit :
> On Mon, Jun 02, 2008 at 11:36:25AM +0200, DL5DI wrote:
>   
>> This special event station callsign that we sometimes find like
>> DQ2008ANYEVENT will never work in packet radio.
>> The protocol header of ax25 frames only allows 6 bytes of callsign and 1
>> halfbyte of SSID.
>> Not only for the destiantion, also for all digipeaters inbetween.
>> We would need to change the whole protocol and all digipeaters and stations
>> using it worldwide to get that covered.
>> I expect that packet radio will be dead before that happens. :-)
>>     
>
> Arbitrary long callsigns...   Only OSI stack can handle that, and even it
> has some upper limits on address lengths.
>
> On IPv6 the addresses are 16 bytes long, and low 8 bytes (64 bits) of them
> are reserved for "link local" use.    Considering that..  one can encode
> any callsign with 38 characters, add couple codes for things like
> "no character here", and "next is ssid", that would be 40 codes.
> Using 6 bits per character one could encode 10 characters + 4 bits on IPv6-
> address "local half".  With arithmetic encoding (see APRS mic-e) maybe
> 17 code bytes.
>
> Would that be AX.25 ?  Definitely not.  That would be IPv6.
>
> On IPv6 the basic assumption is that link local area is /64 size slice,
> and thus "AX.25 space" would be something smaller..  like  /32.
>
> How could we implement smooth transition from AX.25 to IPv6 on data links ?
> Very good question...  old legacy junk will want to live a long time.
> (we are way too willing to recycle obsolete hardware...)
>
>   
>> 73 de Hans, DL5DI
>>     
>
> 73 de Matti, OH2MQK
> --
> 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
>
>
>   

--
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: BUGs into libax25

[Dave Platt]

> Anyway, the maximum callsign length in the AX.25 spec is 6 characters and
> (I looked into that ...) there is no way of extending that without causing
> large scale software breakage :-(  It's almost like retrofitting 128-bit
> addresses into IPv4 - it took a new protocol.

It might not be *that* bad.  I believe that it would be possible to
support 7-ASCII-character callsigns in the six octets that are
available.  It would require specialized encoding and decoding of
the longer callsigns, but would not change the layout of the AX.25
packet header.

Consider that callsigns are strictly alphanumeric and case-
insensitive.  That means that there are only 37 possible
characters (A-Z, 0-9, space).  That's just barely more than
five bits of information per character.  There are less than
37^7 possible callsigns.

There are numerous ways to encode 37^7 different values in
six octets.  It's very easy if you're willing to just fill
the octets with binary data.  It's almost as easy if you
want to use printable ASCII only (blank through tilde,
avoiding DEL and all of the 32 nonprintables at the start
of the character set)... there are 95 such printable
characters, and 95^6 >> 37^7.

I suspect that there's probably a fairly easy way to ensure
that any such encoding of the long callsign would result in
a set of six octets which could be guaranteed to be
recognizable as *not* a standard unencoded ASCII callsign,
and thus make the meaning (and the decoding) entirely
unambiguous.

This method would certainly cause compatibility problems
for many TNCs and other AX.25 devices, but at least it's
vaguely upwards-compatible and doesn't change the packet
structure - just the interpretation of the callsign/address
field.

Whether it'll ever happen?  Probably not, would be my guess, at
least not as-is.  Maybe an approach which can embed an encoded
callsign in an IPV6 address would work better.