This is another in my irregular series of technical briefings about Linux
and amateur radio. I felt like doing some of my thesis, but I decided to
write this instead as:
a) Its more interesting, and
b) More people will be interested, and
c) Its more useful :-)
d) Err...
e) Thats It.
This document is an attempt to explain how callsigns are handled in the
AX.25 code within Linux, and also within NET/ROM and ROSE. I will make
some simplifications to my description, but it should be true to how
things work in the kernel.
In the AX.25 code we have a thing called an AX.25 control block, in the
code itself it is called an ax25_cb and the information within it, it is
what is displayed when you do a "cat /proc/net/ax25". Each AX.25
connection has an ax25_cb, it contains the state variables, and of course
the callsigns of the connection, and lots of other stuff. An ax25_cb may
be associated with a socket, this is true when accepting connections via
ax25d, connecting out with call, etc. In which case data coming in for an
ax25_cb will usually find its way to the user. However an ax25_cb need
not be associated with a socket, this is typically the case for NET/ROM
interlink connections, AX.25 VC connections and ROSE interlink
connections. When doing a "cat /proc/net/ax25", you can tell an ax25_cb
*not* associated with a socket by blanks appearing in the Rcv-Q and Snd-Q
columns.
As has been stated many times on linux-hams, each interface declared in
/etc/ax25/axports must have a unique callsign associated with it. This is
so that a program can say to the kernel, I want to connect out on the
device with callsign G9BF-1, this does not always mean that the callsign
G9BF-1 will actually be used for the connection itself. This is probably
where the confusion in most peoples minds comes about, normally the
callsign for the port is hidden behind a port name like port144 or
whatever you want. As you appreciate if you have more than one port with
the same callsign, it becomes a lottery as to which one will used.
The port callsign in /etc/ax25/axports, say G9BF-1, will be used by IP and
nothing else unless you want it to.
Because this callsign is used by programs to tell the kernel which port
to use, and nothing more, it means that we can use any callsign we like
on any port. So we can say "listen on port G9BF-1 using the callsign
G9BF-2", which would be expressed in /etc/ax25/ax25d.conf as:
[G9BF-2 VIA port144]
where port144 had the callsign G9BF-1 in /etc/ax25/axports. Sure enough
it works, the callsign G9BF-1 itself never appears in the connects or in
any subsequent part of the packet conversation. It is a means to an end,
nothing more.
Thus we have "registered an interest" in the callsign G9BF-2 on port
G9BF-1. We can continue to do this until we get bored, a couple of
interesting twists is that we can:
a) Listen for the same callsign on all AX.25 ports, and
b) Listen as a pseudo-digipeater on a port.
The way that (a) is implemented is to use a special callsign called the
"null_ax25_address" which is recognised by the kernel as being special
and allows us to pull off the trick. (b) is in essence a relatively small
extension of the normal code, except we look in the digipeater address
fields for our callsign rather than in the destination address.
Once we have registered an interest in a callsign on a device, we will
accept incoming connections for that callsign on that device. If the
ax25_cb is associated with a socket then the user (eg ax25d) is told
about it and can perform the necessary work. If no socket is associated
with the ax25_cb then no-one is told about the connection, but it is
still accepted.
Once a given connection is running, data across the connection is acked
as normal, and then it is given to whoever wants it. So imagine that we
have a normal AX.25 Text connection to our BBS, and then the BBS starts
sending ROSE frames across it, we will accept them and pass them to the
ROSE protocol engine quite happily. So every running AX.25 connection is
potentially capable of handling any protocol across it. So for every
connection the following is true:
If TCP/IP is compiled into the kernel, and the PID is for IP Then
Pass the frame to the IP handler
Else If NET/ROM is compiled into the kernel, and the PID is for NET/ROM Then
Pass the frame to the NET/ROM handler
Else If ROSE is compiled into the kernel, and the PID is for ROSE Then
Pass the frame to the ROSE handler
Else If the PID is equal to that of the user Then
Pass the frame to the user
Else
Throw the frame away.
This approach is much easier than having a much more restrictive method
based on callsigns and PIDs. The line "If the PID is equal to that of the
user" deserves some expansion. When a user creates a socket, by default it
will use a PID of Text, however a user can specify a PID other than that.
The kernel will not allow the user to specify IP, NET/ROM or ROSE PIDs if
they are already active ... of course. So it is possible to do higher
level protocol work in user space, witness the Linux/FPAC program.
Enough of the AX.25 level, what about higher up.
With NET/ROM each NET/ROM callsign is a potential NET/ROM interlink
callsign. As normally defined (ala BPQ) only one of the NET/ROM callsigns
is actually used that way, but that behaviour is difficult to emulate.
What we do is we register an interest in each NET/ROM callsign (not the
alias) with AX.25 as being a potential connection callsign. That is why
it is possible for a user to connect to a NET/ROM callsign and not to
receive a reply.
I think this area deserves some more investigation.
ROSE is simpler. By default ROSE will use the port callsigns defined in
/etc/ax25/axports on each port. This is because ROSE doesn't deal in
callsigns like NET/ROM does, how would you work out which callsign the
address 2080192303 is ? What has been implemented here is that an option
in rsparms allows for a single AX.25 callsign to be registered with AX.25
for use by all ROSE interlinks on all ports. This fits in with current
ROSE practice and was easy to implement anyway.
Some of the decisions I have made have verged on the simplistic at times,
but they have turned out to be pretty generic, and in retrospect I stand
by my decisions. A little cleaning up could be done in due course and
over the coming months I intend to do so.
I'll go back to sleep now.
Jonathan
-- +----------------------------------+---------------------------------------+ | e-mail: gmfm@roskapostia.tunk.net | Telephone: +44 (0) 973 695261 | +----------------------------------+---------------------------------------+ | Author of Linux kernel AX.25, NET/ROM and Rose. | +--------------------------------------------------------------------------+