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)

May 2  2024 - The latest official release is now JNOS 2.0p
The development area was getting too big, so time to just have one official download again. It is essentially the past year of development overlaid on top of the last official release. It's taken longer then I wanted, but lots of testing had to be done by various people. I will go out on a limb to say the stability seems pretty solid now, considering my production system has been running 106+ days and counting, and my IPV6 test site at 144+ days.
For those not wanting IPV6, APRS, VARA, or other key defines, I need to go through the code and put in the proper directives. Why haven't I done this yet before releasing it? Contributions from other authors is a big reason, as is the fact things seem quite stable right now. It's best for all of us to have a stable base release on which patches can then be applied again. Case in point, I finally figured out how I'm going to implement multiple ax25 heard lists per interface. It just came to me the other night, after multiple failed attempts to get it working a year ago. It will be the first patch to show up in the (currently) development repository.

Differences between 2.0p and 2.0o.2 - May 6, 2024
-----------------------------------------------------
1) Courtesy of WZ0C, full credit, changes to VARA support for:

- Multiple VARA modems
- Mailbox connects to other systems
- Connect other system services by SSID (mailbox, tnlink, ttylink)
- Forwarding and reverse forwarding connections
- Timeouts (connection, startup, transmit, session)
- VARA interface type (CL_VARA)
- VARA socket type (AF_VARA)
- Resilient connections to VARA modem
- Automatic VARA modem configuration
- Interface statistics

The NEW commmands to use in JNOS for any VARA operations :

>> start vara
>> stop vara
>> attach vara <interface> <mtu> <hostname> <port>
>> vara ptt <interface> <type> [<hostname> <port>]
>> vara reset <interface>
>> vara pppmode <interface> [enable|disable]
#ifdef _4Z1AC_VARAC
>> vara kissport <interface> <hostname> <port>
>> vara broadcast <interface> [on|off]
>> vara cmddebug [on|off]
>> vara debug [on|off]
>> vara timeout connection <seconds>
>> vara timeout startup <seconds> <bytes>
>> vara timeout transmit <seconds>
>> vara timeout session <seconds>

2) Full integration of Michael Ford (WZ0C) APRS mods
I've revamped the APRS heard list management routines, and had to include new functionality to ensure Michael's APRS mods work on multiple APRS interfaces, of which I have 3 on my home system. The original code from years back didn't see anyone having more then a single APRS interface in place. But if you have
multiple interfaces, each with their own callsign/ssid, then you can not rely on the APRS logon callsign anymore to make sure things are passed properly. Need to walk the code and better document the mods, not very clear in places (the code requires cleanup, sections of 'no longer used' code, and so on)
The NOS APRS documentation is way behind - in a pinch, the new mods are :
There's a lot of new things (from WZ0C himself)
* acking works in and out, with retransmits
* The aprs_dupe CRC is modified to align with the APRS-IS spec.
* You can list bulletins in the APRS Message Center with "\b".
* A user can set their SSID in the APRS Message Center with "\s".
* There's a can_nws list.  Weather offices on this list (like BOX)i
will have their weather warnings listed in the APRS bulletin list.
* APRS flags has +fillindigi, which tells JNOS to only digi for
WIDE1-1, but not WIDE2-N or anything further.
* APRS flags has -aprs_txenable to disable transmit when testing
configs or verifying igating is as desired.  Packets are still
logged to xmitlog.txt.
* "aprs digi" allows the sysop to set which terms will be digipeated.
So you can add "MA3-3", for example, or remove "RELAY".  Defaults are backwards compatible.  (WIDE3-3, RELAY, WIDE, SP3-3, DL3-3)
* Change to digi to insert our call when there's room.
* message_handler has been changed so that a return value of 1 always means gate (either direction), and 0 always means don't gate (either direction).
* message_handler updated to include APRS-IS spec gating
rules (both directions).
* more logging, to help in debugging
* Addition of jnos/aprs/xmitlog.txt to log every transmitted packet, and the interface it was transmitted on. This is now optional, see the new directive APRS_LOGSENT_WZ0C in aprs.h header file (Maiko)
* Support (per APRS-IS spec) to gate one position from far away station when it follows one message from far away station.
* Tracking of igates to avoid gating packets from igates.
* Attribute database to store user settings for APRS Message Center.
* Use station position DB to know whether to igate a packet.
* Gate APRS objects in certain cases
* Gate from APRS-IS to RF
* Implement ring buffer for APRS-IS receive so that the server
doesn't hang up on us.
* Maiko's change to use the iface addr when sending a packet
* Maiko's change to have linked list for heard stations

Note, NOSaprs version is now 2.0p, the RF dest call is not APN20P,
so if you have ax25 routes setup for APN20O, you should edit them.

3) The APRS heard list is now a link list, not an array as before, this
is more more in line with the standard ax25 heard list methodology. Also got rid of the 'combined interface' approach to how the APRS heard list gets displayed. Each interface now has it's own section, easier to read, also easier to pickout callsigns, and so on. The cosmetics need work, but the main thing is in place, lots of long term tests done. Note : The 'aprs hsize' command can now be passed 0 to give an APRS heard
list of unlimited size, just like with the 'ax25 hsize' command.

4) Stability fix - since I started IPV6, I have been plagued with frequent crashes of JNOS, in the most bizarre area, netrom network code. So after some analysis it would appear this is possibly a case of the stack meets heap, or vice versa, or something along there. This is a very important patch, even if all that was done was to bump up the value of NWSTACK in the config.c source file. My test systems have been running 100+ days.

5) The 'ax25 heard save|load' functions now include the APRS heard list. You'll recall you can restart JNOS as much as you want, without losing days, months, or even years of stations heard, digipeated, destination calls, and now APRS traffic. All you need in autoexec.nos is something like this :
at now+0015 "ax25 heard save+"
ax25 heard load
I have also redesigned the heard list management routines for the case of the 'ax25 heard load' function, such that I no longer need the axhsort.c functions anymore. I am not sure why I went to all that trouble to write the sort routines after one loads the ax25 heard list from file, when all that was needed was to simply change the manner in which the link list is managed - this is a much better approach. Note : timestamps are a bit off on load, but it's not that bad. What is more important is history of callsigns heard, and if they are regulars, the timestamps will update quickly enough. Also note, I currently don't bother loading digi (path) info for the APRS data, it changes anyways. I will probably revisit that down the road, not critical I think.

6) Added more IPV6 services, clients, ping, dns, options ?
Resolve6() function now passes thru ipv4 numeric addres. Enforce naming convention on ipv6 iface, since exchanging TAP specific data with TUN interface is not a good idea!

a) The usual 'start telnet' will now result in JNOS creating 2 instances of the TELNET service - one for ipv4, and one for ipv6.
IF ipv6iface is not defined, then only the ipv4 instance is brought up. If you do not want to run both, you can create a single instance for the IP version of choice, using the -4 or -6 option, for example : 'start telnet -4' OR 'start telnet -6'
Any additional parameters are just slapped on the end, for example :
'start telnet -4 6300 iac'
b) The SMTP client side of JNOS is now IPV6 capable, this required a lot of testing, and also required a working MX lookup for IPV6, so far it is encouraging, no doubt people will find a way to pick it apart, so please report ANY issues, thank you.
Note : there is no default smtp gateway code for IPV6 at this time
As a consequence of my test setup, mods were also made so that JNOS can now properly communicate with an ESMTP (thanks Bob) email server, regardless of the version of IP - the enhancements are separate and unrelated to IPV6. Had to make sure to set the ethernet address for Loopback iface or else any attempt to talk to 'localhost' will fail, I need to properly implement IPV6 localhost at some point, but what I have now is good enough for smtp, etc.
c) The SMTP server is now available for IPV6. The usual 'start smtp' will now result in JNOS creating 2 instances of SMTP service. One for ipv4, and one for ipv6. IF the ipv6iface is not defined, then only the ipv4 instance is brought up. If you do not want to run both, you can create a single instance for the IP version of choice, using the -4 or -6 option, for example :
'start smtp -4' OR 'start smtp -6'
If you have a custom port, just slap it on the end, for example :
'start smtp -6 14025'
Also fixed padding for 'ip heard' - full length ipv6 address skews listing
Observation :
I had wanted to place the -4 and -6 options at the start of the arg lists, so for example, I would rather have 'start -6 telnet' or start -4 smtp', but the subcmd() code in cmdparse.c makes it a challenge to do so, so for now, this is the easiest way to accomodomate the ip version (ipv) options.
d) The HTTPVNC server now available for IPV6, same as the others, extra -4 and -6 options IF they are needed. Default will start service in both IPV4 and IPV6.
start httpvnc [-4|-6] [port]
NOTE : I used '#undef  APACHE_MOD_PROXY_BBS10000' to test this. My system is already configured for my production JNOS, so it's awkward to test with https at this time. In reality we actually want to use it with MOD_PROXY defined.
IF you happen to see this warning in your linux console (using firefox) :
bash-5.1# [ERROR viaduct::backend::ffi] Missing HTTP status
[ERROR viaduct::backend::ffi] Missing HTTP status
Do a search and you will probably find something in arch linux forums :
Topic: [SOLVED] Firefox breaks after v110 update, all pages show
a blank screen (Read 502 times)
https://forum.artixlinux.org/index.php/topic,5154.0.html
e) The HTTP server is now available for IPV6, same as the others, extra -4 and -6 options IF they are needed. Default is to start service in both IPV4 and IPV6.
start http [-4|-6] [port] [drive] [rootdir]
Note : #define HTTP_EXTLOG is NOT ipv6 ready, so leave it #undef for now
f) The POP3 server is now available for IPV6. The usual 'start pop3' will now result in JNOS creating 2 instances of POP3 service - one for ipv4, and one for ipv6. IF the ipv6iface is not defined, then only the ipv4 instance is brought up. If you do not want to run both, you can create a single instance for the IP
version of choice, using the -4 or -6 option, for example :
'start pop3 -4' OR 'start pop3 -6'
If you have a custom port, just slap it on the end, for example :
'start pop3 -4 11000'
g) The BBS user can now provide -4 or -6 option to your telnet command, which tells JNOS to directly use IPV4 or IPV6 for any passed hostname, instead of using the automatic system of try IPV6 first, IPV4 second, which incidently is a DNS fall through, not an actual CONNECT fall through, so these options should provide a bit more flexibility. The CONNECT fall through is a bit more complicated from a code perspective, and might still some work, comments, suggestions, critiques are welcome.
For example, to bypass IPV6 to Bob's system, and just use IPV4 :
Area: ve4klm (#1) >
tel -4 port.ve3mch.ampr.org
Resolving port.ve3mch.ampr.org... Trying...  The escape character is: CTRL-T
The same holds for the telnet command given at the JNOS console
h) Hop check seems to be working for IPV6 now, not perfect. For this version, the hop port is FIXED to UDP port 53 for each round - equiv to linux :
traceroute -U <host>
i) Significant work done to support IPV6 UDP - trace command updated as well You can now add an IPV6 nameserver (use the full length IPV6 address) :
domain addserver 2001:4860:4860:0000:0000:0000:0000:8888
The above is a public nameserver from Google, resolves IPV4 hosts as well I have added support for TYPE AAAA (28) IPV6 address records ! I confirm that 'domain query' is working (use 'domain trace on' to watch) The domain.txt (cache file) needs works, not 100%, but seems to 'work' ?
New resolve6() function so IPV6 hostnames resolve to an IP address, meaning : You can now ping from either console or bbs prompt using a hostname. You can now telnet from either console or bbs prompt using a hostname. You can now forward.bbs using a hostname (use regular 't' for telnet)
WARNING : make sure 'domain trace off' when you use forward.bbs, if I did not know any better, the domain trace info interferes with the forward ?
NOTE : for all these 'working' cases (ping, telnet, forward), they will first try to resolve IPV6, then if that 'fails', they'll fall back to IPV4. Should probably make this somewhat configurable ? but that's how it is right now. The short form display version of IPV6 address is not perfect, experimental.
j) All outgoing IPV6 PING commands from both the JNOS console and BBS prompt should now be working. You still have to use a full length IPV6 address. (recv_mbuf() and send_mbuf() functions now support IPV6 raw sockets) Incremental ping (incflag) is NOT supported for IPV6 at this time. To abort continuous ping, just use the 'reset' command on the JNOS console. One shot outgoing pings from JNOS console (with length arg as well) :
jnos> ping 2001:0470:001d:0138:0000:0000:0000:0002 100
jnos> Resolving 2001:0470:001d:0138:0000:0000:0000:0002...
2001:470:1d:138::2: rtt 28
jnos> ping 2001:0470:001d:0138:0000:0000:0000:0002 300
jnos> Resolving 2001:0470:001d:0138:0000:0000:0000:0002...
2001:470:1d:138::2: rtt 31
Continuous and Incremental is NOT YET implemented from JNOS console ???
(requires work on the send_mbuf and recv_mbuf RAW IP code)

7) The SMTP deny relay exception code is now in place for IPV6.
Bob (VE3TOK) and myself tested this one late evening. It is working fine. This exception list allows JNOS to accept smtp relay from any IPV6 addresses outside JNOS own IPV6 subnet, currently hardcoded to /120 - more then enough for its own peers.
smtp relay add <ipv6 address> <block count for mask>
The mask for IPV6 is actually a block count, blocks of /8, so for instance, if you want a mask of /24 you would use the value 0x03. If you want a mask of /120 you would use the value 0x0f. Why did I do it this way ? The code is ridiculously simple by working the mask this way. For example, if we want to allow this IPV6 subnet with /64 mask :
smtp relay add 20XX:YY70:00ZZ:0138:0000:0000:0000:0001 0x08
Note : use full length IPV6 addresses in JNOS, even if shortened version is displayed, it's still not supported for entry.

8) The SMTP deny relay code is now in place for IPV6
There is only one IPV6 interface for JNOS at this time, unlike regular IP, where each JNOS interface can have it's own ip address, and we cycle thru all the interfaces to try and match deny relay situations, for IPV6 it is very simple. The smtp client must be on your 'ipv6 addr' with a hardcoded netmask (at this time) of /120 - realistically one will never use, even a small portion of /120 - so I think that's fair for now. Your linux system on which JNOS runs, is automatically included as a valid smtp client.

9) You can now have AXUDP and AXIP in IPV6, for instance :
attach klmudpv6 256 2600:3c03:e003:3700:0000:0000:0000:0003 - 10093 10093
attach axip klmipv6 256 2600:3c03:e003:3700:0000:0000:0000:0003
Bob and I spent some time on this, in the process discovering a fundamental flaw in the code - my fault from 20 years ago. You can not run both AXIP and AXUDP to the same IP address, use either AXIP or AXUDP, but not both. You'd think that most people wouldn't run multiple wormholes to same remote host,
but of course we just had to prove it to ourselves, but it's fixed below : You should now be able to run BOTH an axip interface and an axudp interface to the same remote IP address. You can link up with my test system using :
attach axip axip_v6 256 2600:3c03:e003:3700:0000:0000:0000:0003
and attach axudp axudp_v6 256 2600:3c03:e003:3700:0000:0000:0000:0003 - 10093 10093
Note : use full length IPV6 numeric, domain name is supported, but crashes right now, so stick with the numeric address for the time being, not like AXIP or AXUDP will need dyndns for IPV6 ? Who knows ...

10) Fixed buggy code with the IP version start service parameters.

11) The ip heard list now includes IPV6 addresses
The default is to show both IPV4 and IPV6 addresses. Currently only one option is available, either -4 to show only IPV4 addresses, or -6 to show only IPV6 addresses. The code is easy enough for anyone to customize to their own vices, for example :
jnos> ip h
Tcp/Ip systems heard:
Address                          Port       Since       Pkts
192.168.200.201                  tun0       0:00:00:15    21
2600:3c03:e003:3700::3           tap0       0:00:00:16     7
fe80::ac0e:ffff:fef5:578e        tap0       0:00:00:16     6
2001:4860:4860::8888             tap0       0:00:00:23     1
192.168.4.200                    tun0       0:00:00:28     4
jnos> ip h -4
Tcp/Ip systems heard:
Address                          Port       Since       Pkts
192.168.200.201                  tun0       0:00:00:24    21
192.168.4.200                    tun0       0:00:00:37     4
jnos> ip h -6
Tcp/Ip systems heard:
Address                          Port       Since       Pkts
2600:3c03:e003:3700::3           tap0       0:00:00:27     7
fe80::ac0e:ffff:fef5:578e        tap0       0:00:00:27     6
2001:4860:4860::8888             tap0       0:00:00:34     1

12) Both TCP and UDP code can now log 'no listener' traffic - examples :
17:18:14 network: 2600:3c03:e003:3700::2:56401 - no UDP (161) listener
17:18:20 network: 192.168.4.200:54897 - no UDP (161) listener
17:21:46 network: 2600:3c03:e003:3700::2:39540 - no TCP (34) listener
17:21:54 network: 192.168.4.200:36546 - no TCP (34) listener
You can switch it on and off using a new JNOS command 'ip nolisteners', for example :
jnos> ip nolisteners 1       (to turn on logging)
jnos> ip nolisteners 0       (to turn off logging, default)
I think logging of nolisteners is a great way to test your firewall rules, or to see if any remote systems are attempting an axip or axudp link with your system, and they might have the ports all wrong, and so on ... I personally use it to watch for 'intruders' which I immediately add to my 'ipset' database where they get blocked at both INPUT and FORWARDING to my JNOS system.

13) Added -c option to 'ip heard' command, used to set a ceiling on Pkts counter :
ip heard -c        < displays current ceiling >
ip heard -c 100    < set a new ceiling value >
ip heard -c 0      < 0 means unlimited, the default >
Note : the ceiling applies to ALL entries in the IP heard listing. Anytime
an entry is updated, if the Pkts for that entry exceed the ceiling,
it gets reset to 0 and starts over again.
Working on -r option to clear packet count for a specific Address (TODO) :
ip heard -r [Address]  < reset Pkts for specific Address >

14) Using incorrect variable for maxheard processing in the ax25 digid heard list, and realizing I need to create a new 'numav' variable specific to that list. I also added extra null pointer checks to the heard code.
I think the combination of the incorrect variable, and not having these pointer checks is what Gus has been running into (lots of crashes), hope these small fixes solve the problem once and for all. Anyone with digis in their ax25 connects will be affected by this 'bug' at some point.
[ Postnote - 26Apr2023, from Gus, sounds like this is fixed ]

15) Other odds and ends and such, miscellaneous ?
Added a new '(XX)tcp access denied NNNN' counter to the tcp status information, although I have noticed 'tcpOutRsts' is matching, so it may be removed at a later date, but this new one is directly counted by failed 'tcp access' checks, not TCP internals Hopefully fixed the case where sometimes the lzhuf percentage displayed in the logs during forwarding (usually due to very small messages) is overly huge and makes no sense. Finally got to fixing it after some emails with Michael Ford (WZ0C), this log entry below is what we are referring to :
MBOX (urcall) lzhuf uncompress 86/77 = 239568104853370788 percent He also believes the automatic signature code in mboxmail.c should not add the signature for the (T)raffic type. The body of a Traffic message should only include the Radiogram. Preceding R-lines are okay. This will be especially an issue in cases where Traffic messages are received and parsed programmatically. He was kind enough to provide a patch.
WZ0C also provided a patch for agwpe, baycom, and winrpr. The interface flags shouldn't be initialized to zero after the setencap() call, which effectively removes the interface from the jheard listing. I decided to put it in for multipsk as well.
Added corrections from Michael (WZ0C), to fix a number of crashes within the "attach" subcommands that occur if the user supplies incorrect number of arguments or specifies an interface name that already exists. These corrections are specific to the winrpr, vara, tun, multipsk, fldigi, and agwpe drivers.
Fixed a few stability issues, null pointer checks, as well as an updated makefile and configure script, which now checks for the presence of the compiler and the make utility (thanks Mark, N2MH)

16) New centralized debug flag management routines. I've been wanting to do this for some time, just because it is tiring and wasteful to always have to write new debug commands for specific tasks. New debugging in place for LZHUF compression for recv_yapp() function, to give me a better idea WHERE in the process Early Disconnects might be occurring, not entirely sure how useful that is, but we will see.
NEW : jnos console command called 'debug'
run without arguments will list which debugs are toggled
currently only LZHUF is available - use 'debug lzhuf' to toggle
The idea is to convert all debugging to use this 'module' in the future

Mart 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