DB3FL WAMPES NOS (WNOS) Version 4 Update Guide Mike Chace (G6DHU) Document Version 1.0 (April 1992) WNOS4 is the latest version of the TCP/IP NOS software from DB3FL. It features Data Compression, a more friendly User Interface and Mailbox, AX.25 Autorouter and a Chat node that can be used to connect IP hosts together to form a multinode Conferencing system. WNOS supports the usual range of TNC drivers (KISS, DRSI, SCC etc) as well as all the well established TCP services; Telnet, FTP, POP, SMTP, NNTP, and TTYlink (Chat). It has no need for the RSPF and RIP routing protocols since the WAMPES front-end deals with the auto-routing at the link layer. WNOS periodically saves all routing information (IP, ARP, AX.25 and NET/ROM) to all known hosts making it a truly dynamic system. This manual is a quick guide to the new features in WNOS4. Most of the basic concepts remain as in WNOS3, the documentation for which is included in this release pack. WNOS3 documentation has been continually updated by me and so if you had an early version of WNOS3, please re-read the WNOS3 User Guide in case new features were added. THIS DOCUMENT *MUST* BE INCLUDED IN ANY COPY YOU MAKE OF WNOS AND GIVE TO SOMEONE ELSE. 1. What's New in WNOS4 ? 1.1. The User Interface If you liked WNOS3's user interface, you'll like WNOS4's even better! There are now TWO status lines at the top of the screen. The uppermost line displays dynamic session parameters according to the type of session selected. The lower line shows the "overview" status of each session. Both status lines remain on screen in whatever window is selected. Since the lower status line operates just as in WNOS3, you can read about that in the WNOS3 documentation. I will concentrate on the upper status line. 1.1.1. The Session Status Line 1.1.1.1. Command and Trace Mode When in the Command or Trace windows, the upper status line shows the following information. WNOS4 | Coreleft 100000 | Attended | Command | | | 20:20 Coreleft varies with the amount of free memory (in bytes) available to WNOS. You should see this reduce when sessions are opened, and creep up again when they are closed, as the memory manager cleans up. When the amount of free memory drops to that set by the "memory threshold" command, the "WNOS4" icon changes to "PANIC" and the whole of the upper status line flashes. This is to warn you of impending doom! Next comes the stations "attended" state, as set by the "attended" command. If you set "attended no", the status line icon will change to "Unattended". This is a useful feature, since I often forget to switch to attended when I sit down at the console or, even worse, I forget to switch to unattended when I go to bed. I don't like connect bells waking me at 3am in the morning! Finally, we have the session mode "Command" or "Trace" as appropriate, followed by the time in the very last field. 1.1.1.2. Telnet Sessions The session status for Telnet based connects (Chats, Telnets, and the Local BBS) display the following information. WNOS4 | g6dhu | Telnet | Backoff 0 | TxQ 120 | RTT 12/29 | | | 20:20 Ignoring the program name, the first field is the hostname of the station connected to, followed by the session mode, "Telnet" in this case. If the local BBS has been connected to (the "bbs" command) the hostname displays as "LocBBS". Backoff varies as the connection progresses and shows how much TCP is backed off. TxQ shows how much outstanding data this session has. This is data either waiting to be sent or waiting to be acknowledged by the remote end. When TxQ drops to zero, you know that all data has arrived at the remote end and has been ack'ed. RTT dynamically shows the value of the TCP retransmission timer. The higher the value after the slash, the longer the round trip time to the remote end. Each time it counts down to zero with data still to acknowledge, TCP will backoff (so the Backoff counter increases) and the retransmission timer will increase. If the connection is stable, ie no data to acknowledge or send, a "-" is shown before the slash denoting that the timer has stopped. The next field is unused in Telnet type connections. The one character field before the time shows the upload or download (record) flag. If a file is being uploaded to the remote end (the "upload" command) you will see a flashing "U" in this field. If the session is in record mode (see the "record" command) an "R" will flash in this field. 1.1.1.3. AX.25 Session Status The session status for AX.25 type connections display the following information. WNOS4 | GB7IMB-2 | AX25 | Retries 0 | Unack 1 | T1 12/29 | | | 20:20 The callsign of the remote end appears first, followed by the session type (AX.25). Retries shows the number of times we have resent the current I-frame. Unack shows the number of outstanding, unacknowledged I-frames. T1 dynamically shows the value of the Ax.25 T1 (retransmission) timer (in seconds). WNOS adjusts the value of the T1 timer in accordance with the round trip time for the connection and so the value after the slash gives a good indication of RTT. A hyphen "-" before the slash, shows that the connection is idle, with no frames outstanding. The next field is normally blank but sometimes displays "RNR" to show that the remote end has sent an RNR frame. This denotes that the remote end is temorarily choked and has asked you to stop sending any more data. When it has processed the data and unblocks, the "RNR" will disappear. Again, the last field shows upload or record status. 1.1.1.4. NET/ROM Session Status The session status for Level 4 NET/ROM type connections displays the following information. WNOS4 | GB7ZZ | NET/ROM | Retries 0 | Unack 1 | SRTT 12/29 | | | 20:20 Session status fields are almost identical to those of an AX.25 connection. Except of course, that the Retries and Unack counters now apply to NET/ROM Level 4 (Transport Layer) information frames. SRTT shows the Smoothed Round Trip Time for the connection with the "-" before the slash again denoting an idle link. Where an AX.25 type session would display "RNR", NET/ROM sessions display "CHK", informing the user that the remote end has sent a "CHOKE" packet. This packet has the same effect for NET/ROM Level 4 as RNR in AX.25 (Level 2). 1.1.1.5. FTP Session Status The FTP session status line changes according to whether or not the session is in command or file transfer state. In FTP command mode, the session status line is exactly as that for Telnet type sessions except that "FTP" replaces "Telnet" in the session type field. In file transfer mode (ie either a "put" or a "get" is in progress), the FTP status line shows the following information... WNOS4 | g6dhu | FTP-DATA | Rx 10000 | Tx 0 | RTT 12/29 | | | 20:20 The session type field changes to "FTP-DATA" and the Backoff and TxQ fields are replaced by "Rx" and "Tx". Rx shows the number of bytes transferred from the file being got from the remote end. Tx denotes the same thing when a local file is being put onto a remote host. 1.1.1.6. More and Dir Session Status These sessions display the following information... WNOS4 | autoexec.nos | More | | | 20:20 The file or directory name is displayed along with the session type, which is always "More". 1.1.1.7. Ping Session Status This type of session is created when a repetitive ping command is issued (eg "ping 44.131.20.0 100 600 y"). This is often used to check how many hosts are alive in a local sub-network. The information displayed is as follows.... WNOS4 | 44.131.20.0 | Ping | | | 20:20 1.1.1.8. NNTP News Reader Sessions Reading or posting a news article uses a "More" type session. The session type names are "NNTP Post" and "NNTP Read". 1.2. NET/ROM Route Save If NET/ROM is configured in your WNOS4 executable, NET/ROM route saving is now implemented. The feature is controlled by the command "netrom route save [yes|no]". If "netrom route save" is set to "yes", at each tick of the "save" timer (see the "save" command), the complete current NET/ROM routing table will be saved to disk. The file written to is "NRROUTE.DAT" in the WNOS root. The next time WNOS is started, and if you have set "netrom route save" to "yes", the NET/ROM routing table will be read from disk and the node table will be rebuilt. This means that you don't have to wait for your local node(s) to send a routing broadcast before your node table fills. 1.3. Data Compression LZW data compression has now been extended to the NNTP system and the convers cluster links. 1.3.1. NNTP Message Compression This is implemented in much the same way as SMTP message compression and is selected by the "nntp lzw" command. Both NNTP client and server can operate in LZW data compression mode. 1.3.2. Convers Cluster Interlink Compression Convers Cluster links can now operate with LZW compression on all traffic. So that new systems can still interlink with WNOS3 and WAMPES non- compressed convers nodes, a new server has been added to WNOS4 to handle compressed interlinking. The new server is called "xconvers" and lives on TCP port 3601. To link to other convers nodes in compressed mode, the following steps are required.... 1) autoexec.nos must contain the line start xconvers 2) The convers interlink file, convers.cfg specifies "xtelnet" as the connect method eg # This is a non-compressed interlink g4otj telnet # This is a compressed interlink g4wrw xtelnet 1.4. Mailbox Changes There are not many user visible changes to the mailbox. Changes are mainly to the AX.25 BBS mail forwarding system. 1.4.1. Mailbox Error Message Formats All mailbox error messages (except for "Already Have It") are now prefixed with "***" instead of "NO -". This stops the problem whereby the sysop switches 3rd party mail off, an unknown mailbox connects to forward personal mail with "SP DC0HK@DC0HK" and the WNOS mailbox responded with NO - Permission Denied The forwarding mailbox interprets any message with "N" in the first column as "I've already got that message" and deletes it! The mailbox now returns the safer *** NO - Permission Denied error message instead. I gather that most mailbox software (eg G1NNA etc) understands that "***" denotes a forwarding error and responds accordingly. 1.4.2. Forwarding Mail with Hierarchical Addresses WNOS3 had a bug inherited from old NOS code which stopped the WNOS mailbox from forwarding using Hierarchical Addresses unless the forwarding box's SID banner contained "H$". Since most boxes now have many features, it is rare to find the "H$" together (eg G4YFB Mailbox has [YFB-3.42-BHR$]). The WNOS Mailbox now looks separately for an "H" and a "$" in the SID banner and if it finds them, it uses an Hierarchical Address if the message was sent with one. 1.4.3. Mailbox Prompt The UK version of WNOS4 now restores the current message number to the mailbox prompt. The prompt format is now... (Msg #123: AMSAT) DB3FL de G6DHU> That is, the current message number is 123 within the folder AMSAT. 1.4.4. Forward Commands The WNOS3 UK version "forward nic" and "forward info" have now been integrated into the mailbox commands. In WNOS4 they can now be found as mbox fnic mbox finfo These commands are used to set fields in a BBS standard R: header which is applied to all messages (Personal and Bulletin mail) forwarded from your system to a mailbox. "forward nic" is used to set your mailbox Hierarchical Address and "forward info" can be used to add a small comment (usually your location eg [Bath, Avon, UK]). The WNOS4 Command Reference explains the R: line in more detail. Please note that a full R: header is only generated if BOTH "mbox finfo" and "mbox fnic" have been set. Otherwise, a shorter version is applied to outgoing messages instead. The mailbox forwarding kick command "mbox kick" has also changed name to "mbox fkick". 1.4.5. SMTP Header Stripping Also something that was formerly only in the UK version, but is now included in the standard distribution. SMTP message headers (Reply-To:, Date:, Received: etc) will be stripped from mail that you deliver to a non-SMTP host eg Mailboxes, PMSes, PBBSes etc. This helps in reducing message sizes on the BBS network where SMTP headers are redundant in any case! 1.4.6. New Mailbox Commands There are two new mailbox related commands - "mbox remote" and "xr". "Mbox remote" is the 'console equivalent" of the mailbox "xr" command. Both these commands take an argument which is a hostname. When set, a user logging into the mailbox and typing the "chat" command will have their chat session redirected to the Chat port of the host specified. The command is therefore useful if the machine is remotely sited, remains unattended for long periods or functions as an intelligent gateway. (Internet/AMPRNet gateway operators please note!) When used from the mailbox, the "xr" command can only be executed by a user possessing "SYSOP" privilege ie they have bit 64 set in FTPUSERS. 1.5. IP Auto Router Changes It is now possible to define special routes which do not get updated by the IP/ARP autorouter. It is sometimes desirable for stations to respond to other nodes on an interface or via a protocol different to that used by the incoming path. This often happens when a node can be heard but not worked direct but may be reached across a NET/ROM network for example. If such "split routes" are needed, the IP route to that host may be added with "route addprivate" instead of "route add". Routes marked as private will NOT be overwritten by the IP autorouter. Other non-private routes still get updated dynamically if they change. 1.6. The "swap" Command WNOS4 adds a new command "swap [yes|no]". This controls WNOS4's behaviour when the user performs a shell-to-DOS like command (either "!", "shell" or "mail"). If "swap" is set to no, the usual behaviour takes place and the resulting shell or mailer has to run in whatever memory WNOS left over (ie that shown by Coreleft in the status line). If however, "swap" is set to yes, a shell related command will cause WNOS4 to first write its program image to either Hard Disk or XMS RAM (if enough available) before performing the shell. The advantage is that the shell or mailer then gets a complete 640k of memory to operate within. The small penalty to be had from this feature is that invoking the shell or mailer may take a bit longer whilst the image is written. This means for instance, I can now run the PCElm mailer program from the WNOS4 "mail" command and edit mail with my favourite editor (GNU Emacs). I couldn't do this before because WNOS3 only left its 'coreleft' worth of memory for the mailer to operate in which was never enough to load Emacs. I can now use other, bigger and better mailers too, such as the excellent "View". Swapping to hard disk does not take long, typically some 5 or so seconds on my 12MHz 286 machine. 1.7. Domain Server Changes 1.7.1. The Domain Cache Frequently used domain names are now stored in a cache holding the domain name and corresponding IP address. This speeds up domain name searches because WNOS4 looks in the cache before consulting the DOMAIN.TXT file when resolving domain names to IP addresses (see the "domain cache" sub commands). 1.7.2. Domain Translation WNOS4 can now translate IP addresses to domain names for display in such things as the status line entries (see the "domain translate" command). If "domain translate" is set to "yes", incoming TCP/IP sessions look up the domain name corresponding to the IP address of the remote end. Therefore, if an IP station connects to your chat port for example, the status line entry for that session opened will display the domain name of the connected host, rather than the IP address eg sys2.g6dhu rather than 44.131.20.14. If domain translation is on, all IP addresses are converted to domain names wherever they are displayed too. For example, the ARP table output and trace window will show domain names rather than IP addresses. 1.7.3. Domain Commands Withdrawn The commands domain load domain nslookup domain save have been withdrawn from the standard executable. They are generally not needed by most users since there are very few users who operate a domain name service (DNS). They can however be restored in special versions for users running DNS by defining the symbol ENH in CONFIG.H. 1.8. New NNTP Services For those of you that use NNTP (Network News Transfer Protocol) to send and receive news articles, WNOS4 retains all the NNTP services of WNOS3 plus a few extra enhancements. I have already mentioned that NNTP now supports data compression in both server and client. 1.8.1. NNTP2 Compliance WNOS4's NNTP implementation (both client and server) match that defined by the Draft RFC for the 2nd generation NNTP protocol, NNTP2. This RFC is included in the WNOS4 distribution documentation if you have NNTP configured (not the standard distribution). 1.8.2. The IHAVE Command As part of NNTP2 compliance, WNOS4's NNTP client routine implements the IHAVE command. This improves the speed of distribution of news articles through the NNTP network. The basic idea behind IHAVE is as follows. A client polls a server for new news and retrieves articles as desired. If the client has received new articles of its own since last speaking to the current server, it can offer them to the server using IHAVE. The server can either reject the articles (it may have them already) or it can accept them, in which case, the client posts them to the server. For further details, see the NNTP2 RFC and the "nntp ihave" command in the WNOS4 Command Reference. 1.8.3. News Reader A simple news reading routine is now included in WNOS4. A news posting program was already implemented in version 3 and so WNOS4 now has a completely integrated set of tools for reading, replying to and posting new news articles. 2. Source Code Source code for the UK version of WNOS4 will be available from me. You are in no way restricted in passing the source code on to others. I would however ask users passing source code to others to mail me with a message informing me of who the code was given to. Better still, don't pass the source code on and get the interested party to contact me. That way, I know where sources are and always the latest source code pack goes to those who require it. 3. Bug Reports As with all good software, it's hard to test 100% and so there are likely to be a few bugs about. If you find a bug please contact me with the details and I will do my best to pass them onto Mike (DB3FL). WNOS has had a good reputation for a fast response to bug reports and subsequent fixes. Send me a good explanation of the bug and as good a grip on the environment (both machine and the outside world) and circumstances in which it takes place. Example autoexec.nos and any DOS batch files are often useful too. Please note that neither I nor Mike (DB3FL) will entertain bug reports on executables that have not been built by me or him. I can be reached in the following ways. NTS Mailbox - G6DHU @ GB7IMB.#41.GBR.EU or GB7WRW.#41.GBR.EU Internet - mikec@praxis.co.uk AMPRNet - mike@g6dhu.ampr.org [44.131.20.3] Snail Mail - Mike Chace, 84 Frankland Close Bath, Avon BA1 4EL 73 and enjoy WNOS4! Mike - G6DHU 4. Change Log v1.0 29th April 1992 (WNOS4a6)