TNOS Release Notes - Release 2.30 Brian A. Lantz, brian@lantz.com v1.00, 14 September 1997 These are the FINAL Release Notes for release 2.30 of TNOS. Hope- fully, this list of changes will give you an idea of the scope of work that has occured since the release of TNOS 2.22. ______________________________________________________________________ Table of Contents: 1. Important Notes 2. Bug Fixes 3. Improvements and Enhancements 4. Minor Changes 5. Remaining Known Bugs 6. To-Do List 7. Known Quirks ______________________________________________________________________ 1. Important Notes The following are important notes that you CANNOT afford to ignore: o The 'ftpusers' file has been renamed to 'security' While still located in the 'etc' directory off of your TNOS root directory, the name has been changed to better describe its usage and to prevent newbies from believing that it is just important to the FTP server. o The statistics files now are stored in binary format If you have NOT been using the 'stats' commands or you do not have the 'STATS' flag compiled into your TNOS, you can ignore the rest of this item. If you do not need to preserve your existing statistics, you can simply delete all of the files in the 'spool/stats' directory before starting up Release 2.30 for the first time, or you can leave the files there, though they will never be used by TNOS 2.30 and greater. The new binary stats files are named the same, except that they have a '.dat' file extension added. To convert existing ASCII statistics files to binary ones, use the new 'statconv' utility. Do the following commands in your 'spool/stats' directory: statconv import area area area.dat statconv import forward forward forward.dat statconv import message message message.dat statconv import traffic traffic traffic.dat statconv import usage usage usage.dat o The '>' character is now a special character in command lines This only applies to commands entered from the Command Session, those commands in your 'autoexec.nos' file, and commands you might have in optional script files that you 'source' in. Since the '>' is now used for output redirection, you must change the '>'s in these commands to '\>', to 'escape' the '>', and prevent it from being interpreted as a special character. Also, the parameter that contains the '\>' should either be enclosed in quotes or {}'s, o Either follow the 'readme', or do a 'build-make.inc' If you are building your own TNOS under Unix, you MUST have a new 'make.inc' file. Running the 'build-make.inc' script will create the new one for you, and will name any existing 'make.inc' file to 'make.inc.old', in case you have customizations that you'd like to add to the generated 'make.inc' file. This set also creates the new 'system.h' file. 2. Bug Fixes The following bugs have been squashed. o Fixed a very obscure bug with XFWDing Only affected XFWDing connections with areas using the 'rewrite address' functionality for the area. A rare combination. Released a quick patchkit.1 to release 2.22 to fix this, just in case others needed it. o Fix for MSDOS packet driver for short packets o Fixes for FBB/X forwarding to prevent rare looping If an FBB forwarding session was active, and all messages in the queue were deferred by the remote side, the code would re-loop continually. While this is a rare condition, it was nonetheless annoying when it occurred. o Fixed an inconsistency with 'if' command when expression is false o Fixed MSDOS FTP 'pwd' buglet o Fixed MSDOS FTP 'lcd' buglet (also affected 'cd' command) o The above included in 2.22pl2 o Fixed problem where areas files required space even w/out description o Fixed problem preventing FBB telnet hack from working o Fixed problem w/overly aggressive chopping of haddresses when forwarding o Fixed a remaining problem w/MSDOS packet driver and short packets o Fixed incorrect number of lines in command session flowmode o Fixed a RARE buffer overflow on MBL-style forwarding and long haddresses o Fixed (??) the 'Invalid Gateway' entries and PBBS users exceeding tdisc o Changed few remaining C++-style comments to C-style o Fixed occasional crash if HTTP received from unresolvable address o Fixed a bug where ping responses to the console where not displayed o Fix for preventing attempted forwarding of messages w/out BID/MID o Fixed occasional false pings of negative rtt These were only observed in TNOS/DOS under the Linux DosEmu, but could have occurred in other environments as well. o Fixed problem with smtp mqueue parsing in Win95 Dosbox This would cause a 'smtp list' display to scroll continually, and a 'smtp kick' to not work. Seems that DJGPP is close but not exact on their implementation of the findfirst/findnext functions (at least the release of DJGPP that I use; later release may have fixed this). While the return value is supposed to be zero for success, and -1 for failure, the DJGPP version uses 0 for success and non-zero for failure. The existing code looked for -1, and otherwise assumed success. This has been changed, and seems to fix the problem. This was hard to find, because the DJGPP library was not consistent in its return values, and under DosEmu and pure MSDOS, it worked as expected. In a Win95 Dosbox, though, it was broken. This same bug would also cause the Command Session 'copy' and 'delete' commands to not work properly. While many pieces of code use the findfirst/findnext functions, only these needed changing. o Fixed TNOS/DOS bug with session flow control o Fixed assorted conditionals that prevented not setting ALLSERV o Fixed where the '-S' and '-T' command line parameters were getting trashed o Fixed HTTP problem where directory contents not properly displayed o Fixed HTTP problem where sub-directory listed as files in directory listings o Fixed HTTP problem where directory files were always converted to lowercase o Fixed several potential domain lookup problems This was due to several places not checking the return value from the getpeername and getsockname functions. o Long-standing problem identified (and fixed?) There has been a mysterious problem where TNOS has at times 'lost' active processes. This has mainly been noticed by occasionally having the statusline daemon go inactive. There seems to be some problem with the handling of the process tables, when a processes is in 'waiting' state. The changes made here will hopefully fix the problem. Only time will tell... o Added code to detect/prevent corrupted process table entries o Added code to prevent race condition adding Converse users/groups o Fixed truncated names of built-in fingerd 'users' o Fixed bug with PBBS 'sf' and no header data o Fixed XFWD bug when all incoming msg in a proposal are refused o Fixed XFWD bug with handling the reject.dat file This was obscure, as it only occurred with BIDS starting with 'S' or 'F'. o All the above included in 2.30b1 o Fixed output redirection '>' to be ignore in comment lines o Fixed bug where AXUI would not receive frames w/remaining digi's o Fixed command parser to ignore special characters in comment lines This includes quotes, braces, backslash, and semi-colon. Now, a comment line (starting with a '#') cause the rest of the line to be discarded and not interpreted specially. You can place a comment at the end of a command (preceeded by a semi-colon), but NOT the reverse. Once a comment is started, no processing is done of the rest of the line. o Fixed an obscure bug with 'pbbs nosubjbell' o Changed some of the timer code to prevent possible problems o Fixed problem w/'repeat' command not clearing screen each pass o Fixed problem w/look command and the 'chat' subcommand o Fixed a typo in config.chk, which caused contention between POP/POP3 Only happened if you didn't define POP3CLIENT. o Fixed problem where PBBS users could access Converse server, even when it was off o Fixed assorted potential buffer overflow sections of code o Fixed added <LF> after remote messages received in Converse Server o Fixed Converse problem where channel 32767 was always treated correct o Killed one gremlin ;-) Now delete all timers owned processes when killed Previously, only the alarm timer was stopped (i.e. deleted from the queue), which was (I am SURE) at times causing occasional weirdness, as the process started by the expired timer (and the data it pointed to) were no longer what/where it was when the old process was alive. This would have previously left a 'loaded gun' timer each time that a user of the PBBS was gateway'ed out to a remote site, and they timed out due to their inactivity. While the inactivity timer was removed from the timer queue when it expired, the separate timer on the gateway was NOT removed. Timers for AX25/TCP links may also have (at times) fell through the cracks and been left enabled long after the process that started it completed. Doubtless not the LAST gremlin, but definitely this one was a player ;-) o Changed the internal way that processes are added to process tables This, in addition to being faster will prevent the possibility of getting tied up in a loop trying to add a process to a process table. Now, in addition to a pointer to the head of the linked list, we now also keep a pointer to the tail of the list. Adding to the end of the list is a simple, quick event, now. o Fixed minor problem with PBBS 'sr' command and some mini-editor commands o All the above included in 2.30b2 o Fixed problem with 'review' command not saving area changes o Fixed minor compilation combinations with certain features disabled o Fixed a minor problem with 'pbbs strictcall' and MBL forwarding o Fixed a minor cosmetic problem with buildcat o A fix for an obscure 'ax25 smartroute' problem o Fixed case where FBB forwarding would report false protocol errors This would happen when you had an outbound FBB proposal which the other side rejected all of the messages from, and then the other side had data to send to you. At times, the first line of the remote's proposal was getting improperly eaten, causing the proposal's checksum to be bad. o Minor fix to build-make.inc script for older ncurses o Fixed problem with 'look' not always seeing disconnected user o Fixed two problems by checking for catalog file in startup o Fixed a problem with setting the 'wp clientcall' o Fixed 80 column 3rd status line with >80 column displays o All the above included in 2.30b3 o Fixed a timer bug, added in earlier beta code o Fixed new 132 column 3rd status line bug o All the above included in 2.30b4 o Fix for backspace (and column 0) with displays > 80 columns o Fixed a problem with scripted forwarding sessions Don't know when this one crept in, but the first line of a forwarding script would (at times) be sent twice, and cause difficulties at the AX.25 level. This probably is related to the timer changes in this release, but it may have existed in pre-2.30 releases. 3. Improvements and Enhancements The following optimizations and improvements have occurred. o Converted statistics files from ascii to binary This increases loading/saving speed, reduces the chance of corruption, and uses less disk space. o 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. o Added a 'AH' PBBS sysop command, to display only areas with held messages o 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. o 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. o 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. o 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. o 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. o 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. o Changed nearly ALL Unix/OS-specific code to feature-driven code o 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. o 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'. o 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. o Added ability to attach 'dummy' interfaces This is useful for allowing TNOS to assume multiple IP addresses. The command is 'attach dummy <label> <ipaddr>'. o 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. o 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. o 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. o 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 o 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. o 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. o 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. o 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: o ? Give short list of all commands o Bye Bye (ie. disconnect) o Connect pt cl AX.25 connection, if permitted on port 'pt' to call 'cl' o CONFerence # Conference bridge entry (optional initial channel number #) o Help [subj] Help - get help on a subject o Info Information on this system o Jheard Just heard, on all ports o Jheard port Just heard on 'port' o Nodes List all netrom known nodes o NRoutes List all netrom neighbor routes o Pbbs Connect to the corresponding PBBS o POrts Give a list of the ports of the system o Talk Chat with operator (if system is attended) o Telnet host Telnet to 'host' (if permitted) o Quit Quit, same as 'bye' (ie. disconnect) o 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. o 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: o 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. o 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. o node bbscall o 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. o 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. o 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. o node netrom2node This boolean command can be used to intercept the Netrom callsign, and instead divert it to the NODE application. o node nralias2node This boolean command can be used to intercept the Netrom alias callsign, and instead divert it to the NODE application. o 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}'. o Added a PBBS 'tnode' command to directly enter the NODE application o All the above included in 2.30b1 o 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. o Changed the 'profile newprofile' commands to 'profile add' The older name was only around for beta 1 of this release. o 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. o 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). o 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. o 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. o 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. o 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. o 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. o 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. o 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. o Added timer statistics to the output of the 'timers' command o All the above included in 2.30b2 o 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. o 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. o 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. o 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: o Total Frames - in and out o Data Frames - in and out o Frame Segments - in, out and errors o RNR Frames - in and out o REJ Frames - in and out o Retries sent o 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). o 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. o 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' com- mand 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 follow- ing 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. o 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. o 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. o 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. o 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! o Added a 'udp access' command Works the same as the 'tcp access' command, with the changes mentioned in the previous entry. o All the above included in 2.30b3 o 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. o 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! o All the above included in 2.30b4 o 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. o 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. 4. Minor Changes The following minor changes have occurred. o Removed some unused code in unixasy.[ch] o Cleaned up some potential memory overruns in xfwd.c o Added a 'DUMBPMS' attribute to the forward.bbs syntax o The above included in 2.22pl2 o Added hold count to the summary line for 'AN' and 'AS' commands o Added code to Unix version to decompress man files (if needed) o Cleaned up output of 'ps' command This actually involved making many changes to the various servers in TNOS to have them release the unused copies that they kept of the Command Session's sockets. Now the unused in/out sockets are not displayed. Also modified many servers to have them reflect the user/site connected as part of the process's name (where applicable). o Changed output of 'smtp rewritetrace' - first pass is now 1, not 0 o Added more trace information for forwarding using MBL/RLI method o Changes to build-make.inc/makefile.unx to better setup environment o Changes to build-make.inc/makefile.unx for CURSES Now, while older ncurses releases are still looked for, the default is to include curses.h, if no ncurses.h is found. For sites with newer ncurses releases, it defaults to what's needed, without needing to add a symlink of ncurses.h. If a regular CURSES library is used, all that needs to be manually changed is the 'LCURSES' from '-lncurses' to '-lcurses'. o Cleaned up premake and build-make.inc for /bin/sh There were some bash-specific items in there, which will now execute properly under vanilla-'sh'. o Unix 'make dep' no longer discards error messages o Added support for multiple-job compiles under Unix Uses GNU Make's ability to compile multiple components at once. The default is the same as before (i.e., compiles one file at a time). Unless you have sufficient memory (and ideally a SMP system) this is what you want. But, if you wish to parallelize your compiles, add a line in your make.inc file, of 'JOBS = x', where 'x' is the number of processes to allow concurently. Multiple concurent compilation is only active while the TNOS libraries are compiling, as most of the other few files MUST be processed before the libraries are started. o For consistency, changed 'pbbs mailfor timer' command All other timer commands set the timer, but do NOT kick it when it is being set. The 'pbbs mailfor' timer WAS kicking when being set. This has now been changed for consistency with the other timer-set routines. The only real impact is if you wish to beacon out the mailfor info on startup, you must now add a 'pbbs mailfor now' command to your autoexec.nos file. o Removed MAKEELF makefile variable (UNIX version) o Removed the 'stack' column from 'ps' display on all platforms As some platforms (not using SETSTACK) did NOT display the stack pointer and others did, there was an unneeded inconsistency. Since even the author wasn't using the stack pointer information, this will not be an impact on anyone. o Added number of lost signals to the 'kstat' command output o Increased number of signals that can be queued to 300 o Added visual indication to the status line to indicate flow mode on/off The first line will have the number of sessions surrounded in square brackets if flow mode is off for the current session, and surrounded in '><' if flow mode is on for the current session. o Added features map string to version info display This is the display produced by the Command Session 'version' command, the PBBS 'version' command and the finger of the pseudo- user, 'info'. o Alphabetized the devices in the 'attach' list ;-) o Added a logfile entry with the 'uptime' to shutdown messages o Added some missing trace lines to XFWD code o All the above included in 2.30b1 o Removed portion of code forcing Command Session into flow mode When coming BACK to Command Session from any other session, TNOS used to always force the Command Session's flow mode on. This no longer occurs. o Added to the Command Session's 'sendmail' command an implied smtp kick o Made all file buffers use TNOS mallocw routine Since TNOS already intercepts the fopen() and tmpfile() calls, code has been added to allocate our own buffers, but using TNOS's mallocw(), instead of allowing the C library to do its own allocation using the normal malloc() function. The difference is that the mallocw() function is a waiting (hence the 'w') function that will try repeatedly up to 150 seconds (in one second delays) if memory allocation fails. While under plain MSDOS, memory is either there or it is not, under UNIX (or MSDOS using a virtual memory DPMI manager), memory may NOT be available at the moment, but could be as soon as some cleanup occurs. This will complete the usage within TNOS of mallocw() and callocw(), to prevent any possible false memory failures. o Added a 'pbbs logintimer' command This command sets the amount of time (in seconds) that someone can remain inactive at a 'username' or 'password' prompt, before the login is timed out. By default, this is set to 180 seconds (3 minutes). Setting this command to '0' disables the login timeout. o Added ability to call 'exit' Command Session command in crontabs o Minor change in the handling of crontab This only affects the parsing of a crontab at startup. Previously, the crontab was parsed on startup, then it would sleep for 60 seconds. This meant that if, for example, you had an entry to 'exit' at a certain time, once TNOS would restart it would hit that same rule again, and restart immediately. It would continue to do this, until the next minute came. Now the crontab handler first sleeps 60 seconds, and then processes the crontab. This will prevent the spuratic restarts mentioned above. The only impact is that TNOS will delay 1 minute before making it's first crontab check on startup, which should have no adverse reaction to anyone's setup. o Added a way to disable netrom on an interface On analysis, it seems that there was previously no way to disable netrom from an interface, once the 'netrom interface' command was run for an interface. Now, a 'netrom interface <ifc> off' will disable netrom from any interface. o Added a Command Session console message when 'Exiting TNOS' o Changed internal tick interval from 55 ms per tick to 20 ms per tick Not a big change, except that any timer will only be as much as 20 ms longer than desired, versus the current state, where a timer could be 55 ms longer than needed. This may get changed to an even smaller value later. It really doesn't make any significant change, since the timer process is running (at the present time) several times for each 'tick'. While mainly a cosmetic issue, 55 ms per tick comes out to 18.181 ticks per second, and 50 ticks per second is more understandable. o Added ms to the expiration times in the 'timers' command o Combined router_queue() and queuejob() into one routine o All the above included in 2.30b2 o Added interpretation of special characters within browser tables o Found way to portably silence last two MSDOS compiler warnings o All the above included in 2.30b3 o Remove unneeded code in POP client o All the above included in 2.30b4 5. Remaining Known Bugs The following are known bugs that will be addressed in the near future. These may or may not be fixed before the next release is made available. 1. The proxy server scripts do not seem to work properly There is a problem, that is being looked into, which seems to be related to calling scripts from within scripts (which proxy.scr DOES). 2. None other at this time.... ;-) 6. To-Do List The following are things on the author's 'to-do' list that are being considered for this or a future release of TNOS. These may eventually be done, but not necessarily by the next release. 1. Complete the spec and coding of the non-IP HTTP PBBS interface 2. Consider adding to the browser support for the 'select' and 'textarea' tags 3. Consider adding to the browser better rendering of tables within tables 4. Export a complete set of CGI environment variables when 'exec cmd' used Currently you can execute a program and pass in explicit parameters (which CAN be dynamically assigned using server-side includes), but it is NOT a CGI-compatible interface. I will consider adding this at a later time. 5. Add capability to allow use of OS commands This includes finishing the incomplete 'pipe' command in the Unix release. Due to the obvious restrictions of MS-DOS (memory, etc.), this WILL be considered for Unix version only. 6. Consider adding better support for PBBS<->Internet mail address translation The 'translate' file and improved handling of aliases is a START, but more work needs to be done here. Maybe a 'translate.out' file... 7. Consider adding code to allow a TIP socket type, for use with LL Modems 8. Tweek the WPages code a bit Need to improve the code that insures that the wpagebbs entries are correct, of the proper length, and actually look like hier addresses. Also, make the expiring of WPages files less fragile if the file has become corrupted. 9. Check into duplicate entries in the WP files While not harmful, the WPages routines SHOULD be overwriting existing entries, NOT creating new ones. 10. Consider adding intelligence to convers links The idea being that if there are no incoming links, and no local users, that the remote outgoing link would be brought down until this changed. 11. Consider moving MSDOS version to curses for screen I/O 7. Known Quirks The following are known minor quirks that have no workaround... 1. The 'ls' command cannot represent disk/free sizes for LARGE disks If you have a file system with more than 4,194,303 blocks (a disk partition greater that 4 GIG), then the 'ls' numbers for disk size and free size will NOT be correct. This cannot be fixed, as the number cannot be represented in a 32 bit 'long' integer. Since this will not normally happen on Linux (except with NFS mounted drives), most Linux users will not even notice it. It cannot normally happen on Linux because the ext2 filesystem will not support partitions greater than 2 GIG. 2. None other at this time.... ;-)