differences between JNOS 2.0f and 2.0f [Beta] - December 21, 2007 ----------------------------------------------------------------- 1) Time to freeze things into an official version. I have not done alot of development lately anyways, and if I am to ever update the original jnos 1.11f documentation to where we are now, I need a frozen version. 2) Added callsign validation for BBS login. I have to thank Barry (K2MF) for the validation code. There is a new '#define MBX_CALLCHECK' in the config.h file - enabled by default. Now only *valid* callsigns will be accepted when you try to login to a JNOS server via telnet. 3) The way the email address is being formatted in the aprsmail () function has been changed. Apparently it is NOT legal to use the ( and ) characters in the local part of the email address. Thanks to Janusz for finding this. 4) I have fixed another HFDD bug, where incoming HF connects were not seeing a mailbox prompt in some cases. I have also shortened the text of the HFDD beacon - the "INTERNET GATEWAY" portion has been removed. 5) Bumped up the version of NOSaprs to match this latest version of JNOS :-) differences between JNOS 2.0f [Beta] and 2.0e - Tuesday, June 12, 2007 ---------------------------------------------------------------------- 1) The JNOS (linux version) kernel has been revamped ! There was little choice - JNOS 2.0e would not compile on Fedora Core 6, or Ubuntu, or any of the more recent linux distributions, unless you applied a patch that I came out with last year. The good thing about this is that it will still work on older distributions, like my Slackware 9.1 system. The developers of the GLIBC have *fixed* things so that one can no longer use the jmpbuf calls (setjmp/longjmp) as they have been traditionaly used by the JNOS kernel. The reasoning was that these calls should never have been allowed in the first place type of thing, etc, etc. As a result, I have revamped the JNOS kernel to instead use the ucontext calls (makecontext, swapcontext, setcontext, getcontext). Actually, this was very easy to do, since the original JNOS 1.11f had most of the code in place already - a prior developer was experimenting with Sun O/S. 2) Fixed a bug in the forwarding code - a typing mistake I made when I put in the 'telpac' option for JNOS 2.0e - FBB compressed forwarding was disabled for ANY and ALL forwards to other remote systems asking for it. There was a patch for it, but the patch never made it onto my website for some reason. 3) The 'ax25 status', 'ax25 kick', and 'ax25 reset' commands have been enhanced so that you can now pass the remote call instead of having to type in the &AXB (that 8 digit hex number). This is a feature I have long wanted to add. I always hated having to look up the &AXB, then mess it up (or somehow forget it) while entering it seconds later. 4) More improvements to the HFDD (HF Digital Device) code, including a new feature where the drivers will automatically detect whether a KAM or PTC is in host mode or not. If not, JNOS will try to put them into host mode, using a user configurable init file (new feature) for each HF modem. The code structure of both the KAM and PTC drivers were recently revamped. The only major thing left to do is revamp the DXP38 driver. I have not had alot of time to finish it - I felt it a priority to get a new release out first (that being JNOS 2.0f), due to the kernel issue, and it has been a while since a new version was releasted to the public. If a BBS user or SYSOP enters the 'mbox' command, it used to be that it was not very clear if an HFDD session was active or not. In most cases, all you would see was a bunch of gibberish where the HFDD session was supposed to be. I have fixed this, so that any active sessions show up as 'Pactor'. Keyboard mode (ie, the ability for a BBS user or SYSOP to connect to a remote station via a HFDD port, then *chat*) has been removed for now. It never worked very well, and there were USER issues that came up which I had a hard time figuring out a solution for. Perhaps down the road ... HFDD devices are strictly for forwarding with a remote BBS now, or accepting calls FROM a remote station. NEW and up-to-date documentation for this latest HFDD implementation. As usual, work on the HFDD code is always ongoing, and experimental. From this point on, you won't hear much more about the HFDD development, as I am sure most of you are tired of hearing about it. That's all I had been doing off and on during the middle of the year, and frankly, there is not much left to do on it - It seems I am my only customer anyways. differences between JNOS 2.0e and 2.0d1 - Tuesday, April 18, 2006 ----------------------------------------------------------------- 1) The NRR (netrom route record) code has been separated from the INP3 code, and is now independent of the INP3 functionality. To include NRR support in JNOS 2.0e, use '#define NRR' in the config.h file before compiling. Here's an example of the NRR command at the BBS (mailbox) prompt : Area: ve4klm (#1) > nrr wa7v-2 *** route: VE4KLM-1 K7EK-8 WA7V-2* K7EK-8 VE4KLM-1 > 2) Added PARAM_PACTOR to device parameters. The command : param dxp38 17 1 can now be issued as follows (if the sysop does not like using a number) : param dxp38 Pactor 1 3) Finally - a true HFDD device (actually just a plain serial device). Up until now, the DXP, SCS, and KAM modems had to be attached as an AX25 device, even though they were not using the AX25 protocol. To keep the communications to the modems from getting messed up, the sysop was required to disable the AX25 and MBOX beacons - a kludge of sorts. This change should stabilize the HFDD serial interface quite a bit. Previous to JNOS 2.0e, a typical autoexec.nos entry for a DXP38 would be : attach asy ttyS1 - ax25 dxp38 4096 256 9600 ifconfig dxp38 description "Pactor 1 - 10.129.1 or 7077.1 LSB" param dxp38 Pactor 1 ax25 bcport dxp38 off mbox mport dxp38 off With JNOS 2.0e, the following is now the proper way to do it : attach asy ttyS1 - hfdd dxp38 4096 256 9600 ifconfig dxp38 description "Pactor 1 - 10.129.1 or 7077.1 LSB" param dxp38 Pactor 1 4) NOSaprs is now at version 2.0b, the biggest change is that I have rewritten the APRS digi code to reflect the latest new-N paradigm, and callsign substitution for WIDE1-1 and RELAY. Janusz (SP1LOP) from Poland has confirmed that the code is working as it should. Further more, experimental SSn-N code exists, and is currently specific to Germany and Poland. Again, Janusz has confirmed this code is working as it should. One can change this to suit their own regions by modifying the 'aprsdigi.c' module. I will make this configurable (autoexec.nos) in some future release. Rewrote some of the code that does the NOSaprs 14501 webpage. One should note that the generated URL string is slightly different in this new version. For example the word, 'interface' is now 'ifc'. Bumped up the maximum stack size for APRS Server to be safe. 5) Removed timeout code that waits for an HFDD connection to get established. The code was never written very well, and generated some very undesireable effects if it kicked in at the wrong time. When reading the forward.bbs file to establish a connect, the HFDD code was improperly dealing with an EOL (end of line) read from the forward.bbs file. This was causing truncation of the remote callsign being used in the HFDD connect command. This is now fixed. 6) JNOS 2.0e can now do basic TELPAC forwarding with WL2K systems. A new option called 'telpac' has been added to the 'forward.bbs' file - ie: --------------- k4cjx tcp telpac @ @ @ +Callsign : @ ..VE4KLM +Password : @ . k4cjx --------------- 7) Added CL_HFDD to interface types, so that I can clearly identify HFDD interfaces. The HFDD interfaces will no longer show up as AX25 ports when a BBS user issues the PORTS command, but instead will be listed in their own category, for example : Area: ve4klm (#1) > Available AX.25 Ports: wsc : internet link - VE4WSC 430 : 1200 Baud - 145.01 Mhz Available HFDD Ports: dxp38 : Pactor 1 - 10.135.5 or 7077.1 LSB Remember - HFDD ports are hostmode TNC ports, nothing to do with AX25. 8) Solved a problem that has plagued JNOS (Linux) for a long time - user logs onto the BBS, then enters the NODES command at the mailbox prompt, only to see JNOS crash and restart. It seems the qsort() call is very stack intensive, and can easily push the maximum stack size when the NETROM Node table gets a bit too big. It turns out that the Linux qsort() is a recursive function, using ALOT of stack if it needs to. I did some searching and found an ANSI-C version of qsort that is easy on the stack, and NON-RECURSIVE. I literally pasted the code into a new JNOS function which I call j2qsort(), which JNOS now uses in place of the Linux qsort(). Since I have done this, JNOS has yet to crash on me, whether I enter the NODES command at the BBS prompt, or NETROM ROUTES or NETROM ROUTE INFO at the F10 (console) screen. I can easily list 600+ node entries now. 9) The beginning of some big changes ... Most (if not all) NOS variants (and JNOS is no exception) use function calls that have the same name as their UNIX counterparts - 'bind', 'recvfrom', and 'socket' are just a few examples, as is the NCURSES 'tputs' function. To avoid clashes with the system calls, NOS variants have traditionally used entries like the following to get around these : #define connect j_connect #define recvfrom j_recvfrom #define tputs j_tputs These are typically found in header files like socket.h and global.h. Starting with JNOS 2.0e, I am removing the above method. Instead, I will actually be renaming the JNOS functions to be clearly distinguishable from their UNIX (or WINDOWS) counterparts. For example, the tputs() function in JNOS would be renamed to j2tputs, and the '#define tputs j_tputs' removed. Why ? I want the flexibility to call UNIX socket functions for example, and not worry about conflicts with the JNOS ones. I may try to port JNOS to Windows at some point, and there again I may want to directly access the winsock libraries. I'm thinking the more self contained JNOS appears, the easier these tasks will be for me down the road (I think so anyways). I don't want people to get alarmed by all these changes. They're harmless, and if anything, will contribute to a more stable JNOS 2.0 down the road. 10) Rewrote the locking code that I originally did for Netrom tables, then added scalability for other tables like tcb, timers, usocks. After some long term observation though, it has occurred to me that locks are for the most part, not a big concern, since the type of task scheduling used by NOS is such that operations on tables can only happen from one particular process at a time anyways. BUT, I'm sure there are cases that *might* require locks (when and if I ever find them), so the code stays ... differences between JNOS 2.0d1 and 2.0d --------------------------------------- * Mostly bug fixes and diagnostics, no command or syntax changes. 1) Fixed a situation where anyone who ran an APRS enabled JNOS binary, but didn't have APRS configured, would see JNOS crash on each incoming APRS frame. 2) Bumped up the NOSaprs version to 2.0a, in preparation for providing once again, the NOSaprs update kit for JNOS 1.11f and TNOS users. 3) Fixed a situation where compressed data formats for the !, =, /, and @ DTI values were not being recognized and passed by the validation routine. 4) If we get a directed APRS query that we don't support, we now send a message back to the user saying so. Previously, we did nothing. 5) Fixed a situation where if 'aprs contact' was not defined in autoexec.nos, and a 14501 page was requested, then JNOS would crash each time. 6) INP3 - more work done, spent alot of time reviewing the code against the linux version of INP3 by PE1RXQ. This code is not complete yet and should not be used at this time. I regret having made such a big thing out of it in the last release. Do NOT compile it into your binary (in other words, make sure you '#undef INP3' in your config.h before you mass compile). I'm not sure where the INP3 stuff will go at this stage. I simply have not had the time to work on it lately. It's on the shelf for now ! 7) Some code cleanup here and there, the major one being replacement of all malloc() calls in JNOS with mallocw() instead. Did some cutting down of duplicate code in the kernel subroutines. Fixed a few bugs. 8) Fixed the pactor connect code for the SCS PTC units to use just a plain old 'C callsign'. There should be no port specifier. Previously I had used the syntax 'C 1:callsign' instead, which is simply wrong for the HF mode. 9) Added some experimental locking of the netrom route tables, plus a netrom 'lock conflicts' counter in the netrom status command. This was put in more for me to investigate why the Nodes command crashes JNOS from time to time. differences between JNOS 2.0d and JNOS 2.0c5a --------------------------------------------- 1) The DOS release is once again at the same level as the Linux release, and the makefile for the DOS release has been revamped (simplified). The Linux release will now compile properly up to GCC versions 3.4.3 and 4.0.1. 2) New subcommands added to the JNOS 'netrom' command : netrom debug [on|off] netrom nrr [callsign of a remote netrom node] netrom l3rtt [callsign of neighbour] [interface] 3) New command added to JNOS : start inp3 4) New command added to BBS user prompt : nrr [callsign of a remote netrom node] For example, here is a NRR request to on6dp from my system the other day : Area: ve4klm (#1) > nrr on6dp Area: ve4klm (#1) > *** route: VE4KLM VE4WSC WA7V-2 ON6DP* WA7V-2 VE4WSC VE4KLM > 5) New type of callsign list for APRS callsign filtering : aprs calls micetorf [list of calls or patterns] 6) Added a new directory for the APRS position database (a new project) : ${JNOSROOTDIR}/aprs/db/positions 7) Kantronics KAM Series Host Mode Driver (not completed yet) A crude prototype Host Mode driver for Kantronics KAM modems now exists, and a couple of milestones were set. I spent alot of time on this early in the summer, however it's not ready for general use at this time. a) working single channel KAM hostmode implementation for JNOS 2.0, for the packet (non-HF) mode. I had it working on an old KPC-2, as well as on a version 5.0 KAM that I borrowed from a friend. b) got it working with the AMTOR mode, using two backtoback KAM modems talking to each other (one JNOS, the other Mailbox mode). I was able to do some live testing as well, but nothing more has happened since. Testing has been limited to AMTOR, because that is all I can do at this time with the older KAM modems that I have here. Due to me having poor equipment, lack of live testers on RF, and lack of time in general, the KAM Host Mode driver is on the shelf for now. Adding the GTOR and PACTOR modes to it will be a piece of cake, but until I get my hands on a KAM XL or similar, this part of the project is on hold till further notice. c) Special thanks to Mitch Hill - K1FH - AFA1HN, for helping out, and for being a mentor of sorts with respect to AMTOR and QRG terminology :-) 8) INP3 Support (alot has been done, but not completed yet) JNOS 2.0d has partial support for INP3 stuff. Ideas and code fragments have been borrowed from the INP3 Kernel Patches by PE1RXQ, and work is ongoing. If you want INP3 support, then #define INP3 in config.h, then recompile the source. This is VERY experimental, and not complete yet. JNOS will recognize incoming RIF (Route Information Frames) from INP3 netrom neighbours, and update quality/return time values in the nodes table (more needs to be done there). JNOS will respond to an L3RTT if a INP3 netrom neighbour sends it one. If you want JNOS to regularily send out it's own RIF and L3RTT to its neighbours, then you can run the INP3 scheduler using 'start inp3'. Again, this is experimental and incomplete, but I felt that I really needed to get another JNOS update out to the masses. To see the INP3 stuff in action, turn on 'netrom debug' - see section 2) above. The debugging goes to the master logfile at ${JNOSROOT}/log/DDMMMYY. * It is possible that the INP3 code may add some stability to JNOS configurations that have links to INP3 netrom neighbours. Then again, it might just be my imagination, your results may vary, let me know. 9) NRR (Netrom Route Record) Even though NRR packets (Netrom Route Record) are not really part of the INP3 stuff, it is currently available only if you '#define INP3' in the config.h source file. I'll move it out at a later release. Sysop and BBS user can now ask for a NRR to a remote node - see section number 4) above. Also, if JNOS receives a NRR request from a neighbour, it will now format the proper reply so that the remote user sees a path. A) Started work on a positional database, new module 'aprsposdb.c', and a new directory under the APRS root directory, ie (/jnos/aprs/db/positions). Any positions coming in from RF are to be added to the database. The idea is to have NOSaprs read the database at any time, and generate a graphical map of a region, with positions of stations overlayed on the map. Compiling this feature depends on the #define/#undef APRS_POSIT_DB option in config.h. It is currently undefined, the code sitting there for future development. B) Enabled monitor mode for the DXP38 when running in P-Mode (Pactor), so I can observe more details (and Pactor traffic) when running HFDD server mode on my DXP38 (ie, 'hfdd server dxp38 start'). C) Added a feature (#define DEFAULT_SIGNATURE in config.h) that will add a system signature to ALL outgoing mail from JNOS. If defined, JNOS will add the contents of the '/jnos/spool/signatur/default.sig' file to the end of all outgoing messages composed by any BBS user. In hindsight, I really have to wonder why I bothered with this - perhaps to put disclaimer of sorts on outgoing messages, to protect the sysop from users bending the rules ? D) Added a feature (#define MAIL_TRACE_USER_PORT in config.h) that will add something like the following to all outgoing mail from JNOS : X-JNOS-User_Port: allowing the recipient of a messages to see what 'signed in' user sent it, and on what JNOS port that user was connected, when message was composed. E) Problem in the REMOTE client command, it was crashing alot, the 'udpadd' subcommand was not working properly. It turns out that I was not setting the key information correctly for 'udpadd'. Problem should be fixed now. F) The APRS code is now able to gate MIC-E frames from the APRS IS (internet system) to RF. A new callsign list was added, to control what stations are allowed to have their MIC-E information sent out RF. See section 5) above, note compiling this feature depends on the #define/#undef GATE_MICE_RF directive in the config.h source file. G) Fixed some minor bugs, fixed a whole bunch of missing initializers, and renamed the 'log' function to 'nos_log', to avoid conflicts with built-in system libraries. This had to be done, partly because the more recent GCC compilers were complaining about it. The 'log2' function was also dealt with for similar reasons. Cleaned up some old code here and there. H) If you are using a JNOS binary that has NETROM compiled into it, and you fail to 'attach netrom' (in other words, you're not interested in running the netrom stuff), BUT you happen to have netrom neighbours that broadcast nodes and stuff to you, very likely your JNOS will crash each time a nodes broadcast comes in. The solution was either '#undef NETROM' in config.h, or run the 'attach netrom' command in your autoexec.nos config file. This is now fixed ! It was actually an existing problem before JNOS 1.11f differences between JNOS 2.0c5a and JNOS 2.0c5 ---------------------------------------------- 1) Syntax change for 'ax25 xdigi' - added optional callsign substitution ax25 xdigi [source port] [dest port] [digi call] [substitute call] The 'subsitute call' is optional. 2) Proper changeover code for the SCS PTC modems added, so technically the forwards to any WL2K system should now work just as good as the Halcomm DXP modems. 3) The 14501 page has evolved to include conventional packet stations heard, current and past users connected or logged in. The layout has also changed a little bit. This is an ongoing project ... This requires a new 'jheard.o' in the makefile - see 'makefile.aprs', distributed in this update. 4) Added a new '#undef WELCOMEUSERS' for 'config.h', to cut down on the stuff displayed to users that have just logged in or connected to the system - see the file, 'config.h.dist', distributed in this update. 5) Put the '#define APRS_DIGI' back into the 'aprs.h' header file, as it was accidently undefined when I created the last official version. 6) Removed some excessive entries from the JNOS log files, the new ax25 custom cross port digipeat rules had a bit too much logging enabled. differences between JNOS 2.0c5 and 2.0c4 ---------------------------------------- 1) New command (see documents for details) ax25 xdigi [source port] [dest port] [digi call] 2) Changes in the directory and file structure for the NOSaprs component there is a new root directory for the NOSaprs, meaning you will have to create a new directory, move some files, and delete the old. Here's what you need to do (below). For illustration purposes I use '/jnos' as the JNOS root directory (which is what most people use anyways). a) create a new directory, '/jnos/aprs' b) move the directory '/jnos/msgdb' to '/jnos/aprs/msgdb' c) move the file '/jnos/spool/aprs/aprs.txt' to '/jnos/aprs/aprs.txt' d) delete the directory '/jnos/Spool/aprs' e) feel free to put the NOSaprs log file under the new root directory, so for example in your autoexec.nos configuration file : aprs log /jnos/spool/log/aprs.log could be changed to : aprs log /jnos/aprs/master.log ----- Copyright (C) beginning of time to 2007 by Maiko Langelaar / VE4KLM