Hello to the list,
some days ago, there was announcement that the new DG2FEF AX.25-Stack is also
available for Linux kernel 2.2.14.
Since the pages at
http://www.afthd.tu-darmstadt.de/~dg1kjd/linux-ax25/index.html
claim that the DG2FEF AX.25 stack is already more reliable and more
performant than the out-of-the box Linux-AX.25 regardless of its development
state, I gave it a shot.
Here are the results.
We tested that new software on two different computers, one using SuSE Linux
6.3 (K6-300, 32 MB RAM, 1 GB harddrive) the other one using Caldera OpenLinux
2.3. (Celeron 400, 64 MB RAM, 20 GB harddrive).
At first, we upgraded the kernel to 2.2.24 and applied the DG2FEF patch. No
problems until then.
Compiling the new kernel we found that the drivers for
6pack
yam
bpqether
cause the kernel compile to fail when one of them is selected. That problem
is mentioned on http://www.afthd.tu-darmstadt.de/~dg1kjd/linux-
ax25/index.html , so there is no surprise.
If these three drivers are deselected, the kernel compiles successfully.
Here, we found a small bug in the kernel compile scripts.
Allthough make does not complain about the kernel image being too big lilo
will not accept it if it is more than 414 kB in size.
Until now, however, nothing unxpected or weird did happen. The surprises are
following.
While the patched libax25, ax25-apps and ax25-tools downloadable from
http://www.afthd.tu-darmstadt.de/~dg1kjd/linux-ax25/index.html compiled
without any problems under SuSE Linux 6.3, under Caldera OpenLinux 2.3 the
following errors occurred:
make all-recursive
make[1]: Entering directory `/usr/src/ax25-apps-kjd-1-0.0.4'
Making all in ax25ipd
make[2]: Entering directory `/usr/src/ax25-apps-kjd-1-0.0.4/ax25ipd'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory `/usr/src/ax25-apps-kjd-1-0.0.4/ax25ipd'
Making all in ax25rtd
make[2]: Entering directory `/usr/src/ax25-apps-kjd-1-0.0.4/ax25rtd'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory `/usr/src/ax25-apps-kjd-1-0.0.4/ax25rtd'
Making all in call
make[2]: Entering directory `/usr/src/ax25-apps-kjd-1-0.0.4/call'
/bin/sh ../libtool --mode=link gcc -g -O2 -Wall -o call call.o menu.o
crc.o yapp.o dostime.o -lax25
gcc -g -O2 -Wall -o call call.o menu.o crc.o yapp.o dostime.o -lax25
call.o: In function `statline':
/usr/src/ax25-apps-kjd-1-0.0.4/call/call.c:342: undefined reference to
`stdscr'
/usr/src/ax25-apps-kjd-1-0.0.4/call/call.c:342: undefined reference to `wmove'
/usr/src/ax25-apps-kjd-1-0.0.4/call/call.c:343: undefined reference to
`stdscr'
/usr/src/ax25-apps-kjd-1-0.0.4/call/call.c:343: undefined reference to
`wattr_on'
...and a lot more of these, also for the listen program. Some investigation
showed that these functions are defined in /usr/include/curses.h . The
strange thing is that allthough the compiler knows about that directory as a
part of the includes path it still complains. I have no clue why it does not
want to use the /usr/include/curses.h file.
Even more strange: Under SuSE 6.3, no errors at all. The
/usr/include/curses.h file is exactly the same on both distributions (ncurses-
4.2).
Nevertheless, call seems to have some problems with the new AX.25 stack.
Every time I want to connect to someone using a command like call radio
MYCALL the call program comes up with
Trying...
connect: No route to host
Here I have no idea how this can be fixed, too.
After some fiddling around, we got Linkt 6.2 to work.
Since we had no other hardware available we wanted to set up SoundModem and
BayCom.
After configuring the CM8330 onboard sound chips with the isapnptools and the
kernel pnp support compiled in we found that the SoundModem driver is able to
transmit.
But setting an option for either serial or parallel or MIDI connected PTT
circuit failed. It seems that sethdlc is broken, too.
Also, no soundcard (we tested with an AWE64, some MAD-16 cards and an older
ESS 688 AudioDrive) was able to decode incoming signals. Unfortunately,
smdiag is not included in the AX.25 software packages anymore, and older
versions do not work. Hopefully, there is some other software available to
simply show if there is a reasonable signal available or not. I had no time
yet to check this.
The same, regrettably, applies to the BayCom driver. Neither baycom_ser_hdx
nor baycom_ser_fdx worked. The first test using the debug feature of sethdlc
in a way like
sethdlc -i -d bcsf0
failed on both computers.
I am not sure if this is a fault of sethdlc or the driver.
So, the night finished rather frustrating for us - we got tired without
having any success.
Cheers, 73
Gerd
--
Gerd Roethig
Universit�t Leipzig, Medizinische Klinik u. PK I
Johannisallee 32, 04103 Leipzig
Tel. (0341) 97 12622, Fax (0341) 97 12515
