Upgrading TNOS to release 1.13 http://www.lantz.com/Update1.13.html TNOS 1.13 will be the next release of TNOS, to be released sometime before the formation of the United Federation of Planets. Hopefully, this list of changes will give you an idea of the scope of work that has occurred between versions. Of course, it may be faster just to re-read the docs when the next version is released. New to release 1.13 is support for FreeBSD and other BSD variants of Unix. This document is divided into: * Bug Fixes * Improvements * Minor Changes * Known Bugs * To-Do List ------------------------------------------------------------ Bug Fixes: The following bugs have been squashed. * ARP Response bug fixed Thanks to an excellent bug report by Kurt Freiberger , there is another one dead, but the 1.12 release is already locked :-( The bug occurs when replying to an arp request. The response (incorrectly) comes from the Link address, NOT the IPCALL. Ron had helped me find the reverse situation, but this one sliped through the cracks. * AXUI Buglet in 1.12.... I didn't notice, but the AXUI application sends it's string with a trailing under Linux, instead of a trailing . Fixed now ;-) * Fixed some conditional buglets in expire.c w/WPAGES This kept you from compiling without WPAGES. Fixed now.... * Fixed the occasional 'ghost' statline in Linux version Several assorted fixes made this 'ghost' leave to haunt others. * Fixed bug in the maintainence code The expiry keep waiting for all BBS users to be off, even if maintainence mode was off. This is now fixed. Also added a 5 second delay after outputting the maintainence string before disconnecting, since the disconnect was in some cases too fast. * Infrequent 'SC' bug - understood and fixed.... There has been a known bug in that if you use 'SC' (or use the mini-editor '/c' command, sometimes not all of the copies get sent, if PBBS forwarding is used. I now understand the cause.... The PBBS *.fwd files store the area name and the message wrapper ID (not to be confused with the MID, or the BID). The message wrapper ID is the number found in the third line of the headers ' id AA1111'. Each message going through the smtpserver gets one of these. The BIDs generated are based on the MID, which IS unique for each copy of a message. Well, the bug occurs when two CC:s of a message get rewritten into the same area for forwarding. The first one will go out fine, but when the second comes up, it looks up the message wrapper ID, finds that it has been forwarded already, marks the 'errant' forwarding entry as done, and moves on. The code had no provision for having two messages with the same wrapper ID, though the forwarding code is the only spot that had a problem. This is now fixed. * TCPGATE bug fixed.... There was a bug with TCPGATE where if the socket was closed prematurely the program would lock up. This is now fixed. * BBS gatewaying timeout fixed WELL!! It seems that the tdisc NEVER worked for the gateway commands (connect, telnet, etc.), and maybe never did for ANY xNOS! This is also fixed. * BBS MM and MC commands number of arguments checked The maximum number of arguments was set to 20, and these commands sets up an array of message numbers, but there is no error check for too many messages. Fixed. * Long-time bug in FTP client code fixed The has existed in xNOS since probably day one a bug, that if you are doing an outgoing FTP session and the socket dies in the midst (from the other end or by you doing a 'reset' from the Command Session), xNOS dies a glorious death. This simple to fix but obviously elusive bug has now suffered the same fate ;-) * More exhaustive compiler warnings under Linux I've used the GCC compiler under Linux with just about every possible warning enabled, and have the code cleaned up even under the tighest microscope. * SMTP bugfix for long userids A bug where the SMTP userid could be received as longer than the available buffer for holding it has been fixed. * MSDOS BBS login with long username security bug fixed In the DOS version, a user could anonymously login with a name longer than 8 characters, and if there was a user with a login (exactly 8 characters) that matched with the first 8 characters, then that anonymous user would have access to the REAL users' mailbox, since for DOS we must truncate filename (usernames) to the first 8 characters. Now all BBS logins for MSDOS are checked, and if it is anonymous and greater than 8 characters, it is refused. This does NOT effect FTP, or any other login. ------------------------------------------------------------ Improvements: The following optimizations and improvements have occurred. * A Set Messagenumber command added to the BBS A new command, 'SM x' is added to the BBS, allowing you to quickly change the current message number for use with commands that act upon the current message. * New forwarding option... There is now a 'forward mycall' command, which (if set) defines the callsign used by outgoing forward sessions, regardless of the interface's linkaddr. If it is NOT defined, then the linkaddr is used, as before.... Thanks to Kurt Freiberger for the idea.... > The ax25 user parameter works very well. I figured it'd > work for forwarding as well, but it's still using the linkaddr call. * BBS command 'LB' added This command is the same as 'LIST', except that the display includes the BID in the output, and omits the date and size. * New prefix command to execute commands in all areas You can now do kills, lists, reads, verbose reads, or MA/MH/MP/MT commands on all areas, by preceeding the command with a '!'. All other commands give you a message saying it doesn't make sense to do this in multiple areas, and then does it once. For example, to list the first 5 messages in all areas, use '! l 1 5'. To look for a bid in all areas, use '! L$ bidtolookfor'. * More security - never enough ;-) I discovered one remaining security hole that I had, so we have a new subcommand of the security command, 'security nonsecureampr '. This sets up a single ampr.org address (44.xx.xx.xx) as being NON-SECURE for anonymous ampr/ax25/netrom access. The problem on my end was that the Linux side of my machine has an ampr address on its side of the SLIP connection. All connections coming from the Linux side of the machine come with that AMPR address. I allow logins to lantz.com to come into the gateway, which made them unsecured and set as a trusted ampr site. Now any coming this way are treated as non-ampr for that one address only. * Added a QUICKSCAN BBS command Since a couple of users had asked how to do a quickscan DURING a BBS session, like the one they get on login, I added a QUICKSCAN command, with a "QS" abbreviation. * Added a 'Sender' line to all incoming SMTP messages Since xNOS SMTP takes the envelope address and uses that as the 'From:' address, ignoring the real 'From:' address, I've added code in the SMTP server that takes the original 'From:' address and makes it into a 'Sender:' line. If you are getting mail from a mailing list that uses an envelope address to send it, this will allow you to see who the original sender was, with the 'V' command. * Added functionality to finger server... I've added something else to the finger server that isn't found on normal finger servers; the ability to request for other hosts finger info within a finger request. For example, you can send a finger request of: finger user%host@tnos.host The 'tnos.host' will receive 'user%host', and will change this to a request of 'user@host', will remote gateway it, and send the results on as the data to the originator. This can be used when (for example) a TNOS gateway has connectivity to the Internet, but the local RF network is firewalled and can't be directly reached by the Internet. An Internet user can get the TNOS gateway to relay the finger request, and pass the results back. If you had a reason to, you can nest these. That is, you can send: finger user%dest%gate2%gate1@tnos.host * Bad word list and questionable user list... Now you can automatically hold messages that contain language that you find questionable or from users who cannot be implicitely trusted. Two new files, /spool/userhold.dat and /spool/wordhold.dat are where the data is placed. Partial matches ARE done, so (for example), if you place the word 'main' in the wordhold.dat file, all messages with the string 'main' anywhere in it will be held. Mainland, maintainence, etc will all match. Same goes for email users. A name of 'brian' in the userhold.dat will hold all messages from ANY user named 'brian', or from any host with 'brian' in the name. There is no limit to the number of userhold.dat lines, but the wordhold.dat can be no longer than 100 lines. The wordhold data is read into memory, so if you use this under DOS, be aware that the more you put in, the more likely the chance you will run out of memory. With power comes responsibility ;-) * An addition to ARP..... For a specific need I have coming up soon, I am adding a new feature to the ARP code. The command, 'arp dupcall', is used when ARPing on an AX25 interface (if defined) to send out a SECOND ARP broadcast each time. The first one is always sent to the AX25 callsign 'QST'. The second one (if enabled) is sent to the address defined with 'arp dupcall'. This allows you to send the arp requests to two different places, using 'ax route' and defining different digi path for the two different call signs. * 'domain localtrans' command added Back in November (yes, I keep code ideas archived), Todd W. Powers wrote on the nos-bbs mailing list about an addition he made, a 'domain localtrans' command. This has been added into Release 1.13. There had been discussion about the long lookup times when turning domain translate on, which this helps to reduce. This flag (if set) will only look at the local DOMAIN.TXT file when displaying such things as 'routes' 'arp', 'rspf routes', etc... * TNOS 1.13, FreeBSD, and other BSD systems Thanks to Carl M. Fongheiser/KF0YN , release 1.13 SHOULD compile fine for FreeBSD and similar variants of Unix. Carl did the port, and sent in the diffs. He has been in touch off and on, and SOME of what he had to do to previous releases HAD been incorporated into 1.12. Of note, from Carl: > Up and coming things: FreeBSD doesn't let you use the SLIP over > a PTY trick like Linux does. On the other hand, the version > that'll be released soon will have a "tunnel" network interface, > which will let you do almost the same sort of thing. I'm planning > to add a TNOS interface to that. * Command session 'sleep' command added The command 'SLEEP num', allows delaying 'num' seconds before receiving next input line. * Command session 'pause' command added The command 'PAUSE [num]', allows optional delaying of 'num' seconds, and then prompting for the user to 'hit enter to continue'. * Command session 'echo' command added The command 'ECHO [string data]', allows displaying to the current session's output an line consisting of the concatenated remaining arguments, followed by a . The previous 'echo' command was renamed to 'echomode'. * SMTP HOPPER added Also added in the SMTP HOPPER code from JNOS. This code, put simply, takes effect if there is no direct SMTP connectivity to a host, and the host has NO MX record in the DNS. If this occurs, AND the TNOS station knows where to route the packets (with a 'route' statement), then the station who IS the routing gateway is ASSUMED to also be able to serve as a SMTP gateway, and the mail is sent there... * AX25PASSWORD code added from JNOS * TNOS Conference Bridge is now a PingPong Conference Bridge MANY changes in the Conference Bridge, and PingPong users will love 'em! The displays match closer, the PingPong quality checking is there, the destinations command is added, numberically sorted displays, route destination tracing, integration of TNOS net titles with PingPong topics, an added uptime command, and more. * Added 'convers online' and 'convers cstat' commands Those familiar with PingPong already can guess what these do, huh! The 'convers online' command is a shortcut for 'finger conf'. The 'convers cstat' command gives the link status display, followed by the destination display. * Added the relaying of unknown 'host' Conference Bridge commands Added code to forward on to all other connected hosts any 'host'-type commands received that it doesn't understand. Previously, any 'new' commands got bit-bucketted at a host that didn't recognize it, whether the next one down the line knew what to do with it or not. This will allow servers to add new functionality, without requiring all servers to add this in order for it to be used. * Added a Conference Bridge '/CQ' command I've added a command ('/CQ [topic]') by which a user could send a message to all users, which displays something like: callsign@host channel xx calling CQ [topic] for people to establish QSO's without having to go to any particular channel to see who's there and what's happening. It allows those who are looking for conversation partners to make it known! * Added a Conference Bridge '/sysinfo' command This command (and the coresponding host command) are added to maintain compatibility with TPP. It allows the user to request system information from either the local host, or a remote host, assuming that the hosts in between are TPP compatible. * Added TPP extended command support Tampa PingPong (TPP) provides a way to extend a local Conference server with commands that reside on a remote host. This support is also built into TNOS with this release. ------------------------------------------------------------ Minor Changes: The following minor changes have occurred. * Slight modification to the mail.log output I've added the message type (P/B/T) to the output, right after 'deliver'. This is to allow easier parsing of mail.log file for finding out how many personals and how many bulletins. * Added an additional comment character to the BBS In addition to lines starting with a ';', all lines beginning with a '#' are now ignored in the BBS, and treated as comments. * 'AX25 mycall' and 'ax25 user' callsigns initialized In the startup code, these two callsigns are initialized to 'NOCALL'. Several spots in the code assumed that these were set to SOMETHING, so now they are. When an ax25 interface is attached, it takes the 'ax mycall' as the linkaddr and ipcall. If the 'ax mycall' is not set prior to the attaches, they USED to be blank; now they will be NOCALL. * BBS 'L$' output changed This command works the same, but the output is like the new 'LB' command, showing the bids matched. * No output from BBS list commands if no matches These used to display a listing header even if no messages matched the messages selected. Now, there is no output if there is no match. * Add support for Chameleon-style bids to be PBBS forwarded Similar to the support I added for Pine-stype bids in 1.12, now bids from the Chameleon mailer will be converted to a unique bid when being forwarded out with PBBS forwarding. * The maximum number of arguments (NARG) increased to 30 This was set to 20. * MBOX MAXUSERS - revisited Now outgoing forwarding sessions, and incoming connects from BBSs that are in your forward.bbs file will occur even if the 'mb maxusers' is reached, as long as the hardcoded maximum (40 at the present) hasn't been reached. So if you want to always allow up to 2 BBS forwarding sessions, you can set 'mb maxusers' to 38. The catch: the incoming BBS sessions must either be an AX25 connect or a NETROM connect. Telnets lose out! * MBOX TDISC - revisited The 'mbox tdisc' timer now no longer will time out a user that has SYSOP privileges. * The Command Session 'echo' command was renamed to 'echomode' * Cleanup of conditional from config.h I've done quite a bit of cleanup on the conditionals, and made many more (almost all) conditionals compile clean if they are turned off. I also added in a couple of new conditionals, GATECMDS, FILECMDS, and FOQ_CMDS (like the JNOS code supports), and added conditional code to the previously unused MAILCMDS conditional. You can now leave out just about anything. To leave out more, you need 'del tnos.exe' ('rm tnos', for Linux) ;-) * Added syntax to the alias file entries In TNOS, if there is an alias (or a group list), the ORIGINAL To: line is changed to the NEW To: address. While this is different, it IS exactly what you REALLY want in almost ALL cases. Otherwise, when it leaves via PBBS forwarding (or SMTP, for that matter), the ORIGINAL TO address will make most PBBS's puke, or try to send ALL copies of the aliased file to a user of the ORIGINAL TO name, which won't be found anywhere. I received MUCH flame mail locally about this 'old' way of doing things when I started TRYING to use aliases and groups locally. And while this is ALMOST always what you want, there are at least two cases when you DON'T want this. The first is if you are have NNTP compiled in, and wish it to go to a NNTP group with the original TO address. The second is if you wish to 'CC:' a message. Rob, for instance, places a copy of all messages to certain mail areas in a special area that is a compilation of all messages within the last 2 days. In this case, you DO want to preserve the original TO address. So, as of 1.13, when looking at the address, if it came from an alias and the receiver name either starts with '!' or 'cc:', then the ORIGINAL To: line is preserved. Otherwise, it takes the expected action of making the To: line read as the expanded name. So you could have a rewrite like: *@tpalan* tpalan then an alias file with tpalan cc:tpalan !packet.tpalan cc:ko4ks@ko4ks.ampr.org joe@blow meaning anything that came in to say 'tnos@tpalan' would drop to tpalan, and be left there, AS WELL as getting to NNTP as group packet.tpalan, being copied to me (all still with the to line as 'tnos@tpalan'), and also going addressed to joe@blow. * Changed Conference Bridge /who display default The default display for a '/who' command used to be the long display. It is now the same as the quick display, making '/who' and '/who q' the same. to get the original, normal display, use '/who n'. * Added an option to the Conference Bridge '/who' command The syntax of '/who @ hostname' is now supported, which gives a normal (long) who display, but only of users at 'hostname'. The 'hostname' parameter can be a complete name, or only the beginning of a name, for brevity. ------------------------------------------------------------ Known Bugs: The following are known bugs that are being worked on during the development of release 1.13. These may or may not be fixed in release 1.13. * TCPGATE won't compile in DOS version Missing some references in the source. Will be fixed soon... * Screen saver not right in Linux version Display doesn't clear, just overwrites. Not harmful, but not right. * WHITE PAGES flakiness, at times The expiring and sorting of WP can at times make things a little flakey. This is still under construction. * FTP permissions improved The new UNIX-like dir display needs a little more work with the permissions portion of the display... ------------------------------------------------------------ To-Do List: The following are things on my 'to-do' list that may eventually be done, but not necessarily by the next release. * Linux kernel AX25 devices available from TNOS/Linux This would allow the PI card to be used.... * BID History moved to an in-memory structure This will eliminate the need to sort the history file, allow faster lookups, and eliminate the need to 'bid kick' in order to update the BID info. * Bypass internet SMTPClient->SMTPServer for local mail Find a way to do all that is being done, without the overhead of two separate processes, and two different temp files. * FBB-style forwarding No, I didn't give up on this.... * HTTP daemon??? Who knows! * Add in a way to process PBBS 'import' files Probably by rewriting a file to area 'import', the file would be processed and the messages treated as being received by a direct PBBS connection. * Modify the delegation server Make this only send ONE notification per user per delegation period. * Add capability to TScript to allow starting of OS commands This MAY or MAY NOT be limited to Linux version. * Add in UNIX permissions checking to FTP server This could cause problems with restricted files not being restricted. * Some capability internally or externally to generate statistics Use the log files to show patterns of traffic, usage, etc. * Decide if I'm going to add a third mode to maintainence mode One which will bump users off with a message, then start maintainence.