Hello Jens, hello all,
firstly, I want to thank Jens for his quick reply:
> > Hello to the list,
> > Compiling the new kernel we found that the drivers for
> >
> > 6pack
> > yam
> > bpqether
> >
> > cause the kernel compile to fail
>
> By intention. This way they will get fixed *apropriately*.
> I could also fix them, but I�d need the hardware to test it or
> somebody reliable for remote-diagnostics. However, it�s very much
> easier for the developers of these drivers to fix the interface than
> for me.
That's true and understandable for me. Mentioning that fact I did not want to
complain, I simply wanted to state the facts. At least I am one of those
people that often forget things that are not repeated often enough.
> > 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':
>
> Obviously the linker wasn�t told to link against the ncurses library.
> This is either a problem with the configure script or with your system.
> I suspect the latter one since the original packages must have the same
> problem and nobody else complained. Add -lncurses to the command line
> and it will probably work.
Yes, I also think it has something to do with Caldera's configuration.
Allthough I appreciate your hint here, I am still curious _why exactly_ it
did not work under Open Linux while there were no problems at all under SuSE
6.3 .
> > 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
>
> You have to set a route using axparms or via the ax25 routing deamon.
> This not really a bug, I will change this behaviour of call, but there
> are other things to do which have priority.
OK, I think I can live with it. I only was in doubt if I had a configuration
error.
> > But setting an option for either serial or parallel or MIDI connected PTT
> > circuit failed. It seems that sethdlc is broken, too.
>
> I suspect that you still had the parport and serial device drivers
> loaded
> or some hardware problem. If not please investigate and send patches.
Hmm. Since I used a serial mouse at that machine I was not able to unload the
serial driver as a whole. If my memory serves me right it was possible at
least under 2.0.35 or later to simply disable the serial driver for a certain
port using a command like
setserial /dev/ttySx uart none
Doesn't that work any more?
> > sethdlc -i -d bcsf0
> >
> > failed on both computers.
> > I am not sure if this is a fault of sethdlc or the driver.
>
> Perhaps you could be more specific here.
If there is a problem with serial.o like mentioned above, maybe I just found
the reason for that behaviour.
Just some more detail:
As stated in the HOWTO and in the manual pages (no newer information
available) it should be possible to set the options like operating mode,
ports and so on using sethdlc for both soundmodem and baycom when these
modules are loaded already.
Even more, sethdlc provides us with a very simple diagnostics/debug feature.
sethdlc -i networkdevice -d
can be used for testing if the driver is able to work with the hardware.
Especially the numbers shown for "demodcyc" (soundmodem) or "dbg2" (baycom)
are interesting. They should constantly be changing. If they do not or simply
remain zero, the driver will be unable to detect incoming packets.
There always have been problems with the baycom driver and certain UART chips
which then lead to the result that no RX was possible. But it seems there are
now even more of them with the new drivers.
Unfortunately, the smdiag utility does not work any more so I have no idea
how to detect if there is a signal available at the soundcard's inputs at all.
In another message, Thomas Pinz <[EMAIL PROTECTED]> stated that one has to set up
filters for RX and TX when using soundmodem. I have to ask here what exactly
does that mean. Are there filters needed in form of external hardware or is
it a certain software that I have to set up additionally?
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
