* On 2018 28 Oct 16:45 -0500, Stuart Longland wrote:
> On 27/10/18 22:38, Nate Bargmann wrote:
> > I worked with TheNet in the late '80s and early '90s until TheNet X1J
> > became available, and the mnemonic was similar to a digipeater alias
> > that could be set in a TNC2.  It was a convenience for the user as we
> > generally used a local place name for it.  Nodes would do an AX.25
> > connection to each other using their proper callsigns, not the aliases.
> 
> Ahh okay, so if I want to know a station's AX.25 call-sign, I don't
> actually need to know an alias and can ignore it.  (Or run a local DNS
> server so applications can use ${alias}.ax25 or some such.)
> 
> Interesting you make mention of "TheNet X1J"… I've heard people in
> Brisbane WICEN make mention of "X1J" in isolation, and I came to the
> (wrong) understanding that "X1J" was yet another protocol.
> 
> From your comment there, I gather it is a particular release of TheNet,
> and thus, an implementation of Net/ROM.

As I recall, TheNet X1J was an advancement from a gent in the UK who
expanded the code to fit a 27C512 EPROM.  As a slight modification, the
user would bend one pin of the EPROM out and not seat it in the socket
and then a jumper wire would soldered from that pin to a point on the PC
board for bank switching the EPROM since the Z80 could only access half
of the EPROM at any one time.  I recall doing this to a few MFJ-1270B
TNCs.

It was an extension of the original TheNet and was primarily used for
Net/ROM though I recall that it had some TCP/IP features as well.

> > I'm not sure that Net/ROM was ever that smart.  Two or three hops was
> > about the practical limit.  But then most of the "network" around these
> > parts was all on the same frequency rather than having a proper
> > separation of user access frequency and backbone traffic frequency
> > between nodes.  Another aspect was that few understood the effect of the
> > Quality parameter over several hops.
> 
> Interesting, it looked from what I had read as if the protocol itself
> didn't limit the number of hops, that as it passed through each Net/ROM
> node, a decision was made on where the next hop would be, much like IP does.
> 
> I guess each node will try and pick the "best" possible path, but from
> what I've seen of the algorithms, if you have two possible routes:
> A→C→G→Z and A→B→H→Q→Z; A will more likely pick the former even if the
> link between G and Z is worse than H→Q and Q→Z.

Part of the problem is that no one likely really understood the Quality
value that Net/ROM seemed to base its routing algorithm on and left it
at the default value of 192 (75%).  Note that I'm no expert on the
protocol, I'm just recalling experiences from 20+ years hence.

> Single-frequency networks would complicate matters a bit, all the
> cross-talk between the "backbone" and access point networks.

It's a mess.  ;-)

But, at the time it was all we could afford out here in the sticks, so
we made do.

> Yeah, long term I'm thinking I'll be looking to replace Net/ROM, but I'm
> thinking being backward-compatible would help in the adoption of a new
> protocol.

Net/ROM nodes should also act as a digipeater unless the sysop turned
that off (I don't recall, exactly).  If so, one could go about using
them as AX.25 digis, etc.

> What I'm aiming for, is someone can plug a TNC in, input their call-sign
> and a SSID, click "connect", and a client on their computer will bring
> up a network interface that will "appear" to look like a VPN to their
> host.  In reality, it's intercepting IPv6 traffic, performing header
> "compression" on the packets, fragmenting frames over ~128 bytes and
> encapsulating the fragments into AX.25 UI frames.

A TNC?  In this day an age a simple to configure Raspberry Pi with a
TNC-Pi piggy-backed onto it makes far more sense, at least to me.
Unfortunately, the TNC-Pi is the most expensive part of that combination.

> So like Net/ROM, hopefully minimal configuration.  An application such
> as a chat client, file transfer client or form entry program would just
> open a listening socket like any other TCP/IP application.
> 
> At most, there might be some parsing logic to decode call-signs encoded
> in the IPv6 address' lower 64-bits.

Sounds interesting!

> Interesting, so Net/ROM's connection handling in this case reduced the
> reliability?  I realise the network layout was less than ideal but I
> thought the whole point of Net/ROM L4 was it did ARQ at each hop so that
> the far ends didn't have to.

I may be recalling a flawed memory, but it didn't work anything like
today's IP routers.  Again, I don't know how much of that was due to the
algorithm and how much of that was due to leaving the settings at
default values when things possibly could have been improved
considerably with more educated selection of settings.

> I've been doing some research on the topic though: my thinking is that
> AX.25 isn't much different to today's wireless sensor networks.  These
> tend to avoid "connected-mode" type links in favour of connection-less
> messaging.
> 
> So 6LoWPAN uses mostly UDP over IP, Zigbee is more data-oriented, so in
> its original form uses key-value pairs, but more generically can pass
> around abstract messages.  I'm not sure what LoRAWAN does.
> 
> I'm thinking the same sorts of protocols that run happily over 6LoWPAN
> would work here too.  Most of the applications I'm thinking of are
> one-to-many, and having it just go direct to the nodes instead of via
> some central hub (message broker, BBS, etc) fits more with the
> decentralised ethos of amateur radio.
> 
> A central hub is handy for storing messages, but it can also be a point
> of failure. :-)
> 
> That said, it's interesting to hear the war stories, as I was too young
> when much of this stuff is popular.  If we don't learn from history,
> we're bound to repeat its mistakes.

I see some good ideas, Stuart, even though I'm not familiar with the
protocols you mention.

I'm not sure if the regulations have been changed, but at one time, in
the USA, at least, AX.25 was a requirement for the link layer of amateur
radio data networks.  This is why previous implementations of TCP/IP of
Net and NOS and the Linux kernel stack all run on top of AX.25.

Anyway, good luck and have fun!

73, Nate

-- 

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

Web: http://www.n0nb.us  GPG key: D55A8819  GitHub: N0NB

Attachment: signature.asc
Description: PGP signature

Reply via email to