[nos-bbs] AXIP networking

(Skip) K8RRA k8rra at ameritech.net
Mon Dec 10 10:31:49 EST 2007


Incredibly interesting Barry.

On Mon, 2007-12-10 at 03:18 -0500, Barry Siegfried wrote:
> ["George F. VerDuin" <k8rra at ameritech.net> wrote]:
> 
> > Consider this:
> > Access to a particular tunnel requires a unique call ID, the only
> > uniqueness I can give this ID is with SSID, and so the SSID list
> > becomes very crowded as you enter more tunnels.
> 
> Yes, and that becomes particularly problematical when you have
> "lots" of tunnels.
As you can probably tell from my posts, I mis-interpreted my
documentation to the extent that I wanted to post the remote call in the
attach thus satisfying the uniqueness rules (certainly the other end of
the tunnel would not be heard locally) and the remote call would exist
in the active heard list (potentially) and be available as a contact
point to AX.25 users.  The posting of a SSID modified local call
obfuscates the remote identity and requires some local knowledge about
where this tunnel leads.  I don't like that reality, but I'm not in a
position to change it.

I have yet to complete the first tunnel, so there is still some unturned
issues ahead.  One of them for me is the view of other local AX only
hams for my node.  It now appears the most effective tool for
understanding the neighborhood is in fact NET/ROM when it brings the
subnet from the other end of the tunnel to the local node.  That can be
a big expansion step.

> 
> > Further -- if mycall is used it is immediately ambiguous so omitting
> > the call is a no-solution because it violates the uniqueness rules
> > for digipeating.
> 
> This is an interesting topic.  I believe that its code and the code
> in Linux to do that are similar in functionality, which is that each
> AX.25 neighbor (or user) source to the machine that cross-interface
> digipeats has to know the callsign of the interface that faces toward
> the destination (not the source) ahead of time and then use that
> callsign in the digipeater string.  The code then does some fancy
> callsign substitution in the digipeater string using the callsign
> that is assigned to the interface on the source side of the circuit
> for the return path on the destination side of the circuit.
Yes - but I guess I'm dense enough to not understand why the fancy
footwork is not reserved for local cross-port cases when there is some
complex ambiguity to resolve, let's say for example when there is a mix
of jnos and unix AX traffic going on at the site.  In my over-simple
model the tunnel simply serves to bring a remote site into the "range of
being heard" and needs no other identity associated with it.

Alas - I expect experience will be my most complete teacher?  I am now
eager to complete this, and perhaps to some non-jnos sites as well.
> 
>>SNIP<<
> 
> 73, de Barry, K2MF >>

Thanks for your patience and explanation Barry...


73
de [George (Skip) VerDuin] K8RRA k





More information about the nos-bbs mailing list