[nos-bbs] AX.25 status reporting

[Barry Siegfried]

["(Skip) K8RRA" <k8rra at ameritech.net> wrote]:

> This has been a long-standing question for me...
>
> While there is TCP/IP traffic actively being carried, the AX.25 level
> system carries this invisibly unless you want to read the traced I/O.
> My expectation is that after ARP establishes the AX.25 link for
> encapsulation of TCP/IP content, that the link would appear in the AX25
> STATUS command output for one example.  In my experience it does not.

What is the AX.25 channel IP 'mode' for the channel on which you are
trying to view "connection" stats using 'ax25 status'?  If it is
'datagram' (and not 'virtual circuit'), then there is no "connection"
being made between the IP peers on the channel and there is therefore
no control block keeping track of one.  It is the control blocks of
AX.25 "connections" you are seeing when you view 'ax25 status'.  No
connection, no AX.25 control block, no "status".

> Also in my experience I'm left wondering if the underlying ax system
> is performing OK in carrying IP content.  Yes - there are IP STATUS
> reports that are very helpful, but not an AX.25 viewpoint.  This
> missing link adds to the "magic" of jnos...

20 years ago, everyone told us that 'datagram' was good (simply
because it reduced channel traffic by eliminating the AX.25 I-frame
acknowledgements).  Unfortunately, that was a lie.  The fact is, an
underlying 'datagram' AX.25 "system" is probably not performing very
well at all with carrying IP content.  For every IP frame that gets
lost due to hidden terminals and collisions, the TCP/IP system relies
on the TCP retry parameters that are set at each end of the TCP
transport circuit and these will normally back off to much greater
amounts than an AX.25 t1 (retry) timer will.  This is why it is
*good* to use 'virtual circuit' mode on channels which are carrying
IP.  And you will also see your AX.25 "stats" that way...

> There is another aspect to this that puzzles me.  I see frequent (in
> my opinion) repeat ARP activity.  I can explain it only if there is no
> cache to map AX to IP for transport.  Considering that the 44... network
> is static, and the AX network is fairly unchanging over short periods
> (days), it seems wasteful to repeat ARP with the same question and same
> answer.

ARP list entries which are dynamic (i.e. determined on the fly) "live"
for as long as the 'arp life' entry is set.  If you want them to live
longer, then set 'arp life' higher.  Once the timer expires, if the
'arp poll' flag for a given interface is set, then the machine will
send a new ARP request to "refresh" the entry in the ARP list.  If
the 'arp poll' flag for a given interface is not set, then the entry
will simply be dropped from the ARP list.

> So the question becomes:  Is there good reason to hide AX system
> measurements where IP content is being encapsulated and transported in
> AX.25 packets?

No.  But then again, they will only be "hidden" when there is nothing
to report.  There is nothing to report when the AX.25 channel IP 'mode'
is 'datagram'.

> Because IP packet is typically broken into multiple AX packets, it
> seems useful to see both viewpoints?   For example: when ax goes into
> "recovery" mode, IP simply shows as "waiting"...

You won't see a "recovery" state when the AX.25 channel IP 'mode' is
'datagram'.  The "recovery" state exists only with connected AX.25
circuits.

> Further - if ARP is part of "keep alive" features, isn't ping a more
> effective tool?

ARP is not part of any "keep alive" feature.  It exists strictly to
translate IP addresses into "hardware" or MAC addresses.  With AX.25,
they are callsigns.  With ethernet adapters, they are six 8-bit
hexadecimal numbers.

> If this seems like I'm mucking around in system design, be mindful
> that the more obscure these things are the fewer users there are who
> can discuss jnos with authority.  Can anyone expand my understanding?

Hopefully, I covered what you were looking for.

73, de Barry, K2MF >>
           o
          <|>      Barry Siegfried
+---------/-\---------------------------+
| Internet | bgs at mfnos.net              |
| HomePage | http://www.mfnos.net/~bgs  |
+----------+----------------------------+
| Amprnet  | k2mf at nnj.k2mf.ampr.org     |
| PBBS     | k2mf at k2ge.#cnj.nj.usa.noam |
+----------+----------------------------+