Jnos 2.0

Application Services

PD1HBL-7 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 PD1HBL 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]

PD1HBL-7 Jnos server is running various services that are for internal use only. PD1HBL-7 can be connected through the 
PD1HBL-8 and PD1HBL-9 nodes (just type JNOS at the prompt)

• PD1HBL-6 - JNOS-BBS AX25/TCP Mailbox (JNOS 2.0o)
• PD1HBL-7 - JNOS-Node (JNOS 2.0o) 

What's happening? 

Langelaar.net (release history)

Match 3  2023 - The latest official release is now JNOS 2.0o
The BIG news is the introduction of IPV6 (native JNOS code) 

Differences between 2.0o.2 and 2.0o - April 5, 2023

1) Mostly work on IPV6 code, see README.ipv6 for latest details

2) I have put debugging into nr4subr.c, trying to nail down a really nasty situation, bug, not sure what to call it, gcc related ? no idea if that is true or not, hopefully JNOS logs will give some detail IF it happens on your system. JNOS will crash in the netrom code, and the bizarre thing is that the callback pointer is always 0x10000000 when it happens, yup.
[ REMOVED April 18 - was actually 'killing' use of NETROM ]

3) From Michael Ford (WZ0C), tested by him and Charles Hargrove (N2NOV) Encountering an issue where when receiving a large-ish bulletin over the Netrom4 path between two JNOS systems, after every NR4-window-size frames, the transfer would hang until the NR4-ack-timer timed out. It appears to be because the standard piggyback-ack mechanism does not kick in, in the one-way data transfer. Tried reducing the NR4-ack-timer to near zero as
a workaround, and while it worked, it didn't seem like a permanent fix. For something more workable, I implemented a counter of unacked NR4 rx frames, and whenever the counter reaches 4, it sends an ack. I have the NR4 window set to 10. Acking after every few packets is more efficient than after every one, doesn't impact the sender, and prevents timeout. I did some short research into more formal ack'ing algorithms but chose to go with a quick implementation rather than something more sophisticated. It may be worth making the "4" configurable.
(note to myself, not done yet) WARNING - netrom structure changes - mass recompile mandatory ! files modified by this patch : nr4timer.c nr4subr.c nr4.h nr4.c (the original ackissue.diff I got from WZ0C is also in the rsync area)

May 2022 - version 2.0n.dev
New features are detailed in the release history, but here are the instructions you will need to follow to incorporate smtp MIME support and snmpd mods :

cd < whatever your build directory is >
rsync -av www.langelaar.net::jnos2 .
# note a new version 2.0n.dev
cp hlrevamp2022/version.c .
cp hlrevamp2022/smtpserv.c .
# this kludge is only Charles, lowercase BID on SB fix ?
cp KLUDGE_CH_mboxmail.c mboxmail.c
cp hlrevamp2022/mailutil.h .
cp hlrevamp2022/j2base64.c .
cp hlrevamp2022/files.c .
# mods requested by Mark, but anyone can use these
cp hlrevamp2022/snmpd.c .
edit your existing makefile :

1) Look for the 'UNIX=' section, add j2base64.o as below :
j2tmpnam.o getusage.o j2KLMlists.o j2strings.o j2base36.o \
activeBID.o j2base64.o

2) Make sure you PATCHES section looks as below :
PATCHES = -fsigned-char -DKLM_MAILIT_MIMEAWARE
make clean
./configure
make

Nov 2021 - version 2.0m.5Gx (Apache Fixes)
Changes to Web Based User BBS interface
This now works with apache (mod_proxy module) to give you full protection of https during your web sessions with the JNOS httpvnc server. Download the latest 'bbs10000.c' source file from the official rsync site, then : Add the following directorive to your config.h : #define APACHE_MOD_PROXY_BBS10000

Then recompile as follows : rm bbs10000.o ; make
For the apache server side, add the following to your httpd.conf :
ProxyPass "/jnosbbs" "http://192.168.4.201:10000"
ProxyPassReverse "/jnosbbs" "http://192.168.4.201:10000"
You would place these inside of your *:443 virtual host definition, then restart your apache server - that's what I do on my systems anyways ... Then I can securely access my httpvnc sessions as follows : https://www.langelaar.net/jnosbbs

Jun 2021 - version 2.0m.5Gx (Fixes)
1) By request, NEW capability in the rewrite file. One can now have entries targeting (such a bad word) specific users / stations.
In other words one  can now add entries that apply to only a FROM <pattern> You can get the test code from the rsync area as follows : rsync -av www.langelaar.net::jnos2/newfiltercode 

2) nntpserv.c now contains the latest stability fixes AND to appease the NNTP police out there. JNOS is getting LOTS of flack due to a recent NNTP incident where internet grade foul language and some very inappropriate content was channeled into the packet network, so I have modified the code such that JNOS will only  allow connections to NNTP servers on the 44 network.  

3) Bob Bruninga WB4APR was kind enough to add an entry for 
the NOSaprs module of JNOS 2.0 to his 'tocall' list maintained at : http://aprs.org/aprs11/tocalls.txt NOSaprs is now 'assigned' APN2XX, with APZ200 noted as being used by older versions of JNOS. It's been quite some time since NOSaprs was introduced, so it's not really experimental anymore. Thank you Janusz HF1L (ex.SP1LOP) for suggesting this change. The APZ200 in aprs.h is now set to APN20H. IF you have routing for 'apz200', make sure you change the apz200 to  the new 'apn20h' AFTER you have the new source in place. YES, if you use NOSaprs to TX, use 'ax25 route' to set the APRS path, example :  # 30Dec2020, So K4KPN-10 will catch it and pass it on further ax25 route add apz200 rp0 WIDE1-1

4)  Stability fixes to NNTPSERV, test code -> nntpserv_stability_fix.c (copy to nntpserv.c, then 'make', feel free to send me JNOS logs) NOTE : only applies if you have #define NNTPS in your config.h

May 2021 - version 2.0m.5Gx (Fixes)
Fixed multipsk software modem driver as I did agwpe and winrpr.
Fixed 'endless sockets' bug in agwpe and winrpr software modem drivers, and put in 'backing off' of logged failed software modem connections.
Brand new 'date' command at JNOS console, updated reportRPR.nos script.  (previous version of script used 'sh date' which creates zombies)

Apr 2021- version 2.0m.5Gx
 1) ax25 heard has been 'revamped', new 'heard via digipeater' feature, so that you can actually see stations not directly heard, I created this due to my crazy obsession with Robust Packet lately and seeing all the APRS frames coming in on 30 meters, many via K4KPN-10, nice to know who else you can QSO with (indirectly), really liking this. The save/load functionality improved, you can specify save and load file now, and times are FINALLY accurate on load, this took a lot of effort, but worth it in the end I think. I have NOT included saving of the latest digipeater heard list (yet), that will be next time.

WARNING : the heard file from previous versions of JNOS will NOT work with this version, unless you modify the file, add a second time stamp to the first line of the file, indicating uptime of the previous JNOS at the time you saved the heard file.

To be honest ? I hated the introduction of the 'show' subcommand, so the original 'ax25 h <iface>' is back and will stay that way ...

command help dialogue now taken from a NEW usage/ax25/heard.txt file
(create new /jnos/usage/ax25 directory, copy heard.txt over to it)
there is a sample JNOS script 'reportRPR.nos' if you are interested (it has a problem though, it creates one defunct processes per run, so you might not want to use it a lot - I need to fix JNOS shell command)

I have NOT updated j2addendum.txt (yet)

2) The VARA IP Bride code now included, no need to extract the tar file anymore

#define EA5HVK_VARA
#define PPP
#define REMOTE_RTS_PTT  (option if you have no VOX control)

Going to try again to write VARA for access mode, because quite honestly so far it seems to be the only way it's being used, very integrated into the winlink system as well by the looks of it ...

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

Install Jnos2 on Raspberry Pi

The purpose of this mini howto is to get a working Jnos configuration on a Raspberry Pi. This is the most simple methode to install and configure Jnos on your Raspberry Pi

Full instructions can be found on the VE4KLM website at: 
https://www.langelaar.net/projects/jnos2/

Make directory and download Jnos:
>> sudo mkdir ./Jnos
>> sudo rsync -a www.langelaar.net::official ./Jnos

Install ncurses development package:
>> sudo apt-get install libncurses5-dev libncursesw5-dev

Configure script Jnos:
>> cd Jnos
>> sudo ./configure 

Build the Jnos executable:
>> sudo make

Make jnos executable:
sudo chmod a+x jnos

Run Jnos:
>> sudo ./jnos

Update JNOS 2.0m.4 systems:     
>> cd <your JNOS source>      
>> sudo  rsync -av www.langelaar.net::official     
After rsync is complete a new file: update_jnos.2.0m.5?.tar.gz     
Extract the files using :       
>> sudo tar xvzf update_jnos.2.0m.5B.tar.gz     

Solution bring Jnos colors back 

add : -fsigned-char to the CFLAGS in the makefile.
CFLAGS = -DUNIX $(DEBUG) $(PATCHES) $(WARNINGS) -fsigned-char

Configuring Jnos

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.
AUTOEXEC.NOS Example

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.
FTPUSERS Example 

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
DOMAIN.TXT Example 

4) MAIL.CFG 
(helps with amnesia)
MAIL.CFG Example

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.
LOCAL.RTE Example

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.
INFO.HLP Example

7) AREAS /jnos/spool/ 
This file contains the mail area groups and are configurated in the rewrite file
AREAS Example

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.
REWRITE Example 

Download/Install Jnos

Quik guide (CLICK) here.
Howto (CLICK) here.
Documentation of Jnos (CLICK)Release history (CLICK)

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.

• Direwolf and Jnos
• Direwolf and Jnos (review)
• Jnos link with uronode
• Jnos rewrite
• Setup a Jnos axip link
• Setup Jnos Ampr Gateway
• Setup Jnos network interface (tun0)
• Jnos TCP access control
• Jnos axudp link to Xnet
• Examples howto forward Jnos/BPQ/Linfbb
• Start Jnos on bootup/reboot
• Compile instructions Jnos 2.0k
• Example autoexec.nos