BUGs into libax25

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 <[email protected]> Jun 1 2008

73 de bernard, f6bvp

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

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

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.

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

Ralf