[nos-bbs] AX.25 status reporting

[(Skip) K8RRA]

On Mon, 2006-09-25 at 17:08 -0400, Barry Siegfried wrote:

> ["(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".

Careful Barry, jnos contains numerous(?) TCP/IP based resources -
telnet, smtp, and the list goes on...
Every time IP content is moved over an AX path, multinode comes alive,
ARP finds(?) a path, and content is encapsulated.
Little depends on ACK stuff - but as you point out both AX and IP
contain (redundant?) rules for various types of content.
Is datagram seen (somewhere?) as being superior and thus default?  Does
the opinion still hold water in 2006?

> 
> > 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, 

YUP - and today TAPR has an active(?) group revisiting related subjects
that may effect IP over AX.
I have the opinion that much can be done to improve our situation - and
no time to devote to that exact subject.

> 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...

Right on - I have grown up in "datagram" mode.   Although I'd still like
to see "A" is linked to "B" at the AX level I guess...
I'll begin the experiment with VC - and watch for the differences...

> 
> > There is another aspect >>SNIP<<
> 
> ARP list entries which are dynamic (i.e. determined on the fly) "live"
> for as long as the 'arp life' entry is set.

HMMM - I have so far missed this parm in my search.  Will I need to
search .src?
I also see manual arp table entries - maybe I need to remove
"eavesdropping" and add "static"?
But then many ARPs originate remotely...

> >>SNIP<<?
> 
> Hopefully, I covered what you were looking for.

To a large extent you have Barry.  THANKS VERY MUCH.
As I consider what I've just learned it seems the implementation of IP
over AX has made it difficult for AX to optimize what AX does (or might
do) well when carrying IP.  

> 
> 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 |
> +----------+----------------------------+
> 
> _______________________________________________
> nos-bbs mailing list
> nos-bbs at lists.tapr.org
> https://lists.tapr.org/cgi-bin/mailman/listinfo/nos-bbs


73
de [George (Skip) VerDuin] K8RRA k
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/nos-bbs_lists.tapr.org/attachments/20060925/6cf57edf/attachment.html>