Subject: Re: Sun 3/50 Ham Radio.
To: None <>
From: David Kelly <>
List: port-sun3
Date: 01/31/2001 20:34:05
"=3D?ISO-8859-1?Q?H=3DE5kan Th=3DF6rngren?=3D" writes:
> >>>>> "David" =3D=3D David Kelly <> writes:
> =

> David> needed then use the kernel's SL/IP, PPP, or BPF interface. Direc=
t =

> David> access to the 8530 serial port would be nice as then one could u=
se a =

> David> BayCom-ish radio modem without bit-banging the protocol.
> =

> I am no kernel expert in any way, but I think it would be nice to have
> it in the kernel.  I would like to use it together with TCP/IP, can
> that be done without having it inside the kernel?

How much does it hurt for pppd(8) or ppp(8) to be outside the kernel?
I see ax.25 as a link-level layer where it is advantageous to be able to =

run completely without the kernel's networking, or for TCP/IP then by =

all means provide a SL/IP, PPP, or BPF connection back into the kernel.

> You should also
> consider that many machines that run NetBSD are old and slow.  AX25
> in itself is not slow, it depends on the communication hardware being
> used.

1200 bps is the definitive interface. 9600 can still be purchased out =

of most catalogs. 56k is exotica. On the 1200 bps links you can count =

on 300 mS overhead just to key the radio. Faster is possible but you =

have to convince those with slow synthesizers that its their problem =

and not yours. Something like 60 cps thruput.

A major problem with using kernel TCP/IP stacks is the very long delays =

which are typical of AX.25 RF links.

> If someone would like to describe to me briefly how they think AX25
> should be implemented on NetBSD I would be very interested.  Just to
> get me started and think a little bit more about it...
> =

> David> Unix needs a Unix-AX25 userland suite of applications. But nobod=
y seems =

> David> to care enough these days to spend the time doing it. Myself inc=
> =

> That is probably correct, but you could probably get somewhere using
> TCP/IP based applications over packet radio for a start.  FTP and SMTP
> would be nice for example. We used AX25 a little bit for running a
> multiuser game around here. It was not popular, other people seemed to
> like a quiet channel more, even though they did little with it...

IMHO what is needed is a Unix-like ability to build unique applications
on a solid base. Am not referring to *BSD but to the Unix Way where you
build a good solid engine where fairings and trailer hitches can be
added by others without breaking everything. Such as the way a Unix
shell integrates all the other utilities.

Were I to do it, and start from a clean sheet, the first thing I'd do is
built a daemon to attach to a serial port and communicate with a TNC in
its most brain dead mode, KISS. The daemon will have to implement AX.25
itself. But having control over the TNC it could also provide the raw
pipe onto the radio for TCP/IP. Or tunnel TCP/IP over AX.25. Would think
of this daemon as being much like inetd in that on incoming connect it
could consult its configuration and launch a BBS. Most "destinations"
for an incoming packet would be external to this daemon, a very few
would be served by simple internal "servers". For incoming TCP/IP
packets it could direct them to the kernel.

On a system with multiple radios, run multiple daemons, each with its
own config. A TCP link into the kernel would be useful for these daemons
to talk to each other. There is already a tunneling protocol in use for
amateur radio operators to link over the internet. The same thing that =

links two daemons in one computer could link to the rest of the world.

Interesting that the entire 44.x.x.x net is

Routing is quite another issue.

I don't think I'm the only one to have had similar ideas. "Kernel AX.25"
has quashed any separated AX.25 development. TNOS and JNOS
all-in-one-ported-from-DOS systems are still in use by a few diehards. =

But then again this is a Sun mailing list so everybody knows about that.

David Kelly N4HHE,
The human mind ordinarily operates at only ten percent of its
capacity -- the rest is overhead for the operating system.