Last week I posted a question about an interaction I saw when trying to 
use LinuxNode to establish an AX.25 connection with another LinuxNode 
over an axip link.  I didn't receive any replies that explained what 
was happening, so I did my best to figure it out.  The paragraphs below 
are a first draft of the explanation I plan to put into the gateway 
section of the book.  I'd really, really, appreciate any feedback on 
whether this explanation is correct, or coherent.

Thanks,

John N8UR
[EMAIL PROTECTED]

-------------
Extract from _Networking_Without_Wires_, copyright 1999 John Ackermann 
N8UR:

"Once you figure it out, configuring ax25ipd is quite straightforward, 
largely because (unlike xNOS) all the axip routes share a single 
interface.  However, there is a downside to this simplicity.  You need 
to be careful about using the LinuxNode software to gateway AX.25 
connections across an axip link.  This came to light recently when we 
were configuring a pair of Linux axip gateway systems to link two 
PacketCluster nodes, and I think it's worth taking a couple of 
paragraphs to show what happened; if nothing else, you'll gain an 
appreciation of the interactions that can cause problems in computer 
networking!

For various reasons, the link between the two Clusters was going to be 
done using straight AX.25 connections via the Linux node program.  In 
other words, the station initiating the link would first connect via RF 
to the LinuxNode at his end of the gateway, and from there issue a 
command like "c axip W8APR" to connect to the LinuxNode at the other 
end of the tunnel.  From W8APR, he would issue another connect command 
to reach the remote cluster.  Although we had everything configured 
correctly, the script didn't seem to work reliably.  Some test 
configurations would work, while others resulted in no connection being 
made between the two LinuxNodes via the axip link.

Further digging showed that the only time the axip link worked was when 
the callsign of the user was the same as that of the node.  In other 
words, W8APR-5 could establish a connection to K8MK via the W8APR 
gateway, but a user with a different callsign could not.  Very strange, 
but there is a reason (if not a solution).

Here's the first part of the problem.  Since ax25ipd can support many 
axip links on a single interface, it relies on callsigns to determine 
to which IP address the packet should go.  If the destination callsign 
doesn't match a route defined in ax25ipd.conf, the packet goes into 
never-never-land; although it is sent to the axip interface, it never 
comes out.  This is different than an xNOS gateway, which can ignore 
callsigns because it uses a different port name for each axip link.

The second part of the problem is that the LinuxNode program quite 
properly does callsign substitution when you use its "(C)onnect <port> 
<callsign>" command.  In other words, if I am connected to the W8APR 
node and issue the command "c axip K8MK", to reach Jim's Linux axip 
gateway, the packet will be sent with N8UR as the source address,* not 
W8APR.

My connect request will make it to K8MK, but what happens then?  K8MK 
attempts to respond, but to N8UR and not W8APR -- it has no way of 
knowing that I connected using the W8APR node.  All it knows is that 
the packet came in on the axip interface.  So, it sends the 
acknowledgement back to N8UR via axip.  Since W8APR, not N8UR, is 
defined in K8MK's ax25ipd.conf routing table, the daemon doesn't know 
where to send the packet and it goes off into limbo.  The result is 
that I never get the "Connected to…" message.

This means that ax25ipd and node don't make a good combination for user 
connections.  A workaround is to run NET/ROM at each end of the AXIP 
link and instruct users to connect to the remote LinuxNode using 
NET/ROM syntax (no port name in the connect command).  Since the layer 
3 NET/ROM packets will use the node callsigns (the user's callsign is 
encapsulated as part of the NET/ROM frame), the connection will work 
properly.

*  Actually, the callsign will have an "inverted SSID" attached to it, 
so N8UR will be sent as "N8UR-15".

Reply via email to