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

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