HB3NOS is based on Jnos 2.0 (c) Maiko Langelaar, running on a Raspberry PI 3+ with Rasbian v4.1.6-v7. The Jnos server version that is running as part of HB1BBS services is modified on many aspects. I am working on making my own releases for personal use based on the previous works of many people, most notable are *Phil Karn (KA9Q), Johan Reinalda (WG7J), Gerard van der Grinten (PA0GRI), *Anders Klemets (SM0RGV), Kevin Hill (G1EMM), James Dugal (N5KNX), Brandon *Allbery (KF8NH), Barry Siegfried (K2MF) and Brian Lantz (KO4KS). All Jnos 2.0 additions, enhancements, extensions, code restructuring, fixes are Copyright (C) 2004-2019 by Maiko Langelaar [VE4KLM]
We are running the latest version v2.0m.5G (02-04-2012)
Well, quite simply, JNOS is the "Swiss Army Knife" of Packet Radioi!!! Because it can do just about anything. It's a TCP/IP router, firewall, BBS, SMTP/FTP/WEB server, and talks AX.25, NetROM, and TCP/IP protocols. And it does APRS and WINLINK. Jnos is an "Operating System" *NOT* an Application. It acts as a Digipeater and/or a cross-band Digipeater. You can uplink and downlink with it using plain old AX.25 It contains a BBS "Bulletin Board System" It can have any number of radio ports It can act as a File Server (using the "Upload" and "Download" BBS commands, of FTP) It supports the complete TCP/IP protocol suite (Telnet, Finger, FTP, Ping, ARP, SMTP email, POP3 for Email, HTTP web, and anything than will run atop IP) It supports an Ethernet port(s) and can be connected to your LAN or to the Internet It supports NetROM/Knet protocol and can link with NetROM nodes/networks It supports AXUDP links to other systems (such as BPQ nodes) It supports a WINLINK interface to exchange Email with that network. It can be an APRS Digi as well as an Igate. It supports RLI/FBB "Heirarchical" email forwarding. It supports a Network-Wide CONVerse Bridge that supports over 32,000 individual CHAT channels (911 for Emergencies, 411 for Weather events, individual County channels (81), individual District channels (222), and even links to bridges throughout the World) It supports TCP/IP over the top of the AX.25 Link Layer protocol. It supports TCP/IP over the top of the NetROM networks. It supports TCP/IP routing using conventional "ifconfig" and "route" commands It supports IPIP ENCAP (Protocol-4) for easy linking across non-Amateur networks such as the Internet or microwave/mesh networks. It contains IP ACCESS and TCP ACCESS firewall. It has built-in detailed HELP files SMTP Email can have multiple recipients SMTP Email can have MIME Attachements It has very robust daily Logging of all logins, actions, logout, and SMTP/FTP transactions. It has Remote management access and rebooting capability. It supports SNMP network management and monitoring tools. And it can be configured to do ALL OF THE ABOVE at the same time! Have I missed anything?
Langelaar.net (release history)
Apr 2021 - version 2.0m.5G
1) Basic DNS malformed packet protection, better error checks and logging, bumped up stack size of DNS procs, this fix alone will add significant stability to people reporting JNOS crashing (from DNS attacks).
2) Got a few reports of longer hex values showing up when running the console commands like 'ax25 status', 'tcp status', 'netrom status', however when it was required to 'kick' or 'reset' by hex value, JNOS would report the call back as not valid, preventing people from being able to do such things. The fix was fairly easy, replacing htoi() calls with htol() instead.
3) Robust Packet Interface (KISS over TCP/IP) to WinRPR Modem
4) VARA IP Bridge Interface (TCP/IP) to EA5HVK VARA Software Modem As documented, you need to extract the source from varadev.tar. This is because the current vara code hardcodes some things in PPP source which I have not finalized at release time. Applying the VARA source will break any serial PPP configurations you may have running. Chances are nobody is using PPP with JNOS anymore, but I need to be sure :]
5) This update sees the addition of DUPE protection for concurrent forwarding sessions from multiple remote hosts, where messages having the same BID are coming in from multiple sources, seconds of each other, even within minutes of each other in some cases. It should be noted that up till now, JNOS has always been vunerable to this, resulting in posting of duplicate messages, which in turn get forwarded to other systems, which is just not good. The solution up till now has been to stagger forwards with remote partners, such that only one partner is forwarding at any particular time. With this new feature, we can loosen things up a bit more, and not worry about it. Excess messages get deferred (not refused), since we might need them later.
6) The BID for messages from 'our host' is now in BASE36 format, giving us a much bigger range of several million numbers, instead of the original range of 99999 and then start over again. If you use an email client (like thunderbird) to send messages to your JNOS system, you'll notice this version no longer uses a portion of the long message-id present in the email header to generate the BID, rather it will just create another BASE36 BID from JNOS sequence number pool. I figure it is perfectly fine to do this now, since BASE36 extends the range of the BID to several million. The original message-id is still preserved in the message header anyways, so nothing is lost here.
7) Protection from getting 2 UA frames after we send a SABM frame, resulting in a terribly vicious loop, like a DOS attack, rare scenario encountered, some time ago, where the remote software (based on linux ax25 stack) went nuts on some of us. Possible ax25 libs were updated, but the software on the other end not compiled in a long time and running old libs ? We will never know to be honest, but the situation was very real, yup.
8) Very basic implementation of Multi Factor Authentication (MFA) why not ? (note this is very much a prototype, and needs to evolve over time)
9) Important changes to the JNOS httpvnc (web based user BBS) service. Now using POST instead of GET in the form submission, so you won't be seeing any user credentials and commands in the URL anywmore, it's all hidden in the message body now. The original version had user callsign and password exposed in the URL which was just bad, but my knowledge of HTTP programming was quite limited at the time I wrote the original prototype, so really it is a huge security improvment. NOTE : Data is still cleartext over your network since this is HTTP ... This version also quickly shuts down those annoying and bandwidth consuming favicon http requests that firefox likes to send out in huge volumes, yeah. Added a CTRL-A checkbox so a user can abort any SEND (SP, SR, SB) commands. Made adjustments to timeout values in the code, removed some pwait() calls which didn't seem necessary anymore, and now setting the 'Server:' field in the HTTP response header to reflect the more recent JNOS version 2.0m ... Cleaned up debugging and general logging to the JNOS logfile.
10) Important changes to the SID Capture feature. The original prototype was written more to help me debug stuff at the time, but I figured it might come in handy for others, but the last enhancements actually were not really great. In the interest of getting more information about the hosts connecting to us, the focus on the connecting callsign was lost, the information displayed was confusing, you had no idea who the call was in many cases, and it turns out in the end that I introduced bugs into the code, so the information at times was even wrong here and there. This new version has a much better user friendly layout, being more in line with what I originally wanted to do way back then. Now you get the callsign, the time of connect, the full SID sent to us, and connection details, as in was this a netrom connect, a radio port, a wormhole, telnet connect, etc ?
11) Security - make sure you configure users in ftpusers with BBS permissions only for stations you have authorized incoming forwarding with. This will protect against rogue or ignorant incoming connects from any stations who could then proceed to send a SID, possibly followed by illegal 3rd party forwarding or forwarding of malicious messages. for BBS permissions OR 0x02000 - so 0x0407f in ftpusers becomes 0x0607f Up till now, JNOS has always allowed this, but now JNOS will send a terse message to the 'offending' station first, instead of the SID, disrupting the message flow - it might require some refinement, let me know please. These events are also logged to the JNOS logfile. IF this feature causes you grief, then disable it in config.h with : #define J2_DONT_ENFORCE_BBS_USER
12) Added EHLO support to SMTP server. I discovered this by accident when my android email app refused to talk to my JNOS, so tcpdump showed me exactly the problem, easy enough to add the command. Quite honestly, I thought it was there already, oops
13) Instead of hardcoding NETROM parameters, I know several folks have had it done, please consider using the following NEW commands in autoexec.nos : netrom obsoinit <value> default is 6, for NEDA use 5 netrom obsominbc <value> default is 5, for NEDA use 3 Same with acktime, use the EXISTING command instead of hardcoding it : netrom acktime <value> default is 3000, for NEDA
14) Couple of 'stability' mods to netrom code.
15) Better error logging during saving of the BID to the history file.
16) Removed first column (gateway ip address) from the 'genencaptxt' file. (now it matches the exact same format as a real encap.txt)
17) If you are running two systems with the same Call Sign please consider staggering your sequence numbers, since the sequence number pool is now into the several million range, not constrained to the old 1 to 99999 and back. For example, in my /jnos/spool/mqueue/sequence.seq, I reset the value to 16801420, which starts my base36 bid at ANNNN, way ahead. If anyone sees a flaw in this, please talk to me :] Not so sure one should be running multi BBS with same callsigns, but ...
18) Some tweaks to APRS code, for instance making sure to remove trailing 0xc0 characters from the end of APRS data coming in via a WinRPR interface, and also breaking out callsign list management routines - which are no longer specific to the APRS aspect of JNOS, also used for IP access and Winlink call lists, so they got moved to the new j2KLMlists.[ch] source files.
19) Fixed some more compiler and linker warnings, some dependant on how one modified their config.h file - originally these never would have showed for the more standard configurations (if there is such a thing). I also added some TNODE 'mods' from Brian (N1URO).
20) Important for ARM processors, the makefile now FORCES signed char, the reason being the linux version of JNOS always assumed signed char, but this is a big problem for ARM and Raspberry PI based hardware, which actually assumes unsigned char intead - more efficient apparently. So BEFORE this got enforced, PI users were complaining about all sorts of strange behavior with JNOS and/or outright continuous crashing ...
Dec 2020 - version 2.0m.5F
This is basically version 2.0m.5E, but 'cleaned up' ... Defines I had hardcoded in makefile have been moved out, so users can now do it properly in their config.h file. Working on more compiler warnings. Once this is all done, all the patch files will be stowed away again, and 2.0m.5F will become the next official version, it's been a while. Also working on recent j2addendum documentation as time permits.
Nov 2020 - version 2.0m.5E
An implementation of Multi Factor Authentication (MFA) for JNOS 2.0 - why not ? Check rsync area for a new 'update_jnos.2.0m.5E.tar.gz' file. Please refer to the following URL for complete usage instructions : https://www.langelaar.net/jnos2/documents/working.txt This is an edit of some documentation I started last summer.
Nov 2020 - version 2.0m.5D
These are refinements to the 2.0m.5C patch, but technically we need to change the version number to reflect this, a new 'update_jnos.2.0m.5D.tar.gz' file.
1) Robust Packet Interface (KISS over TCP/IP) to WinRPR Software
2) Changes to the JNOS httpvnc (web based user BBS) service
3) Important changes to the SID Capture feature.
4) Removed first column (gateway ip) from the 'genencaptxt' file.
5) BIG OOPS - Brian (N1URO) had some TNODE mods that were supposed to be part of the version 2.0m.5 update, but I just discovered they were never put in, even though I had mentioned '#define TNODE' if you want those mods in play. I have made sure to add the source files to this latest update - sorry about that.
Nov 2020 - version 2.0m.5C
definements to the 2.0m.5B patch, but technically we need to change the version number to reflect this, a new 'update_jnos.2.0m.5C.tar.gz' file.
1) WARNING : Make sure you configure users in ftpusers with BBS permissions only for stations you have authorized incoming forwarding with. This will protect against rogue or ignorant incoming connects from any stations who could then proceed to send a SID, possibly followed by illegal 3rd party forwarding or forwarding of malicious messages. for BBS permissions OR 0x02000 - so 0x0407f in ftpusers becomes 0x0607f Up till now, JNOS has always allowed this, but now JNOS will send a terse message to the 'offending' station first, instead of the SID, disrupting the message flow - it might require some refinement, let me know please. These events are logged to the JNOS logfile.
2) Couple of mods to the DUPE control code, see the README.
3) Added EHLO support to SMTP server.
I discovered this by accident when my android email app refused to talk to my JNOS, so tcpdump showed me exactly the problem, easy enough to add the command. Quite honestly, thought it was there already, oops :|
4) Couple of 'stability' mods to netrom code, see the README.
Oct 2020 - version 2.0m.5B
1) The BID for messages from 'our host' is now in BASE36 format.
2) This update sees the addition of DUPE protection for concurrent forwarding sessions from multiple remote hosts, where messages having the same BID are coming in from multiple sources, seconds of each other, even within minutes of each other in some cases. It should be noted that up till now, JNOS has always been vunerable to this, resulting in posting of duplicate messages, which in turn get forwarded to other systems, which is just not good. The solution up till now has been to stagger forwards with remote partners, such that only one partner is forwarding at any particular time. With this new feature, we can loosen things up a bit more, and not worry about it. Still debating whether to defer (instead of refuse) the excess messages ...
3) Better error logging during saving of the BID to the history file.
4) Instead of hardcoding NETROM parameters, I know several folks have had it done, please consider using the following NEW commands in autoexec.nos : netrom obsoinit <value> default is 6, for NEDA use 5 netrom obsominbc <value> default is 5, for NEDA use 3 Same with acktime, use the EXISTING command instead of hardcoding it : netrom acktime <value> default is 3000, for NEDA (?) 5) If you want to use Brian's (N1URO) mods for TNODE, then define TNODE in your config. h or in your makefile before you compile your code.
6) If you are running two systems with the same Call Sign Please consider staggering your sequence numbers, since the sequence number pool is now into the several million range, not constrained to the old 1 to 99999 and back. For example, in my /jnos/spool/mqueue/sequence.seq,
I reset the value to 16801420, which starts my base36 bid at ANNNN, way ahead. If anyone sees a flaw in this, please talk to me :] Not so sure one should be running multi BBS with same callsigns.
May 2020 - perhaps 2.0n was an exercise in getting 'carried away' ?(read the release history please for an update)
Apr 2020 - sanity check, emailed my Winlink account from outside, still able to pick off my messages from the Winlink CMS server using JNOS.
Mar 2020 - The source is available on my github account again
Feb 2020 - What started off as version 2.0m.1 has now been released as version 2.0n.beta - radical changes to password management, so I had no choice but to change the version MAJOR. Been playing with the SCS PTC-IIusb modem again, HF conditions not great.
Oct 2019 - New version 2.0m (beta) - read the release hisstory for details.
Aug 2019 - Now able to accept packet connections from Winlink (RMS) Express clients, and go direct to CMS servers, just like an RMS node. I just need to cleanup the code before I release any updates.
Jul 2019 - Very excited about a couple of things, first off, rediscovered the software combo of Paxon and PC/Flexnet32, still works in Windows 7 and it's been 15 years ? Excellent for an AXUDP packet terminal !
Now have base infrastructure in place to support packet connections from Winlink (RMS) Express clients and go direct to CMS servers. I was asked to support this, so making some good progress on it.
Mar 2019 - Been working on a new xterm based session manager as an alternative to ncurses. A previous maintainer of JNOS actually has it listed in the code as something they wanted to do years ago. I have made some progress, but ran into a major snag, and quite honestly ? I am not so sure I like the idea anymore, so giving it a break for a while.
Jnos on Raspberry Pi
If you desire to run JNOS on a Raspberry Pi, Jim Smith N8AVX has produced this excellent HOWTO that walks you through the entire process, step-by-step, to having a running JNOS application running on a Pi.
You start with a Pi with the Linux OS already loaded, follow these steps, and you will have a (minimal - autoexec.nos and a couple support files will need additional configuration) JNOS that can talk through either a USB or Serial port to your KISS TNC. Enjoy!!!
HOWTO-JNOS-on-Pi3-v4.3.pdf 1,2 Mb
The following files will need to be edited and configured for your JNOS station to operate properly. Each of these Example files contain a working configuration and contain instructions how to edit each section to customize the config for your particular station.
1) AUTOEXEC.NOS /jnos
This is the main configuration file. This is where we set the CALLSIGN, Hostname, IP Address, any SSID assignments, Aliases, and enable the services.
2) FTPUSERS /jnos
This is a Password file. Here we create special priviledged accounts such as the root administration (those that can access special mainenance functions), and the UNIVPERM account which determines what services anyone without a specific account can do on the system. This file also determines who is a BBS and who is a human user. Change " /jnos 0x4407f" to reflect your callsign and your password. This account can use the "@" command to log into the JNOS Shell at the /jnos directory. From there this user can issue JNOS commands to change routes, clear mail queues, etc.
3) DOMAIN.TXT /jnos
This is the DNS CACHE file. All DNS lookups get stored here. However, certain entries need to be made here so that a new JNOS node does not have "amnesia". A node *MUST KNOW* its own Hostname and IP Address in this file so that it can identify itself (oftentimes a problem when attempting to send SMTP email to a user on the box). Change the "YOUR-HOSTNAME-HERE.ampr.org." to reflect your Hostname or callsign. Change the "44.102.x.y" to match your IP address.
YOUR-HOSTNAME-HERE.ampr.org. 0 IN A 44.102.x.y
(helps with amnesia)
5) LOCAL.RTE /jnos
This is the static route table. Here we define the DEFAULT route and any SUBNET routes and which Interfaces traffic to them will be routed. Change all SUBNET and INTERFACES to match your system.
6) INFO.HLP /jnos/spool/help/
This file contains the text that will be delivered to a user who types "I"nfo on the command line. This file SHOULD be brief but explain what and where this JNOS box is located. Adjust the text as you feel meets your needs.
7) AREAS /jnos/spool/
This file contains the mail area groups and are configurated in the rewrite file
8) REWRITE /jnos/spool/
The rewrite file is used to perform a one-to-one mapping between destination addresses as received by NOS and destination addresses as actually used by NOS. Each record within the rewrite file comprises a single line, containing either two or three entries separated by spaces. The first field is the template field; if a destination address matches the template, it is replaced by the second field. The third field, which is optional, is the single letter "r", which, if present, tells NOS to rescan the rewrite file, using the new destination address to attempt to match against the templates.
So Jnos is still being developed, and is a complex TCP/IP packet program with lots of possibilities. Below are some items that deal with some of the possibilities.