[nos-bbs] use of SSID

[Barry Siegfried]

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

> the "initial packet delivered to the BBS" is well exampled in my
> neighborhood by various sites with jnos.  In addition, I seem to
> recall several occurrences of this detail on this reflector...
>
> Clearly - I have disadvantaged the AX.25 BBS user by my choice of a
> single SSID for my configuration.  On my site the *blank* needs to
> be sent after the "CONNECTED" message per your note.  At this moment
> I have not fully defined the problem thus I will not adopt multiple
> SSID as a solution *yet*... Perhaps multiple SSID is a solution, or
> perhaps it is a work-around waiting for a more elegant solution?

[snip]

> I find it interesting that jnos can differentiate NET-ROM and TCP/IP
> but not "vanilla" at connect time.  This is perhaps one of those
> classic examples of comparing apples and oranges for differences.
> The BBS is a server function whereas NET-ROM and TCP/IP act more as
> communication "paths" between nodes.
>
> Before I leave this subject behind I feel the need to dig into the
> detail - and document the consequences of the choice (or oversight).

Please forgive me but I have some things to say about this subject.
Do NOT blame JNOS for the conclusion you have drawn by your observations
that it "can differentiate NET-ROM and TCP/IP but not 'vanilla' at
connect time".  This one statement and the two that follow it need
some commenting about.  Hopefully you will find this to provide the
"detail" for which you are searching.

First and foremost, it's apples, oranges *and* peaches.  And they're
all related fruits.  AX.25, Net/Rom and TCP/IP define handshaking
protocols (i.e. conversation "rules") and they *each* serve as
communication "paths" which may be used to connect a client machine
to a server machine for the purpose of delivering a single application
from the server to the client.  This model is called "peering" and it
exists for all three protocols above.

Any machine that runs applications, e.g. PBBS (the JNOS mailbox),
TTYlink (keyboard to keyboard), Convers (IRC for hams), FTP, POPmail
and SMTP to name a few of the more popular ones defines a "server".
Any machine that connects to any application on a server for the
purposes of using that application defines a client.  This is
completely without regard to the connecting "protocol" that is used
as described in the paragraph above (AX.25, Net/Rom or TCP/IP).
And as we already know, JNOS has support for several protocol paths
to access its applications.  Using the examples above:

PBBS - may be accessed via AX.25, Net/Rom and TCP/IP
TTYlink - may be accessed via AX.25, Net/Rom (I think) and TCP/IP
Convers - may be accessed via AX.25, Net/Rom (I think) and TCP/IP
FTP - may be accessed via TCP/IP only
POPmail - may be accessed via TCP/IP only
SMTP - may be accessed via TCP/IP only

You get the idea, I'm sure.

Now each time a connection is made to a server a socket (data pipe)
is assigned by the software which logically links the connecting
protocol (AX.25, Net/Rom L4 or TCP) to the application and a new
process is spawned which delivers application output from the server
to the client and application input from the client to the server.
But what about the layers beneath the application itself which
actually move the packets between the machines.  Well now let's
see, we have AX.25 (apples), Net/Rom (oranges) and TCP/IP (peaches)
and they each provide the same functions with respect to the
applications in the machine.  Let's examine each of them:

TCP/IP implements level 4 (transport) and level 3 (network) layers.
IP provides the network routing and TCP, which rides underneath IP,
provides the end-to-end transport reliablity.  TCP/IP can ride
underneath any level 2 (link) layer protocol that has been programmed
to carry it, the most popular being ethernet and AX.25 and yes,
even Net/Rom layer 3.

Net/Rom implements level 4 (transport) and level 3 (network) layers
as well.  It provides both network routing and end-to-end transport
reliability and the level 3 part of Net/Rom can exist without the
level 4 part (but obviously, not vice versa).  Net/Rom can ride
underneath any level 2 (link) layer protocol that has been programmed
to carry it, the most popular being AX.25.

AX.25 implements th level 2 (link) layer, just like ethernet.  It
can carry packets which contain higher layer protocols and this is
something that JNOS does very well.  But wait!  AX.25 can ALSO carry
application data (what you refer to as "vanilla" above) directly
between peers (clients and servers)!

How is this possible?  Doesn't it break the model?  You bet it does!

Using the "layered" digital communications model, shouldn't application
data be carried in frames which have more sophisticated handling in
them that provide link (physical packet addressing between machines
on the same medium), network (network packet addressing and routing
between mediums) and transport (Acks for end-to-end packet delivery
reliablity)?  Well, yes they should!

Yet... AX.25 can serve this "double duty" of sorts.  It's both a link
layer to carry higher layer frames AND it can directly carry application
data.  How then, does a machine know what to do with an AX.25 frame?

Good question.  I'm glad you asked it.  Before I get into that, here
is some history:

AX.25 was, to put it in very simple terms, originally deployed
incorrectly!  With the effort by hams in the late 1970s to quickly
get AX.25 running, it was originally designed without any thought
whatsoever to higher layers of the communications model (other than
a process ID byte was included in the AX.25 header) and it was
utilized to carry keyboard-to-keyboard "user" or "application" data
between peers on the same medium.  Period.  AX.25 should have been
designed as strictly a link protocol (like an ethernet of sorts for
RF) and then utilized as such to support a true layered model
underneath it, but the hams were too anxious to get it up and
running and because of that, this is now what we're stuck with
today.

So, we see now that AX.25 must be a bit of a "jack of all trades"
then and when it carries "vanilla" application frames with user
data in them (pid=TEXT), it is cramming all the functions of
link/network/transport into a single and simple addressing protocol
between machines on the same medium.  And THAT'S the problem.  It
was never designed to be anything more than a way to move packets
between machines on the same medium.  As usual, the hams wanted to
have their cake and also get immediate gratification from eating it.

The proper way to have deployed AX.25 would have been to use it
strictly as a link addressing protocol for RF, similar to today's
802.11 (ethernet) for wire, where your callsign/ssid is the link
identifier, and a layered protocol starting with something like IP
(or level 3 Net/Rom) would network packets between mediums underneath
it.

In the early 1980s while KA9Q was thinking about writing software
to *network* AX.25 with TCP/IP (which was a standard that already
existed in the wired world) on a DOS platform, the Net/Rom boys
developed Net/Rom L3 and L4 to provide networking and end-to-end
transport reliability specifically for use underneath AX.25 and
to use in a TNC.  This was, of course, a laudible goal because it
extended the "reach" of AX.25 to work between mediums (through
"nodes", which are the Net/Rom equivalent of routers in the IP
world)!  So, what you have now learned is that Net/Rom actually
provides the exact same functionality that TCP/IP does, only it
isn't quite as sophisticated with the TCP sliding windows, etc.

But back to JNOS.  KA9Q invented NET (which became NOS) to ride
TCP/IP underneath AX.25 and then in 1989, W9NK added Net/Rom support.
THAT is when NOS really became popular.  G1EMM then started making
his own tweaks to NOS to make it "better" and after that, WG7J took
over G1EMM's work and his "brand" of NOS became JNOS.  And JNOS,
like any good NOS, attempts to support AX.25, Net/Rom and TCP/IP
and have AX.25 do its usual "double-duty", which is by no means
an easy feat implement!  But I digress.

Back to our "problem" of JNOS being able to "differentiate NET-ROM
and TCP/IP but not 'vanilla' at connect time".  When packeteers
realized that they had to press the return key (i.e. send an empty
packet) to get the application going when they would connect to
a server's PBBS via AX.25 not only didn't they understand why
this was necessary, but they next did what they do best... complain
to the software developer.  So WG7J pondered this issue a LOT.  He
decided that he would make use of the famous "(AX.25 IP) mode" of
an interface to determine whether or not he could "jumpstart" (i.e.
automatically start) an application.  Here was the algorithm:

1) If the IP mode of the AX.25 channel is "datagram" AND the
interface is NOT enabled for Net/Rom, then that means unconnected
UI (unnumbered information) frames are being used to carry IP
(resulting in less overhead and less reliability) so that when
an AX.25 connection (using I frames) arrives at this machine it
can be presumed that the user was a "vanilla" (i.e. non-TCP/IP)
guy and JNOS could be programmed to "jumpstart" the PBBS (mailbox).
The "vanilla" guys loved that.

2) But... if the IP mode of the AX.25 channel is "virtual circuit"
OR the interface is enabled for Net/Rom then that means I (information)
frames are being used to either carry IP or Net/Rom (resulting in more
overhead and more reliability) so that when an AX.25 connection (using
I frames) arrives at this machine it can NOT be presumed that the user
was a "vanilla" guy and JNOS would be programmed to require a keypress
by the user in order to get the PBBS (mailbox) started.

How else can the software possibly know what an AX.25 connection is
carrying if:  1) the AX.25 (IP) mode is virtual circuit, or, 2) the
interface is enabled for Net/Rom?  It can't.

So, a sysop had a choice.  He could either require the use a less-
reliable datagram mode of transmission for IP and NOT use Net/Rom at
all so AX.25 vanilla users could get JNOS mailboxes automatically
jumpstarted, or, he could require the use of a more-reliable virtual
circuit mode of transmission for IP or Net/Rom so AX.25 vanilla users
would be required to send an empty packet to get a JNOS mailbox to
start.

Not much of a choice, eh?  Also, the packeteers didn't understand this
concept about higher layers, yada yada, etc. etc. and they still
complained that they had to send an empty packet to get a JNOS mailbox
going.  Sooooo... WG7J invented the "bbs callsign".  This was the
callsign that would ALWAYS jumpstart the PBBS no matter who connects
to it.  Problem solved.

And then later, this was expanded to include special callsigns (normally
using different SSIDs) for various other services as well, like for
Convers and TTYlink and who knows what else.  Heck, if you look at the
SSID like a TCP port, you can have 15 different applications in a NOS
program jumpstart to "vanilla" AX.25 guys if you want.  Why not 16?
Well... you probably want to leave *one* SSID available to carry higher
layer protocols.

Otherwise, why bother using JNOS?

Does the above make anything clearer for you?

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