ax25ipd UDP mode documentation

[Bob Morgan]

Well, for several years, I have had a nagging problem getting the udp mode
of ax25ipd to work at all.  Yesterday I finally hacked my way through
it with use of strace and reference to various parts of the source,
and lots of trial and error.  It turns out to be a documentation problem,
I didn't have to change any code, just the .conf file.

Just now, Ralf posted a request for improvements to ax25-howto, and this
may fit in with that also.  Ralf, I can take the ax25ipd portion of ax25-howto
and edit it with this newer material if you like, but I guess I need to
know where the recent official copy of it lives.  (I might even redo
the ax25ipd manpage, but I would have to figure out how to do the
manpage editing.  I haven't done anything with manpages before except READ 
them.)

Continuing with the matter of running udp transport with ax25ipd:
For various reasons, here centered around a simplistic DSL masquerading
modem/router, I have a need to actually make the udp mode work.  The dsl box
allows me to masquerade a few tcp and/or udp ports through it to various
hosts on its lan, but it doesn't allow me to masquerade any other protocols,
such as axip # 93 for instance.  The only other option is to demasquerade
the whole thing and expose the lan to the internet, which I am not
in a position to do with this particular lan.  And I have a few other reasons
as well that amount to experimentation with other gadgets that I would like
to interconnect with ax25 and they also only have tcp and udp hooks, not ip.

So, with the existing documentation I have been able to find, namely
the ax25-howto, and the .conf file and some things that come with
the ax25ipd tarball, anytime I configured it for udp, absolutely
nothing happened.  It just swallowed up the packets and never threw
any udp packets out onto the lan.  What isn't mentioned in the docs is
that in addition to setting the udp option in the socket definition near
the top of the .conf file, one must ALSO specify a udp option on the
tail end of EACH routing line in the routing section near the end of
the .conf file.  It didn't tell me that, and the source didn't really
help much, until I did a lot of trial and error with strace
running, and I satisfied myself where routing was getting lost, and then
after more trial and error, I eventually found what the config parsing
wanted to see to set the flags that the routing processing wanted.

When I added a udp option to the end of all of the route definitions,
it started working.  It doesn't say this anyplace that I have found.

The code in the config parsing routines looks at first glance like some
flags (b and d) might not parse in combination with the udp option.
I didn't pursue or test that possibility any farther, although
I think it needs to be looked at.  That's a TODO or FIXME item.

It also happens to be possible to listen on one udp port, and send
udp packets to the far end under some other port number, although that
would be a weird asymetrical routing situation that not very many
situations would ever need.  It turns out that the default udp port number
of 10093 can be overridden by specifying some other port number just
after the udp option on the end of either the socket or the route definitions.

The socket definition sets the udp listen port, and also the source port
on outgoing packets, so the other end knows what the return address/port is.
The route definition sets the udp destination port for each route.
Leaving off the udp option on a route leaves the packets in no-mans-land
and they disappear entirely if udp socket has been defined.  I think
that is actually a bug, but anyway that is what it does.

Of course, by specifying other ports on both socket and routes, some
other udp port number can be used if necessary, in case some combination
of firewalls and routers only allow some specific ports through.
It is quite flexible it looks like, if one finds out how to set it up.

Previously I also had to use some different param definitions to implement
a higher speed modem on a tnc that I was feeding with one end of ax25ipd,
and I have also documented how to specify the various params in the
.conf file.  They follow straight from the kiss definition itself.
I also have encountered a situation a few times where the tnc gets
reset while ax25ipd is running unaffected, and at that time, the tnc
restarts with some default params of its own which may not be optimum,
particularly if some params are deliberately set up in the .conf file.
I then have to do things like stop and restart ax25ipd, or maybe
disconnect the serial port from the tnc and send it some params
from some other device, or maybe a kill -s SIGHUP  to ax25ipd
would accomplish the same thing.  I think I vaguely recall that others
have also observed that behavior.  Maybe the workaround is to use
a cronjob to periodically send the SIGHUP, but the real fix is to code
up a periodic broadcast params patch in ax25ipd to refresh a tnc.
(Or has this been done 

YAPP server pgm

[Bob Morgan]

I have been watching some of the discussion go past here
about YAPP.  A few years ago I hacked up the source for
call (the linux ax25 packet user pgm) and extracted the yapp
portion of the code out as two separate programs.  I got the
download half of it working to my satisfaction, and I
never have yet had time to finish the upload half of it.
I call them yd.c and yu.c, respectively, for the usual
BBS commands with which users usually associate them.

I am not sure if these programs I wrote are what the
original requestor wanted or not.  Here is what they do:
They sit on an unattended AX.25 capable file server, and users connect
to them and download files.  If I had the upload half of
the program finished, they could upload files to the server also.
The normal way I have implemented them is as an external command
of the NODE program, where I have configured NODE to redirect
transparent stdin/stdout to these programs.  (I also have
made some minor patches to NODE to handle some transparency
issues, and from memory I don't remember if the patches
affected this interface or some others.)  These programs
are called by some hooks in node.conf, or possibly
in ax25d.conf.  They are NOT command line driven in any way,
and are NOT useable from the keyboard locally.  (For this, I
use the standard CALL application.)

Along a little different thread, here are my side-by-side
comparisons of yapp vs. ftp as a file transfer process:

I usually start to see problems with YAPP on ax25 radio
channels with a filesize greater than roughly 20K to 30K.
Yapp protocol just buffers up as much of the file as
there is comm buffer space to handle, after the initial
handshaking headers are exchanged and the data transfer
state starts up, and continues to refill buffers from
there on to the end of the file.  It doesn't have any
application-layer flow control or pacing.  Sure, AX.25 has some
hop-by-hop short term flow control, but that doesn't
seem to be sufficient.  I have also been known to
use it in some mixed networks where some of the packets
are ax.25 over ethernet (BPQ, at ethernet speeds of course),
followed by rerouting these packets out over real radio
ports at traditional lower packet speeds, so sometimes
there is quite a mismatch which of course has to be
buffered up, and this can cause more problems.  Anyhow the
usual symptom with YAPP is that the connection breaks off
during a longer file transfer.  Shorter files do fine.

FTP, on the other hand, seems to be bulletproof.
Ftp does some application layer end-to-end flow control and
pacing, and IP helps out also in the flow control area.
Watch the progress displays on FTP to see it refill
the buffers as the file transfer progresses.  I usually
see it complete one 16K block before buffering up the next one.
Here, I am using IP over AX.25 UI frames with the
standard kernel ax.25 networking.  I don't recall
ever having a file transfer fail in the process of
sending the data, as long as the radio links held up.
Filesize doesn't seem to be a limit.  I once sent
a huge (by ax.25 packet standards at least) 3 or 4 MB
file by ftp at 1200b over a plain old packet link, and
while it took almost 12 hours on an otherwise idle
channel, it worked the first time and didn't stumble,
and correctly transferred the file intact. (It helps
to have a fan on the transmitter PA, particularly the
one sending the file out.)  As someone else observed,
the IP exponential backoff, when it occurs, is quite
painful to watch, and I would like to find out how
to tune it on AX.25 links.  Usually if it misses
a few packets it backs off much too far much too quickly,
and takes too long to take off again.

Comments, anyone?

I can post the source of yd.c (~19Kb) to the list, if that is
appropriate, or maybe send it somewhere if there is
some interest.  I could also post the comments at the front
of that file which explain things a bit more, to the list,
if necessary, without posting the whole file.  Sorry I haven't
had a chance to finish off the upload half of it yet.  In our
local situation, the download portion had a lot more
priority, so it got done first, and I haven't had a chance
to revisit it yet.  (This amounts to a first public
announcement that it exists and is available, gpl of course.)

I also have some semi-useful short patches to NODE that we
use locally that might be of some limited interest, I would
have to take a while to locate and document some of them.

73 de Bob Morgan, WB5AOH
wb5aoh at arrl dot net
or
wb5aoh at wb5aoh.dyndns.org

-
To unsubscribe from this list: send the line "unsubscribe linux-hams" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html