The `user_call' programs are really called:
ax25_call and
netrom_call. They are very simple programs
designed to be called from ax25d to automate
network connections to remote hosts. They may of course be called from
a number of other places such as shell scripts or other daemons such
as the node program.
They are like a very simple call program. They don't do any meddling
with the data at all, so the end of line handling you'll have to worry about
yourself.
Let's start with an example of how you might use them. Imagine you have
a small network at home and that you have one linux machine acting as your
Linux radio gateway and another machine, lets say a BPQ node connected to it
via an ethernet connection.
Normally if you wanted radio users to be able to connect
to the BPQ node they would either have to digipeat through your linux node,
or connect to the node program on your linux node and then connect from it.
The ax25_call program can simplify this if it is called from the
ax25d program.
Imagine the BPQ node has the callsign VK2KTJ-9 and that the linux
machine has the AX.25/ethernet port named `bpq'. Let us also imagine
the Linux gateway machine has a radio port called `radio'.
An entry in the /etc/ax25/ax25d.conf that looked like:
[VK2KTJ-1 via radio]
default * * * * * * *
root /usr/sbin/ax25_call ax25_call bpq %u vk2ktj-9 |
would enable users to connect direct to `VK2KTJ-1'
which would actually be the Linux ax25d daemon
and then be automatically switched to an AX.25 connection to
`VK2KTJ-9' via the `bpq'
interface.
There are all sorts of other possible configurations that you might try.
The `netrom_call' and `rose_call' utilities work in
similar ways. One amateur has used this utility to make connections to a
remote BBS easier. Normally the users would have to manually enter a long
connection string to make the call so he created an entry that made the BBS
appear as though it were on the local network by having his ax25d proxy
the connection to the remote machine.
Take our 
