Re: Netrom

[Nate Bargmann <n0nb@n0nb.us>]

* On 2013 09 Jul 21:15 -0500, Cathryn Mataga wrote:
> On 7/9/13 7:08 PM, Cathryn Mataga wrote:
> >On 7/9/13 3:34 PM, Thomas Osterried wrote:
> >>((255*255)+128)/256 = 254 => It does decrease on the next hop
> >>and behind.
> >
> >
> >
> >Oops, you're right.  So what about this situation.
> >
> >A -- B   -- C
> >         \   /
> >           D
> >
> >
> >If A sends a broadcast to B.   The link from B back to A should
> >decrease the 'obsolete' value with each broadcasts.  But can the
> >listing loop around from C to D back to B?
> >
> >But the loop of death should eventually run out of gas when the
> >quality hits 0.  So, how are all those nodes sticking around for
> >years and years.  Even if misconfigured, can Netrom do this all by
> >itself.  Hmm.
> >--
> 
> Err, if A sends a broadast to B and then disconnects.

It has been a long time, nearly 20 years since I worked with NetROM, but
I do recall this.  Broadcasts are AX.25 UI (unconnected) packets and are
sent to the destination of NODES, at least that is what I recall of the
original NetROM, early TheNet, and G8BPQ nodes.  So Node A in this case
does not "disconnect" nor does it ever send its nodes list as part of
the connected level 2/level 3 session.  Even when there was a level
2/level 3 connection between nodes, the nodes broadcast was a UI packet
typically broadcast every 60 minutes often refered to as "node barf" by
some who didn't care to understand about their operation.

Most of us ran the nodes at the firmware default values although I'm
sure somebody tweaked things for better performance.

Actually, while NetROM was deployed on a single frequency in many areas,
particularly here in Kansas, Oklahoma and Nebraska due to financial
constraints, doing so really hurt performance.  As I recall, the system
was really designed to be sort of a cellular system with neighboring
user nodes on separate frequencies tied together by a common higher
speed backbone and coordination used to isolate user nodes.  However,
out here in the sticks, just getting one node on the air was an
accomplishment let alone doing it right.  But that is a topic for
another time.  In this scenario, user nodes would not send a nodes
broadcast on their radio port but would over the RS-232 port which is
how back-to-back and node stacks were built (three or more TNCs were
tied via a diode matrix to each other's RS-232 port to build a stack),
thus eliminating node barf from being seen by the users.

Once upon a time I had a Software 2000 NetROM manual that described a
lot of the protocol.  I have no idea if the authors of the Linux NetROM
code had access to that document or any other reference.  After years of
watching it, even when I had access to a NetROM network with a backbone,
NetROM seemed to fall apart after more than about three or four hops.
The most reliable way to make BBS forwarding work was to script the
connection through each node to the next manually as then a weaker path
would retry more often at level 2.  Otherwise, connecting to a distant
node a few hops away would result in level 3 timeouts from the first
node and kill the connection.  The nodes had no ability for true store
and forward and did not behave like routers.  

All of this is a bit hazy in my memory.

73, de Nate >>

-- 

"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."

Ham radio, Linux, bikes, and more: http://www.n0nb.us