3. Improvements and Enhancements

The following optimizations and improvements have occurred.

• Converted statistics files from ascii to binary
  This increases loading/saving speed, reduces the chance of corruption, and uses less disk space.
• Added new 'statconv' executable
  This executable can be used to import existing ascii statistics files, converting to the new binary format. It can also be used to export a binary file into the old ascii format, which is only useful for debugging purposes.
• Added a 'AH' PBBS sysop command, to display only areas with held messages
• Added a command session 'pbbs holdsummary' command
  This gives the same output as the PBBS 'AH' command, without requiring the sysop to logon to get this information.
• Added a 'review' PBBS sysop command for reviewing of held messages
  This command displays all held messages, then area-by-area, message-by-message allows you to list the message, view the message with headers, release the message from hold, skip the message (retaining the hold), kill the message, skip to the next area, mark all messages in this area available, or quit the review process. The '?' command displays command summary.
• Added a 'pbbs scan <username>' command
  This is the same as logging into the PBBS as 'username', and then doing a 'quickscan' command. Simply added for the convenience of the sysop.
• Added a 'smtp rewritecheck' command
  This allows you to easily check the rewrite rules for a given address. The 'smtp rewritetrace' flag is forced to on (regardless of its current setting) during the resolution of this rewrite tracing, and returned to its original setting once complete. Note, that if this command is accessed remotely that the rewritetrace intermediate info will not be displayed, as this is always displayed on the Console.
• Changes, as needed, for compilation on Solaris 2.5 and IRIX 6.2
  Now TNOS compiles off the shelf for SGI's Irix (tested with 6.2) and for Sun's Solaris (tested with 2.5). It will use the native OS's curses, but it is NOT as full-featured as NCURSES, so not all curses-related features work unless you use NCURSES. Highly functional, though....
  The IRIX 6.2 compile was tested on 5.3 and 6.4 and runs fine. The Solaris 2.5 compile was tested on 2.3 and it also runs fine.
  Other versions of both Solaris and IRIX will probably also compile TNOS now without modification, but only the above listed configurations have been tested.
• Extensive improvements on self-configuration for Unix
  The build-make.inc script (which creates the default make.inc file) has been extensively enhanced to automatically setup TNOS for most any Unix. Several source files have had minor changes made to them to support this enhanced capability.
• Changed nearly ALL Unix/OS-specific code to feature-driven code
• Removed the need for TNOS/DOS users to find/install a DPMI manager
  From now on, the TNOS/DOS executables distributed from lantz.com will have a build-in DPMI manager. This DPMI manager (PMODE) does NOT support virtual memory, but does allow you to use all of the available physical memory in the machine. No special considerations need to be made. Just run the executable.
  If these executables are run in the presence of an existing DPMI manager, the PMODE code steps aside, using the better DPMI manager. Those who need to use virtual memory will want to use a DPMI manager that supports virtual memory.
• Added a Command Session command, 'timers'
  Primary will be used by the author as a diagnostic tool, this command displays the current contents of the timer queue, showing the process owning the timer, the timer's state and duration, and the time that the timer should next 'kick'.
• Added a 'http ftpdir' command
  This command sets the default FTP directory to use with URL's starting with '/ftp/'. If this is undefined (the default), then URL's starting with '/ftp/' will refer to a subdirectory within the normal http directory, using the normal methods of access.
  If the 'http ftpdir' is defined (or given on the 'start http' command line) then all URL's starting with '/ftp/' will be based out of the directory given. In addition, all files served within a defined ftpdir will display directory listings without the need of a 'welcome.html' file, bypassing this normal security step in the HTTP server.
• Added ability to attach 'dummy' interfaces
  This is useful for allowing TNOS to assume multiple IP addresses. The command is 'attach dummy <label> <ipaddr>'.
• Added back a new version of the 'fstat' command
  The original 'fstat' command was a MSDOS-specific command, and was never in the UNIX version of TNOS. For consistency it was removed from the MSDOS version when the DJGPP port was done.
  This version gives a little more information, and is OS-independent. It is done by putting a wrapper function around the standard fopen/fclose/tmpfile functions, saving information about the file into a table, then calling the real version of the desired function.
  The output of the 'fstat' command gives the name of the process owning the file, the time it was opened, the file's length and current position, the access mode that the file was opened with, and the file's name.
  These changes also has the benefit of preventing files opened by a process from remaining open after the process completes, as now in the killproc function all open files of a process are closed. There were a couple of places discovered that opened files using the tmpfile function, and could exit the process without closing them. Rather than check/change all occurances in the code, I just added this code in killproc, which emulates the way that C handles open files with normal processes.
• Added code to attempt to prevent needless restarts
  If a spuratic SIGSEGV signal is received (and DUMP_CORE is not defined), then the UNIX version will attempt to recover and continue TNOS, rather than exiting. The resume event will be logged to the logfile (if active) and will be displayed to the Command Session screen. This resuming will only be allowed to be attempted up to defined number of times per execution of TNOS, so that a persistent error will cause an exit, eventually. Currently the default is to allow up to 20 resumes.
  The recovery method varies depending on the process that encountered the error. If it is one of the required Daemon processes or it is one of the servers started with a 'start' command, then they are restarted from the beginning, with the same parameters that they initially were started with. If the process was not a Daemon or a server, then we simply kill the running TNOS process.
  The number of times the TNOS kernel has resumed (and the current number of times that a resume will be allowed) can be found in the output for the 'kstat' command. Also this display shows how many times (of those times that a resume occurred) that a Daemon or server was restarted.
  Note: no attempt to resume is made if the process that encountered the SIGSEGV was the Command Session.
• Added an 'attach kernel' command for TNOS/Unix under Linux
  This (taken from wampes and modified extensively for TNOS) allows you to attach directly into the Linux kernel's protocol stack, and is primarily used to interface with Linux ax25 devices or to connect to Linux applications written to utilize the Linux kernel ax25 devices. Experimental, and not yet tested!
  I have began an attempt to use the same method to eliminate the need to use a slip pseudo-tty to communicate with the kernel, instead sending the IP frames to the kernel protocol stack directly. At this point it can communicate with everything downlink, but not TO the kernel, itself, when connected to the ethernet device. Also getting stray duplicate packets.
• Redirection of Command Session output added
  Now any Command Session command can be followed with a '>filename' to redirect output from the command to that file. Well, not really redirect, as you still get the output on the console. What is really being done behind the scenes is the equivalant to doing a 'record filename' to the Command Session for the course of that command. (Note, you cannot do a 'record' command to the Command Session, as it is not a normal session.
  This also works with multiple commands on the same command line, though each separate command (at this time) would need it's own redirection, if that is what is desired, as there is no way to combine several commands output together.
  For example, to place the output of the 'ps' and 'socket' commands to a file named 'data', you could do either:

          ps >data
          socket >data
  

  or you could do the same thing with:

          ps >data ; socket >data
  

• Added commands to set a security profile's password
  Added the Command Session 'profile passwd' and PBBS 'passwd' commands. These allow the sysop to change a passwd for a user, without having to manually edit the 'security' file.
  In addition, a user can (under certain circumstances) change their own passwd without requiring sysop intervention. This can only be done if:
  1. The user is in the 'security' file
     This means that anonymous users cannot set passwords.
  2. The user was authenticated with a password
     This means that they either connected by telnet, or the system has the 'pbbs ax25password' command set to always authenticate users.
  Users with 'sysop' permissions can change any users' password, but only from the Command Session, or if they logged in, authenticated with a password.
• Added commands to add a new security profile
  Added the Command Session 'profile add' and PBBS 'profile add' commands. These allow the sysop (locally or remotely) to add a new security profile to the 'security' file, without having to manually edit the 'security' file.
  This can only be used from the Command Session, or if an individual with SYSOP permissions logged in, authenticated with a password.
• Added a ax25 loopback device
  To use this device, do an 'attach axloop' command. Set any needed parameters on the newly created 'axlp' interface, and it's ready to use.
• Added a dumb node-like application
  For those wanting a front-end that looks like a normal Netrom node (that is, non-verbose, with only a few commands), you can now define a 'node call' and connects to that call will go to this new node application. The commands within the node are self-explanatory, and the 'help' and '?' commands list them.
  The current internal node commands are:
  • ?
    Give short list of all commands
  • Bye
    Bye (ie. disconnect)
  • Connect pt cl
    AX.25 connection, if permitted on port 'pt' to call 'cl'
  • CONFerence #
    Conference bridge entry (optional initial channel number #)
  • Help [subj]
    Help - get help on a subject
  • Info
    Information on this system
  • Jheard
    Just heard, on all ports
  • Jheard port
    Just heard on 'port'
  • Nodes
    List all netrom known nodes
  • NRoutes
    List all netrom neighbor routes
  • Pbbs
    Connect to the corresponding PBBS
  • POrts
    Give a list of the ports of the system
  • Talk
    Chat with operator (if system is attended)
  • Telnet host
    Telnet to 'host' (if permitted)
  • Quit
    Quit, same as 'bye' (ie. disconnect)
  • Users
    Shows current mailbox users
  The node's 'PBBS' command will do a 'C xxxx' to the 'node bbscall' callsign, if it is defined. If the 'node bbsinterface' is also defined, then it will do a 'C ifc xxxx' connection. This allows you to divert the node's PBBS command to another PBBS. If the 'node bbscall' is not set, a 'PBBS' command will do a 'telnet localhost' to the TNOS PBBS. Only real difference is that login/password prompting occurs.
  To avoid the login prompting, do an 'attach axloop', set the interface parameters appropriately, and define the 'node bbscall' to be the call of the PBBS, and the 'node bbsinterface' to be 'axlp'.
  The 'INFO' command simply displays the 'NODEInfo' file, and the 'HELP' command uses the 'NODEHelp' file.
  While it may appear to be different than the PBBS, internally the NODE is using the PBBS routines to do almost all of its work.
• Added the Command Session 'node' command and its subcommands
  This command is used to alter the settings/characteristics of the NODE application. The various subcommands are:
  • node alias
    Sets the alias assigned to the node. If this is set, then this callsign will ALSO route to the node application. This is an optional subcommand, if the 'node call' command is used. Either 'node call' or the 'node alias' must be defined to route users to the NODE application.
  • node banner
    Sets an optional banner string to be displayed on initial connect. While some will want a completely silent node, others will prefer at least SOME output, so that the user knows he got there fine. If this command is NOT defined, then no output will be given on connection.
  • node bbscall
  • node bbsinterface
    The 'node bbscall' and 'node bbsinterface' commands affect the action taken with the NODE's 'PBBS' command is given. If neither of these commands are given, then the TNOS PBBS will be connected to. The method used to connect to the TNOS PBBS depends on whether or not the ax25 loopback interface 'axlp' is attached. If the 'axlp' interface is found, then it is used, and the connect is ax25, as if the user had entered a 'C axlp mycall' command. If the 'axlp' interface is not found, then a 'telnet' is used, as if the user had entered a 'telnet localhost' command.
    If the 'node bbscall' is defined (but the 'node bbsinterface' is NOT defined, then the PBBS named in this command is connected to via netrom, as if the user had entered a 'C call' command. The named PBBS must be accessable via netrom.
    If the 'node bbscall' and the 'node bbsinterface' are both defined, then the named PBBS will be connected to on the named interface, as if the user had entered a 'C ifc call' command.
  • node call
    Sets the callsign assigned to the node. If this is set, then this callsign will route to the node application. This is an optional subcommand, if the 'node alias' is defined. Either 'node call' or the 'node alias' must be defined to route users to the NODE application.
  • node gatewayexit
    This command, if set, will make the NODE application automatically disconnect all users after they return from a gateway command (Connect, Telner, or Pbbs). If this command is NOT set, they will return back to the NODE application.
  • node netrom2node
    This boolean command can be used to intercept the Netrom callsign, and instead divert it to the NODE application.
  • node nralias2node
    This boolean command can be used to intercept the Netrom alias callsign, and instead divert it to the NODE application.
  • node showid
    This can be used to view the ID string that the NODE currently is using. The ID string varies depending on the values of the 'node alias' and 'node call' commands. If both are defined, the string is 'node:call}'. If neither command are defined, the string is 'NODE}'. If only one of the commands are defined, then the string is 'callsign}'.
• Added a PBBS 'tnode' command to directly enter the NODE application
• All the above included in 2.30b1
• Added 'start/stop fbbtelnet' commands for incoming FBB telnets
  While outgoing FBB telnets have already been hacked to work (FBB improperly uses <CR><LF> instead of just <CR>), incoming did not work. Now you can (if needed) 'start fbbtelnet' and a listener process will be waiting for FBB incoming connections on port 2323. The remote FBB will need to be configured to connect to that port number.
  If you wish to change the port number being listened to, you can, in the same way as with the telnet server.
  The ONLY difference with fbbtelnet from telnet is that the end-of-line sequence is made into <CR><LF> for fbbtelnet.
• Changed the 'profile newprofile' commands to 'profile add'
  The older name was only around for beta 1 of this release.
• Added a 'profile usermodifyable' command
  This allows the sysop to choose whether or not the end users (non-sysop users) are allowed to change their own passwords. The default is disabled.
• Added a 'profile fileext' command
  Since several TNOS users (including the author) use several different security files (included by the top level 'security' file) and would not want the 'security' file itself being altered, this command allows you to have, for example, a 'security.users' (or 'security.usr' for DOS) file, and place users who can alter their passwords in this file.
  If this command is not defined, then no extension is used, and the 'security' file itself is used for the 'profile add', and 'profile passwd' Command Session commands (and the 'newprofile', and 'passwd' PBBS commands).
• Added commands to change a security profile
  Added the Command Session 'profile change' and PBBS 'profile change' commands. These allow the sysop (locally or remotely) to change an existing security profile in the 'security' file, without having to manually edit the 'security' file.
  This can only be used from the Command Session, or if an individual with SYSOP permissions logged in, authenticated with a password.
• Added commands to list a security profile
  Added the Command Session 'profile list' and PBBS 'profile list' commands. These allow the sysop (locally or remotely) to list an existing security profile from the 'security' file, without having to manually edit the 'security' file.
  This can only be used from the Command Session, or if an individual with SYSOP permissions logged in, authenticated with a password.
• Added commands to delete a security profile
  Added the Command Session 'profile delete' and PBBS 'profile delete' commands. These allow the sysop (locally or remotely) to delete an existing security profile from the 'security' file, without having to manually edit the 'security' file.
  This can only be used from the Command Session, or if an individual with SYSOP permissions logged in, authenticated with a password.
• Added uuencode capability to the PBBS 'upload' command
  As a complimentary operation to the 'DU' (download and uuencode) command, there is now a 'UU' (upload and uudecode) command. The file is saved in the filename specified in the command line (that is, the filename in the 'begin' line of the uuencoded file is ignored). Any data before the 'begin' line or after the 'end' line will be ignored.
  If the 'security createsecure' command is 'off', then the file mode listed in the 'begin' line will be preserved as-is. If the 'security createsecure' command is on, then the file mode listed in the 'begin' line will be masked against the value of the 'security createperms' command, and only permissions allowed in the 'security createperms' command will be preserved.
• Added protection against SIGSEGV around free() calls (Unix version)
  When a gremlin in TNOS modifies another processes memory, usually a memory pointer gets corrupted. When the pointer attempts to free the memory it held, it usually results in a crash, with a SIGSEGV.
  While there is no way to determine what that pointer used to be and free the proper memory segment, we can prevent the attempt to free the memory from crashing the TNOS application.
  The number of times that a free resulted in a SIGSEGV (that recovery was possible) is now found in the 'kstat' command's output.
• MAJOR internal overhaul of the Converse Server code
  While nothing is visible externally, the code for this server was looked at under a microscope and all potential problems related to possible buffer overflows (due to remote sites running broken servers, sending erroneous data) have been eliminated. Though hard to immediately prove, the author believes that TNOS stabiltiy will improve even more due to this. Many occasional periods of instabilty are coincidentally linked to times when experimental converse servers are causing havok on the non-TNOS converse servers, too.
• Added a Command Session 'shutdown' command
  This is a convenience command, which provides an easy way to notify all users of a shutdown. The syntax is one of:

          shutdown <delayinseconds> "message"
          shutdown now "message"
  

  The "message" string must be surrounded by quotes or braces, as the string must be seen by TNOS as a single argument. The first parameter can either be the string 'now' (which is treated the same as with a delay value of '0'), or it can be a delay value (in seconds). If the delay value is non-zero, then a message will be sent to all users immediately, telling them of how many seconds till the shutdown, then the function will delay that many seconds.
  After the delay time (if any) a message will be sent to all users, telling them of the shutdown. Then a final five second delay will be done, to allow all output to have time to flush. After this, TNOS will exit.
• Added timer statistics to the output of the 'timers' command
• All the above included in 2.30b2
• Added a 'ip routesame' command
  This command controls whether or not an IP packet is allowed to be routed back out the same interface it was received on. The default for this command is 'off'. Normally, enabling this will leave the system open to being an unwilling participant in eternal routing loops, if a remote system is mis-configured. If you know you have a need for this, enable it. Otherwise the default of 'off' is probably safe.
• Added a 'crashprotect' Command Session command
  This functionality is disabled in production releases of TNOS, as it should be used only for diagnostic purposes.
  TNOS inherited its code base (once upon a time) from JNOS. While JNOS (and even TNOS, prior to the port to DJGPP) *seems* relatively stable, this is mostly due to MSDOS allowing writes to random memory. There have been (literally) nearly 1000 hours of cleanup and debugging by the author to clean up the code base, and make TNOS rock-solid stable. While for most users this is a reality, for some it is not. Some components of TNOS (with certain conditions) can get confused and write to memory owned by other TNOS internal processes. The offending process usually does NOT have a problem, but causes one for the process that now has corrupted memory. The victim process usually crashes TNOS.
  Once again, most users do not see this. The author does, and that is mainly because the ko4ks.ampr.org site runs nearly all of the functionality of TNOS, so that it is thoroughly tested. This makes it hard, though, to trace down exactly which application(s) are causing the problem.
  The 'crashprotect' command (which defaults to off) allows the SYSOP to disable the protections added in TNOS 2.30 to prevent crashes when one process corrupts another processes memory. Some SYSOPS would rather have the system recycle rather than possibly have some component in the system unstable. Others would rather have the individual process or corrupted timer ignored and have the system do its best to continue. This command allows both.
  The 'crashprotect' command affects whether or not the SIGSEGV protection (on UNIX only), the corrupted process table protection, and the corrupted timer table protection are to be used. If the 'crashprotect' is 'off', then any of these events will cause an immediate, orderly exit. Those wishing to debug these exists will need to place a breakpoint at either the function named 'crash_it_already', which is only included as a place for easily catching this shutdown in a debugger, or at the function named 'shall_we_crash', which is called earlier, at the point where the 'crashprotect' setting is being looked at to determine whether to protect or crash.
  If the 'crashprotect' is turned 'on', then these events will be protected, and individual processes encountering the errors will do their best with the situation.
• Some NNTP enhancements/fixes from Gareth
  The first one makes the 'nntp ihave' work as it was intended. Setting the 'nntp ihave' to 0 will now reject any incoming news articles attempted to be forwarded by another host using 'ihave'. A value of 1 for 'nntp ihave' permits inbound news from a server using 'ihave', while setting 'nntp ihave' to 2 engages the 'ihave' pusher to send news from the local TNOS.
  The rest are the addition of the LISTGROUP command from Stan Barber's draft nntp extensions, together with the LIST EXTENSIONS and MODE READER commands. This makes it possible to use (at least) the 'pine' mail and news reader with the TNOS NNTP server.
  Also from Gareth are these notes on pine and TNOS nntp, as a Getting started with pine and nntp
  1. Choose SETUP from the main menu
  2. Select 'C' for config
  3. Set 'smtp server' and 'nntp server' to your TNOS's hostname
  4. Optionally you can set the 'inbox-path' to the path of your own TNOS mail file (e.g. /nos/spool/mail/g4hip.txt)
  5. Set the 'news-collections' entry to point to your TNOS site, *{your.tnos.hostname/nntp}[] (e.g. *{pellaz.g4hip.ampr.org/nntp}[])
  6. Then 'E'xit config, and confirm the changes then Quit from the main menu and restart pine.
  7. After restart, head for 'folder collection' menu item on the main Pine screen and move the bright-up bar to the newsy bit at the bottom. Type: A then wait for an invitation to list a group.
     Type something you expect to see in the newsgroup name you want to subscribe to, (e.g. ampr) as there doesn't seem to be a way of getting a list of everything. Then use ^X to bring up a list of matching newsgroups. Select from the list a newsgroup or two to subscribe to, and take things from there.
  Note: If you use Pine to DIRECTLY alter your TNOS mail file, the TNOS index file is NOT updated, so you will either need to do a 'buildctl xxxx' (where 'xxxx' is your mail area name) or only access your TNOS mail area from Pine and NOT from within TNOS.
• Added an 'ax25 counters' command
  Several counters have been added to support this command, to allow the sysop to get a better understanding of the performance of his ax25 connectivity. Counters were added for each ax25 interface for the following:
  • Total Frames - in and out
  • Data Frames - in and out
  • Frame Segments - in, out and errors
  • RNR Frames - in and out
  • REJ Frames - in and out
  • Retries sent
  • FRMR Frames received
  The 'ax25 counters' command can give these counters for all interfaces (if no other parameters are given), for a single interface (if only one parameter is given) or for multiple interfaces (if multiple parameters are given).
• Added a PBBS 'counters' command
  This gives the same display and takes the same parameters as the 'ax25 counters' command described in the last item.
• Added ability for TNOS to assist in part-time gateway routing
  Inspired by mfnos, the 'remote' command has been enhanced to allow trusted remote sysops to add gateway encap routes to their site which run with non-static IP addresses. After completing the TNOS implementation of this feature, the author shared the code with the author of MFNOS, who seems to have chosen to add the password protection that the TNOS implementation required.
  As with one of the long-standing design rules of TNOS, commands will not be added which either jepardize the security of the site, or prevent the sysop from being in complete control. This command is no different.
  The complete revised list of uses of the 'remote' command are:
  1. remote [-p <port#>] [-a <kickaddress>] <hostname> kickme
  2. remote [-p <port#>] -k <key> <hostname> reset|exit
  3. remote -s <password>
  4. remote [-p <port#>] -k <key> -r <destIPaddr>[/<bits>] <hostname> add|drop
  5. remote -g <gatewaypassword>
  The new additions are the last two entries. The last line adds a gateway password used only by entry number 4. The '-s' password is only used for the 'exit' and 'reset' commands. The '-g' password is only used for the 'add' and 'drop' commands from entry number 5.
  For a remote system to add a route to your TNOS:
  1. You MUST have a TNOS compiled with the ENCAP flag enabled.
  2. You MUST enable a gateway password with the '-g' sub-command.
  3. The remote site must also be running TNOS (version 2.30 or later).
  4. The remote site MUST have a TNOS compiled with the ENCAP flag enabled.
  5. The remote must issue an 'add' command, probably in their 'autoexec.nos' file, using the proper gateway password.
  The restriction of number 3 may be unnecessary if other xNOSs implement this functionality and do so in the same manner. I am told that the next version MFNOS should be compatible.
  Remote systems using this functionality should have a 'drop' command in their 'onexit.nos' file.
  The easy way to see if you have a TNOS with the ENCAP flag enabled is to do a 'ifconfig' command, and see if you have an 'encap' interface.
  When a proper 'add' command is received (with a proper password), a private route is added to your routing table for the 'destIPaddr' the remote specified, added to the routing for the encap interface. The address that the remote command came from is the address that the routing for the encap interface will use. For example, if a remote system with a non-static ip address of '4.5.6.7' sent a 'remote -k xxx -r 44.2.3.0/24 ko4ks add' command and 'xxx' was the gateway password at ko4ks, then this is the same as if the following command were entered at the ko4ks Command Session prompt:

          route addprivate 44.2.3.0/24 encap 4.5.6.7
    
  

  Note, that the route string specified by the '-r' parameter MUST be a '44.x.x.x' address, and the address that the packet is received from must NOT be a '44.x.x.x' address, but must be the non-ampr, static IP address. Also, an attempt to use a route string of '0.0.0.0' (to re-define the default route) is ignored.
• Added 'stats http' commands
  Like the other 'stats' subsystems, the HTTP stats subcommand keep track of hourly, daily, monthly, yearly, and general information, which for the HTTP server is the number of total requests and the number of those requests that were directed to the PBBS (if the HTTPPBBS compile flag is enabled).
  Note that the TNOS browser does a 'look-ahead' for each URL it fetches, by doing a 'HEAD' command, looking at the headers, and determining whether or not it can render the data of the URL or if it is only available to be downloaded. So, when you 'hit' a TNOS server from a TNOS browser, the actual requests are TWO.
• Added a built-in HTTP status page to the HTTP server
  The predefined URL of '/status' (or '/status/') will render an HTML page dynamically that gives details on the HTTP server and its status. This is not configuratable in its output. You CAN disable this special built-in URL, using the new 'http statusurl' command. The 'http statusurl' command is enabled by default.
  The statistics from the 'stats http' subcommands are included in this dynamically rendered URL, if the STATS_HTTP compile flag is enabled.
• Enhanced (some would say fixed) the 'ip access' usage
  The previous releases of TNOS (and JNOS, etc) treat the 'ip access' command in a way that is not entirely intuitive. If no entries for an interface exist, then the interface is assumed to be open, which is fine. And if an interface has any entries, then there must be a rule permitting the access, which again is fine.
  The problem is, that it is not exactly intuitive. If you wish to deny certain UDP ports, then you add an 'ip access deny udp ....' command, right? Well, without ALSO having a line permitting all other ports, you basically deny all ports by virtue of having now defined access permissions without a default rule.
  So now, when an 'ip access' command adds either a deny or permit permission for a UDP or TCP port, a check is made to see if this port is already covered by an entry. If it is not, then a default inverse set of permissions is defined for that protocol.
  A by-product of the old treatment of 'ip access' was that if, for example, the TCP port 3600 was denied to anyone, then unless otherwise stated, then all UDP ports (and all other protocols) were ALSO denied. Really kinda hard to see how it all worked, huh! ;-)
  Even more problems found and fixed, in that the ORDER of the entries made a difference, and while you may THINK that you had a 'deny' entry in there, it might have been overridden by a global 'permit' of all other ports!
  ALSO a note: Many misunderstand the purpose/scope of the 'ip access' command. This command ONLY only deals with IP frames being routed THROUGH your site. It does NOT affect frames coming addressed TO your site! You use the 'tcp access' command for restricting your own TCP ports. There is NO equivalent 'udp access' command, though, for blocking UDP packets addressed to your site.
• Enhanced (some would say fixed) the 'tcp access' usage
  Yep, you guessed it! The 'tcp access' was equally counter-intuitive! So now, when an 'tcp access' command adds either a deny or permit permission for a TCP port, a check is made to see if this port is already covered by an entry. If it is not, then a default inverse set of permissions is defined.
  A by-product of the old treatment of 'tcp access' was that if, for example, the TCP port 3600 was denied to anyone, then unless otherwise stated, then all TCP ports were denied to EVERYONE. Really kinda hard to see how this worked, too! ;-) Even more problems found and fixed, in that the ORDER of the entries made a difference, and while you may THINK that you had a 'deny' entry in there, it might have been overridden by a global 'permit' of all other ports!
  
• Added a 'udp access' command
  Works the same as the 'tcp access' command, with the changes mentioned in the previous entry.
• All the above included in 2.30b3
• Added an optional 'unbuffered' parameter to the trace command for files
  If you are tracing to a file and wish to 'tail -f' it to also see the data in real-time, or if you wish to trace to a TTY (console or serial port) and wish the data to be unbuffered, then just add 'unbuffered' (or actually only the 'u' is needed) to the trace command, after the filename. This is not suggested for simply logging the information, only if you also need to see it without buffering. Unbuffered file I/O uses an order of magnitude more CPU to do the same work.
• The 'crashprotect' command ONLY enabled for alpha code
  As this is for diagnostic purposes only, the command is disabled for production releases. It's use by anyone else but the author is discouraged!
• All the above included in 2.30b4
• Added a new client/server protocol for adding dynamic gateways
  Like the extensions to the 'remote' command, this new protocol can allow a remote TNOS server to make available ENCAP routing for a client that has a dynamic IP address. The server for this protocol is activated with a 'start router' command. The client is activated with a 'start dynamic' command.
  Both the client and server use a configuration file, that (while different in usage) is identical in file format. The server's file is located at 'etc/routesvr.dat' and the client's file is at 'etc/encap-rt.dat'. Each of these files can have blank lines or lines beginning with a '#', which are treated as comments. All other lines have two fields, surrounded by any amount of white space. The first field is a route string, and can be any route address (with optional '/bits') that is valid for the third parameter of a 'route add' command. The second field is an authentication string, used for security.
  For the server, this file contains all of the dynamic routes that will be allowed to be added by remote sites. Each route must be authenticated with the authentication string by the client application to be added. This one file contains all possible routes that can be added by all possible clients.
  For the client, this file contains all of the routes that are desired to be added to the server's routing table. The authentication strings in the client's 'etc/encap-rt.dat' file must match the corresponding authentication string in the server's 'etc/routesvr.dat' file for the route string specified.
  When the client/server connection is broken (due to either side going away), the client's routing is removed from the server machine.
  A Unix stand-alone version of both the client and the server will also be made available, for compatibility.
• Removed the experimental AX.25 Negotiation extensions code
  The compile flag 'AXNEGOTIATION' is removed, along with it's code, which includes the 'ax25 negotiate' command.