 John Martins' |
|
Whetting your feet with Jnos…
By John
Martin KF8KK
for original presentation to the MI ARPSC D7 EC’s
Some Background…
While Jno
For those familiar with
command line Unix, Jnos is a
piece of cake. The rest of us may have
trouble making full use of this ‘swiss army knife’
and settle for just a few of the possible uses that Jnos
can be used for.
Thankfully, there’s a guy in
For most of the packet
networking tools, it’s sad that ‘software maintenance’ is rare or has
ceased. The brightest minds who developed our packet networking infrastructure during
the 1980’s have gone onto other things.
We are very fortunate to have current progress in the world of Jnos, thanks to Maiko.
Jnos is based on the ‘Network Operating System’ [NOS]
written by KA9Q back in the late 80’s.
This is the time when IBM8088 XT computers were all the rage, the
Commodore VIC-20 and C64 were popular, etc.
At that time, if you wanted
to network your [IBM] PC you had to buy expensive networking software. The original KA9Q ‘NOS’ (some referred to it
as ‘net’) was revolutionary in that for the first time hams could experiment
with using the burgeoning internet protocols of TCP/IP and UDP/IP over packet
radio. The fact that the software would
also act as a gateway to an Ethernet LAN was missed by most hams at the time
since very few had the rare and expensive networking cards for their computers
(A 3com netcard might command near $500 back then).
In the early days, all of
the NOS derivatives (this includes KA9Q, and the later JNOS, XNOS, MFNOS, TNOS, etc) were
written exclusively to run on DOS PC’s.
This meant they were limited in program size to fit within the 640k
memory limitations imposed on all DOS run programs. Thankfully, Jnos
has been ported over to run on Linux and avail itself of the more modern RAM
available, and make use of commonly available networking devices.
The program was mostly
written before the days of the graphical user interface, where anyone who used
a computer was familiar with entering command line text commands. The authors of the ‘noss-es’
were particularly familiar with unix commands, since the
internet was almost universally accessed using computers running various
versions of the Unix operating system.
This carries forth into the Jnos that we use
today, and is mostly responsible for why it seems rather cryptic by our current
standards.
What does Jnos
bring to the table?
Jnos can be viewed as primarily a network and protocol
gateway device with a ‘bbs style’ mailbox and mail
forwarding capability. Jnos also provides functionality as both a file server, a
Telnet gateway, and a linkable conference server.
Network/Protocol Gateway…
Jnos can communicate via multiple paths if desired. You can install as many TNC’s
as you can physically wire into your PC.
You can also install multiple Ethernet network cards, and multiple
modems if your needs require this.
Jnos can communicate via these ports using not only
regular AX.25 packet protocol, but it can use the internet/Ethernet TCP/IP (and
UDP/IP) protocols. Jnos
is not limited to just those protocols. Jnos can communicate using the NetRom
‘ISO Layer 3’ protocol,
PPP (point-to-point protocol), and SLIP (serial line interface
protocol). Sadly, they left out IPX/SPX
(Novell Netware), Appletalk, and Arcnet---
but, perhaps it’s just as well.
The ability to speak in
these different protocols makes the system most useful in the EmComm arena as it allows us to utilize the high speed
internet where available, and the slower speed RF packet systems where needed.
Through Jnos
and TheNet X1J nodes, actual TCP/IP packets can be
transmitted across the ham radio RF and easily pass through a Jnos gateway to the internet. While the use of TCP/IP over the radio is
currently a rarity, the ability to do so opens up another potential avenue we
can use to assist the served agencies.
The TCP/IP over RF that I am talking about is just the same TCP/IP
that’s on the internet, or in a typical LAN.
The only difference is the speed.
Jnos BBS Mailbox
Jnos was not written from the start to be a full featured
BBS like Msys or FBB, so when you compare it’s BBS features it comes up a tad short.
On the other hand, Jnos does provide basic mail handling and forwarding. Of course, like the other BBS systems, the
system operator has to manually setup the forwarding configuration for
forwarding to occur. Few Jnos operators currently in
Jnos makes it easy to send email to local users, or to anyone over the internet. Simply put the persons callsign, or an
internet email address after the ‘S’ in the send message command and Jnos will act accordingly.
Recently, a feature was
added to Jnos (still under development) that allows for the Jnos BBS to send and
receive emails via the Winlink2000 system.
This shows great promise as being a real boon to Jnos
users as currently they cannot receive email replies from the internet. Nearly all Jnos
system operators disable inbound email due to the avalanche of spam that
quickly appears if they open up their server for that. Internet email via Winlink2000 is likely to
be the future of Jnos internet email, at least for
inbound email (outbound
can still go whichever way it can).
Jnos stores messages in ‘areas’. Each user has an area assigned to their
callsign. The system operator can create
special areas of the BBS to store messages pertaining to specialized topics. By way of these ‘areas’, the Jnos BBS can be used to store pertinent information in a
manner that can be logically sorted and retrieved by users without having to
wade through every message on the system.
Jnos as a file server..
Jnos also allows for users to download and upload files
to the hard drive of the server. This
can be done via commands within the BBS, or via
regular internet FTP via the TCP/IP protocol from either the internet, or
stations running TCP/IP over RF.
The Jnos
FTP server has the same functionality of most other commonly used FTP
servers.
The only caveat in using the
Jnos server for downloading/uploading files is that
if used via the RF, the time it takes to transfer a file at 1200 baud can be
daunting unless the file is rather small.
The file server method of
storing information on the Jnos server is an
alternate to storing the information as messages in one of the sectioned
‘areas’ of the BBS.
Jnos as a Telnet Gateway
The Jnos
BBS also allows the user to gateway through the internet using the TELNET
command to remotely log onto other systems, ham radio or otherwise.
For those of us not familiar
with Telnet, it’s an internet protocol which allows you to log into a remote
computer and get their command prompt.
For most Jnos users, this allows you to log
into another Jnos system in some other area and get
access to that systems commands and RF ports just as if it was your local
system.
It is via this Telnet mode
that a user can easily setup a wormhole on demand to RF packet across the
state, nation, or even internationally.
A station can connect to their local Jnos node
via RF, Telnet to a distant jnos hamgate
and then connect out on RF from there.
Once the connection is made, their traffic will pass just like any other
packet connection.
The Jnos
Converse ‘chat room’ server…
On systems configured for
the Converse mode, users can enter into any of thousands of multi-user ‘chat
rooms’. These provide text chat much
like the common messenger programs popular on the internet currently. Jnos allows you to
connect these converse rooms together with those on other Jnos
systems. This networking of converse
servers can make the converse mode extremely useful during an event, allowing
not just for communications locally, but for regional and state authorities to
monitor the traffic and communicate when necessary.
In
By standardizing the
numbers, if an event were to happen in Leelanau and the state EOC wanted to
join in the local converse traffic of the event, they would know to go to
‘channel 45’.
Jnos as a NetRom node…
NetRom and TheNet (X1J) are what’s called ‘ISO Level 3 network nodes’, and are
operationally identical (so much so, the company that authored NetRom alleges copyright infringement by the freeware TheNet authors). I
will use the term ‘NetRom’, but only for
simplification, as ‘TheNet’ operates synonymously.
The term ISO Level 3 i
NetRom nodes broadcast the list of nodes that they
hear. These ‘node broadcasts’ are heard
by the other nodes and automatically routing tables are built by the
nodes.
In an area with multiple NetRom nodes, each node will present the user with the
nodes that are available by any of the NetRom nodes
in the area.
The user does not have to
know anything about how his data gets to any of the nodes,
the routing is done automatically by NetRom and often
traverses numerous nodes and gateways along the way.
An example would be the
occasional appearance of the SSM (VE3SSM in Sault St Marie) node in the 145.07
node broadcasts of BEN11 (wI0OK-7 in Empire).
A user can connect to the BEN11 node and then issue the ‘C SSM’ command
and eventually find themselves connected to the VE3SSM
station in the Soo.
The amazing thing that
the user would be unaware of is the path their packet took to get to the Soo. BEN11 would
connect via the serial port on it’s TNC to the BEN12 node which would then
transmit the packet on 433.125mhz to the KKBBS jnos
node, which would then gateway the packet out on 145.09 to VE3SSM! Yes, this does work, I’ve verified it—but
there must be band enhancement for SSM to reach Empire.
NetRoms ability to provide automatic packet routing enables
the system to provide much needed assistance to users who would otherwise have
difficulty in setting up a long or complicated route.
Theoretically, there is a
way to configure a Jnos hamgate
to share NetRom routes with another Jnos system via a tunnel across the internet. I have not verified this, as outside of D7W (northwest lower MI) the configuration of NetRom
by Jnos system operators is not yet a common reality. In time, this functionality may become real,
and then simple commands to a NetRom or Jnos node could connect you to packet anywhere across the
state, using RF when available, and Internet when not. I hope this is not a vaporware feature, as it
could be handy.
Jnos Extras…
In addition to the commonly
used features of Jnos above are the following (which
may or may not be configured on your local Jnos hamgate):
SMTP server….
This is the very same SMTP
server that you’ll recall when you setup your internet email. Microsoft Outlook or Outlook Express, or
similar internet email client programs can connect up to a Jnos
server for the sending of email. As
long as you have a TCP/IP path from your computer to the Jnos
server (either via the LAN or RF) you can send you email via jnos.
POP3 server…
Similar to the SMTP server,
the POP3 server will work just fine with your Microsoft Outlook email client
for your retrieval of mail from Jnos. Just like with SMTP, if you have a TCP/IP
path to the Jnos machine, you can retrieve your email
or packet mail for viewing in Outlook or any other internet email software.
Web server… (yea… plain old http!—view
with your web browser)
Jnos can be setup to serve up web pages! While Jnos does not
provide the capabilities to run CGI scripts, it can serve up pages via the LAN,
Internet or even RF to be viewed on your regular web browser.
Proxy server…
Jnos hamgates can be setup as
proxy servers, routing
TCP/IP packets destined for one port to another.
NNTP News Server or Reader
You can serve up newsgroups
to your area with your Jnos hamgate,
or download newsgroups and have them appear in your BBS as an ‘area’ so that
local users can view the messages.
APRS Igate…
The latest versions of Jnos (Jnos2 by VE4KLM) contain a mode where the Jnos hamgate can be setup to
gateway APRS data to and from the internet.
This mode can have some
interesting possible implementations dealing with possibly a gateway from the
regular packet side of Jnos to and from the ‘text
mode’ available to APRS users. Since
this mode is new, useful applications for it are still as yet developing. (possibly allowing a
regular packet equipped EOC to communicate to search and rescue APRS stations
without having to switch over to the APRS channel directly).
Conclusion…
Jnos is a very useful tool in packet networking. Sadly, it’s not a simple system to install and can test the
knowledge and patience of even third echelon IT professionals. Once properly configured, it is easy to see
how it has garnered the ‘Swiss Army Knife’ moniker, making it well worth the
effort to setup.
Finally, when it comes to
hooking up the TNC to the radio, please visit http://www.febo.com/packet/layer-one/
for some useful advice on setting up the audio for the best reliability and
packet connectivity.
Our Statewide Digital Radio
Group website is at:
http://www.mi-drg.org/ with plenty of information
available to view.
I’ve been keeping some
packet ramblings that might be useful at:
http://www.kf8kk.com/packet/packet.htm
Thanks and 73
John Martin KF8KK
ISO/OSI LAYERS and what they mean to you and me.
The International Standards
Organization, a group of really smart people, decided to define a ‘STACK’ of ‘LAYERS’
that would describe a very flexible system for computer networking and call it
the ‘Open Systems Interconnection’. [If you’ve ever heard
reference to a ‘TCP/IP stack’--- this is it!]
These layers allow data to
traverse a computer network in such a way that computer networking software was
modularized, allowing for sections of the standards to change without having to
toss out the whole system. Being the
rapid pace of networking advances over the past 30 years, this model has served
us all very well. Software authors can
concentrate on the special needs of one portion of the overall ultimate
networked system, without having to reinvent everything with each new software
product produced, or whenever a bug is fixed.
LAYER 1 ---- Physical
This is the physical network
card and wires in your wired Ethernet LAN.
It’s the radio and RF path in your wifi
LAN. It’s also your packet TNC, radio
and RF path in ham packet radio. Layer
1 deals with such things as the ‘MAC address’ of your
network card (that’s the unique factory-coded address of each individual
networking device). For hams, Layer 1 is
where your ham callsign is inserted into the system. For those watching TCP/IP in action, Layer 1 information
appears in the ARP (Address Resolution Protocol) tables. ARP tables correlate specific network devices
(be they network cards, wifi transceivers, or
individual hams) to Layer 2 or 3 addresses.
LAYER 2 ---- Data Link Level
This is where we first start
to see packets of data. Your standard
packet radio, AX.25 connection is considered ‘layer 2’ by the gurus (layer 1
being the physical gear associated with your callsign).
LAYER 3 ---- NETWORK level
This is where the IP in
TCP/IP comes in. It’s also where NetRom packets reside (NetRom
packets reside atop layer 2 AX.25 packets).
It is here where routing from one machine (or ‘node’ if you think of
each device on a network as a ‘node’) to another is performed. The
common ‘IP address’ (192.168.1.1, etc) resides at this level.
LAYER 4 --- TRANSPORT level
This is where the TCP or UDP
in TCP/IP comes in. [similarly the IPX in IPX/SPX for those familiar with
Novell Netware networking]. TCP and UDP
bring at their level items called ‘ports’.
Anyone who has gone through the hazing of setting up Echolink
through a router has seen ‘ports’. TCP
port 5200, and UDP ports 5199 and 5198 need to be
passed along to the particular computer running Echolink.
You can look at these
‘ports’ as if they were a socket panel on the side of your computer with
special sockets with unique pin configurations for each different type of
program your computer runs. A socket
with two vertical pins would connect to the email receiving program. A socket with three horizontal pins would
connect to your web browser. A socket with
sixteen oval pins (that’s socket 5200) is meant to connect to Echolink.
LAYER 5 --- SESSION level
This level is setup so that
if you have four web browser windows open at the same time, the data from each
particular web page can go to the desired browser window. It’s like having an automatic ‘cube tap’
available on that socket panel mentioned above in layer 4.
Of course, you can have
multiple sessions for any of the sockets.
LAYER 6 --- PRESENTATION level
This is the actual data as
it is piped into the back side of your actual software.
LAYER 7 --- APPLICATION level
This is the program that
generates or receives the data. It’s
‘Internet Explorer’ or ‘Outlook’. It’s
also the mailbox/bbs in Jnos,
or the ‘Yahoo Messenger’ program.
The way to look at it is much like what
happens when you place your hand written letter (layer 7)
into an envelope (layer
6), then place that
envelope in the mailbox (layer
5), then the postman
takes that letter and puts it into a big bin at the local post office (layer 4).
The letter then goes to a regional mail processing plant (layer 3) and gets routed across the country via
a USPS TRUCK (layer
2). The truck travels across the Interstate
Highway System (layer
1) and then reaches
the regional mail processing plant near the destination (layer 3) and then continues back UP through the
layers on the other side.
Useful links:
http://en.wikipedia.org/wiki/OSI_model
http://www.uwsg.iu.edu/usail/network/nfs/network_layers.html
http://www.uwsg.iu.edu/usail/network/nfs/network_layers.html
APPENDIX B:
NETROM/THENET the how and why to
bother.
The why…
Just like a Kantronics KA node, a NetRom node
will provide the packet connection with the more reliable ‘hop by hop
acknowledgements’ as opposed to the ‘end to end acknowledgements’ that’s used
when using the ‘digipeater’ mode in creating a long
distance packet connection.
While the documentation for
recent Kantronics TNC’s
describe a means to setup their KA nodes to use the Kantronics
‘K-net’ mode, which purports to provide node broadcasts that are similar to and
compatible with NetRom, I have not personally seen any KA nodes setup
in this manner. Hopefully, this
functionality can be verified and simple instructions on how to enable it made
available to our group. If this mode is
NOT in reality what the manual eludes it to be (and we’ve all come across vaporware at one time or
another), then NetRom
with it’s automatic routing features would be a
dramatic improvement over the Knet/KAnode systems.
Even with Knet functioning as it should (with NetRom
interoperability and automatic routing)
the ability of a TheNet X1J (NetRom)
node to route TCP/IP radio traffic through the node is a feature that could
prove invaluable as our packet network evolves.
With TCP/IP being routed
through the node, it is then possible for users and Jnos
hamgates to make use of RF paths to route certain
forms of data that would otherwise be limited to the internet side.
Of course, at present, the
use of TCP/IP over RF packet is almost nonexistent. The future, however, may be different as
software development for TCP/IP applications is quite active these days. How important this functionality is in a
particular area will vary.
The how…
The most popular way to
setup a NetRom node is really to setup a TheNet X1J node, which is the freeware functional
equivalent. I’m not certain if you
could still purchase a Software2000 created NetRom eprom.
TheNet (and NetRom) are pieces of
software that are placed onto an eprom
chip by an eprom ‘burner’ and then placed into a
‘TAPR TNC-2 or similar’ TNC in place of the factory eprom
program chip.
There are a couple of small
wire jumpers that need to be added to the TNC along with the chip swap. The modification is not difficult for
someone used to working with the innards of electronic gear, but it would be a
daunting task for someone without experience on the technical side.
The TNC’s
that are commonly used for making a TheNet node are:
PacComm Tiny2 (currently
available for sale by PacComm)
MFJ 1270 / 1270B / 1270C /
1274
TAPR TNC2
AEA PK96
PacComm Spirit2
TheNet information can be had at the following websites:
http://www.vectorbd.com/bfd/thenet/index.html
http://www.kf8kk.com/jnos-linux/thenet-ops-1.htm
remember---
GOOGLE is your friend!