ProfitPress Mega CDROM2 Shareware Freeware (MSDOS)(1992)(Eng)

home *** CD-ROM | disk | FTP | other *** search

/ ProfitPress Mega CDROM2 …eeware (MSDOS)(1992)(Eng) / ProfitPress-MegaCDROM2.B6I / MISC / NETWORK / WNOS4DOC.ZIP / WNOS4DOC.EXE / WNOS4MAN.TXT < prev next >

Wrap

Text File | 1992-05-30 | 41.9 KB | 1,106 lines

DB3FL WAMPES NOS (WNOS) Version 4 Manual Mike Chace (G6DHU) Based on the original German document by Mike Bentrup DB3FL Document Version 1.0 (May 1992) Program Version WNOS4a6 1. Introduction WNOS is a version of NOS (the Network Operating System) based on earlier work by Phil Karn (KA9Q), Kelvin Hill (G1EMM), Gerard van der Grinten (PA0GRI), Anders Klemets (SM0RGV), Peter Glasmacher's (DK5DC) GNOS program and WAMPES from Dieter Deyke (DK5SG). Special Features of WNOS include; More friendly User Interface New AX.25 Server (from WAMPES) Convers Server (from WAMPES) Real time data compression on SMTP, NNTP and Convers interlinks Automatic route saving for IP, ARP, NET/ROM and AX.25 Dynamic timers based on link layer traffic conditions This manual is not really designed to provide beginners with an overall grounding in the use of the NOS software. More importantly, it provides a guide for users familiar with TCP/IP use in other NOS variants, as to how to use WNOS as well as explaining the new principles in this software. Installation programs and so on are not provided, but all the information on directory structure and configuration is provided herein. Beginners should be able to find plenty of other tutorials and information about TCP/IP and NOS in general from other sources, should they wish to know the "basics". 2. WNOS 2.1. About This Manual This is the first attempt at a reasonably complete manual for WNOS. Don't be surprised if some bits are missing or don't quite follow a logical sequence. Thanks to Thomas (DG8FBV) for proof reading the German original drafts and providing feedback. This manual tackles a number of different areas of WNOS and first provides an overview of the hardware required and of the startup procedures used to run WNOS. Following this is a description of the display features and of the file and directory structure required. The main body deals with a detailed description of each of the commands supported by WNOS. Note that some commands and options will not be available since they depend on which features have been compiled into the distributed executable program (WNOS.EXE). A summary of the commands available in any given program may be displayed by the "?" command. The final sections deal with short cuts, an overview of the most important RFCs (Request For Comments), the Internet Protocol definition documents. At this point I'd like to thank all those involved with tests and trials, bug fixing and bug hunting! Special thanks go to Peter (DK5DC) who provided code from his GNOS system. Thanks also to Dieter (DK5SG) for permission to use parts of the WAMPES software. Also to Thomas (DG8FBV) and Heinz (DL8YQ) who tested many versions to destruction and became "professional testers" to the extent that the key combination CTRL-ALT-DEL became an everyday part of life! UK Note from G6DHU: Thanks to all those who beta test my UK version of WNOS; G1ERT, G6PWY, G4OTJ, G4BIO and all those who use the software in this country. Suggestions for improvement, problems and bug reports are of course always welcome. 2.2. About WNOS WNOS is an extension of, and improvement upon the foundations laid by Phil Karn in his original version of NOS. The "W" in the program name stands for WAMPES. This doesn't mean that all of the WAMPES system is implemented in WNOS, just the AX.25 Autorouter, Convers server and client and other smaller features. This involved a lot of work in porting WAMPES code from its Unix environment to DOS. Also, the move to a different style of C compiler brought its own problems. In any case, WNOS Version 4 is now rid of most of the bugs and problems present in earlier versions. WNOS being mainly German in origin, is designed foremost with that Packet Radio environment in mind where auto routing of AX.25, crossband digipeaters and Hop-to-Hop acknowledgement are all daily facts of Packet Radio life. 2.3. WNOS In Comparison The command syntax of WNOS (and NOS) owe much to that of the Unix operating system. For instance, directories are delimited by "/" instead of the DOS "\". Not all WNOS functions make the conversion of file syntax from Unix to DOS-style and so the Unix approach is more often than not, the correct one in WNOS commands. At a first glance, WNOS bears little relation in its look and feel to that of the original NOS. The reasons are twofold. Firstly, WNOS removed NOS's more irritating features, and secondly, the user interface in NOS is very primitive for today's machines. A continual process of improvement over some two years has made WNOS what it is today. 2.4. Features The AX.25 server automatically drives the ARP and IP routing tables. In this way, incoming IP traffic can be sent to other hosts with the minimum of operator intervention. IP traffic from NET/ROM routes is also now dealt with in the same way thereby removing one of the remaining inconveniences. Lastly, AX.25 routes, the ARP and IP routing tables and the NET/ROM routes are all saved to disk at periodic intervals. Interface parameters have also been made more flexible and extended thus allowing settings such as Paclen and the AX.25 timer values to be specified separately for each configured interface. In this way, interfaces using high speed links can be optimized for performance. The user interface of WNOS has also been improved over time. WNOS3 began by providing a single status line at the top of the screen with summary details about each active session. For WNOS4, two status lines are now displayed one of which includes a permanent monitor on the level of free memory "coreleft" available. This gives useful warning of when the program is running short on working memory. When hopping into a session, one finds that the upper status line displays the important parameters for that link. Through this, one gets a quick and simple summary of the progress of the session. Unfortunately, due to the 25 line limit of most displays, any further extension of this user interface is now likely to prove difficult. The new features different from WNOS3; LZW Data Compression is now extended to NNTP and Convers. The Domain Name Server and Client code has been extensively modified; a configurable size domain cache has been built in and the domain name translation function reinstated. The NNTP Server and Client code has been optimised and its functionality extended. The POP code has also been modified and reorganized. The trace functions have been reworked for greater speed, less wastage without compromize on functionality. 2.5. Protocol Timers Particular attention has been paid to the TCP timers in WNOS4. Especially in the cases where fast links (eg Ethernet) meet slow AX.25 links, attention has to be paid to synchronisation during the change in link speed. TCP frames are often carried upon AX.25 but the AX.25 layer acknowledgements have little effect upon the TCP layer. WNOS attempts to rectify this situation by deriving TCP layer timer values from knowledge about the AX.25 link layer. In datagram mode (AX.25 UI frames), nothing needs to be done, since all timing is handled by the TCP layer. If however, either AX.25 virtual circuits or IPCAM modes are used at the link layer, TCP timer values are multiplied by a factor of 10 to allow for the usually slow acknowledgement and forwarding of frames on the link layer. After a maximum wait of 300 seconds, unacknowledged TCP segments are resent irrespective of the link layer conditions. This ensures that the TCP layer is not controlled too stringently by the underlying AX.25 connection. In practice, this timing method results in an overhead of a little under 5%. If data arrives so quickly on the fast link, that it cannot be forwarded onto the slow link, the sending host on the fast link is sent an ICMP control message (Source Quench). This then allows the slow link to catch up in sending the data on to its intended destination. WNOS monitors this sort of condition continuously in order to minimise the overheads in forwarding traffic. 2.6. Internals In contrast to NET (the forerunner of NOS), the core of the program runs in a quasi-multitasking environment. Each main action runs within a small piece of code known as a process (A summary of the currently active processes may be displayed by the "ps" - (Process Status) command). This environment allows NOS to be much more powerful than its predecessor which had to finish each task before another could begin. One mustn't forget that just because the sysop isn't typing anything at the console, the program isn't just idly waiting. It is busy updating timers, coordinating tasks, updating the display, handling interrupts, monitoring all frames on the channel etc etc. Since even this approach leads to problems on today's fast machines, attempts were made to streamline and optimise the program code. This involved rework of many files, removal of redundant code and so on. This rework also allowed the trace process to run in a separate window all of it's own. All of this work allowed the overall performance of the program to be increased considerably as well as providing a stable NET/ROM implementation and a net reduction in the size of the executable by 10 kilobytes. Parallel to this work, went a complete reorganisation of the memory management routines. Borland compiler library routines were used which allow unused memory to reallocated for use by DOS as and when it was needed. These library routines first appeared in Borland C++ 1.01 and so the program will not run if compiled with Turbo C 2.00. Despite all of these improvements a word of advice: I (Michael Bentrup DB3FL) make no guarantees and take no responsibilty for, any damage that WNOS may cause on other systems. Whether intentional or unintentional. 3. Using WNOS 3.1. Hardware Requirements WNOS can run under the MS-DOS or DR-DOS PC operating systems. It has been tested with MS-DOS from versions 3.31 to 5.0 and DR-DOS versions 5 and 6. Under MS-DOS 3.31 there are some problems with Terminate and Stay Resident (TSR) programs and especially with PC-CACHE version 5. With PC-CACHE version 6 there were no longer any problems even if operating under MS-DOS version 3.31. All versions of DR-DOS have an internal problem that means that the File Pointers shown by the "stat" command are not properly displayed. This seems to be a DR-DOS bug. Disk compression programs such as Stacker and DR-DOS's SuperStor may also be used without any problem. Memory managers such as QEMM386.SYS and EMM386.SYS also work well with WNOS but there is one known slight problem in that if the program is "exit"ed with outstanding Telnet connections, some memory corruption may occur. This may cause QEMM to terminate with an error. In this case, it is necessary to reboot the machine from cold so that the ports are properly reset. This is due to WNOS needing a well defined port setting before startup and would fail to attach drivers to ports if a reboot was not carried out. WNOS has been developed on the following hardware configuration; 386sx, 20MHz clock, 2Mb RAM. Either MSDOS5 with Stacker or DRDOS6 with SuperStor was used as the Operating System software. In both of these configurations, the following resident software was also used; QEMM386.SYS, DOSKEY, and K3 (a keyboard driver). QEMM386.SYS was configured with OPTIMIZE and the "STACKS=0,0" command removed from the CONFIG.SYS file. With no programs loaded, about 630k of memory was free for DOS. Later development used much the same configuration but with a 386dx, 40MHz machine with 8Mb of RAM. Depending on the options configured in the executable, WNOS needs at least 500k of free memory and a hard disk is recommended. WNOS can be run using floppy disks as long as the machine itself is fast enough. G6DHU has no problems running a full version of WNOS4 on a 386 16MHz laptop using just the 1.44Mb floppy as filestore. The machine running WNOS is recommended to be at least a 10Mhz 286. Slower machines, particularly those with floppy drives only, will experience problems in busy environments when long disk accesses are required. XT machines equipped with V20 or V30 processors and at least an 8MHz clock should also be able to run WNOS. Display output is in text mode only with the extended IBM ASCIIZ character set supported. Even Hercules mono cards should be OK. Under EGA/VGA display adapters it is possible to switch in a 43/50 line mode. 3.2. WNOS Command Line Options WNOS accepts command line parameters (options) at startup from the DOS prompt. Each parameter is identified by a hyphen "-" and a letter. The value for that parameter should then follow, with no spaces in between. The options are; -e = WNOS switches into EGA/VGA 43/50 line mode at startup. At program exit, the original display mode is reset. In "shelling out" from WNOS, no check is made on the display mode to use or reset it on exit back to WNOS. -b = Instructs WNOS to use BIOS routines to do display output rather than the default, which is to write directly to display registers. This option is often useful when running under some multitaskers. -s = Sets the maximum number of sockets that WNOS can simultaneously have open. With all servers started, 10 sockets will be active. The default is 40 sockets which should be sufficent in most cases. -d = Allows the WNOS file system to reside in a sub- directory off the root of the current disk. You are not allowed to specify a disk name in this option (eg F:). A typical startup call to WNOS might be C:\> wnos -e -d/tcpip /startup/autoexec.wn4 This command line instructs WNOS to look for its file system in the directory C:\TCPIP, use 43/50 line display mode and use the startup configuration file C:\STARTUP\AUTOEXEC.WN4. If no startup filename is given on the command line, WNOS will look for the file AUTOEXEC.NOS in the directory specified by the -d option or in the root if the -d option is not given. If no startup file can be found, an error message will be given at program startup. When WNOS is used for the first time, the routing save files will not yet exist and the error messages resulting from this may be ignored. After a period of operation, these files will be written to disk and read in again at the next startup. 3.3. Operation At Startup After startup, WNOS waits in command mode in the Command session window. Input, followed by a carriage Return, is taken to be a command and is thus executed. Each line of input is saved in a buffer which can be perused using the Cursor keys. If at the program prompt, a CR is typed, and nothing else, the program does nothing, not even a new prompt is given. This line oriented input mode is sometimes replaced by a character input mode. This is particularly so when logging into a remote machine where a password must be typed. In this mode, input typed will not be echoed to the screen. If the "---more---" prompt appears on the screen, then character based input is also in operation. CR is not needed after something is typed, as it will be read immediately. Hitting the Space bar normally scrolls down the screen when the "---more---" prompt is displayed. 4. The Windows 4.1. Window Selection To switch between sessions, or from a session into the Command or Trace windows, the Escape or Function keys are used. This provides for quicker and easier movement between each window. Peformance issues necessitated the separation of the Trace and Command windows but the most useful advantage gained, is that trace output no longer interrupts the command window. The input buffer in each session remembers the last 10 commands or lines of text typed in. The following keys are used for session switching; F1 to F8 - Switch between sessions F9 or ALT-F10 - Switch to trace window, or toggle between the Trace window and the last selected session. F10 and ESC - Switch to Command window. 4.2. Editing Options Partially typed commands/input text may be edited using the following keys; Cursor Up - Move backwards through command history Cursor Down - Move forwards through command history Control-B - Recall last input line/command. Fills the current line with the end of the last line if it is longer. Control-W - Delete last word in current line Control-U - Delete the whole current line. 4.3. Window Structure After startup, the two status lines remain at the top of the screen in all windows. The lines may be configured for use in colour or monochrome displays via the "attribute" command. The status lines in Command and Trace windows; WNOS4 | Coreleft 50000 | Command | | | 17:43 1:DB0DA 2:R:44.131.20.3 3:U:DB0GV-2 4:Chat 5:LocBBS The fields are as follows; WNOS4 - The Program Version Coreleft 50000 - Free Memory Available Command - This is the Command window. "Trace" in that window. "R"/"U" - Record or Upload mode 17:43 - The time. The lower line displays the summary status of each session. 1:DB0DA - Outgoing AX.25 connect to DB0DA 2:R:44.131.20.3 - Incoming telnet seesion, Record mode in operation. 3:U:DB0GV-2 - Outgoing NET/ROM connection to DB0GV-2, in upload mode. 4:Chat - Chat session from the mailbox to the console. 5:LocBBS - Connection to internal mailbox. The current session is marked in colour on the lower status line and a session with incoming data still to be read is shown in another colour. On mono systems, the status line entry flashes when new data arrives. In the UK version of WNOS4, there is an additional field after the "Command" or "Trace" icon, which shows either "Attended" or "Unattended" according to the setting of the "attended" command. Should the "Coreleft" value drop to a level defined by the "mem thresh" command, the upper status will blink and "WNOS4" is replaced by "PANIC" to indicate impending doom! On switching into a session, the upper status line changes character to display information about that session. The "coreleft" icon is removed too. The top session line shows infomation as follows (Right to Left across the line)... 4.3.1. AX.25 Sessions Retries = Retry Counter Unack = Unacknowledged frames T1 = AX.25 T1 timer value RNR = If an RNR frame has been received "R"/"U" = Record or Upload Mode active 4.3.2. NET/ROM Level 4 Sessions Retries = Retry (Level 4) Counter Unack = Unacknowledged (Level 4) frames T1 = Round Trip Timer value CHK = If a Level 4 "choke" frame has been received "R"/"U" = Record or Upload Mode active 4.3.3. FTP-DATA Sessions Rx = Received Bytes Tx = Transmitted Bytes RTT = Round Trip Time 4.3.4. TCP Sessions (FTP Command, Telnet, TTYLink etc) Backoff = TCP "retry" status TxQ = Unacknowledged Bytes in send queue RTT = Round Trip Time "R"/"U" = Record or Upload Mode active Most windows operate in pseudo-split screen mode. The bottom line is used for text input and editing, while the upper portion shows incoming and outgoing data. Incoming data is shown in a different colour/intensity from that sent. 5. Files and Directories 5.1. Files The WNOS configuration files are listed below in alphabetical order together with the pathname. These paths are relative to the option specified in the "-d" command line startup option. For example, if the current drive is C: and no -d option is given, the "alias" file is expected to be C:\ALIAS. If the startup option is "-d/tcpip", the file is expected to be C:\TCPIP\ALIAS. Abbreviations below are; F = File D = Directory B = Binary File A = ASCII (text) file /alias F/A - Mail Alias file /autoexec.nos F/A - WNOS Startup file /arproute.dat F/B - ARP statements (*) /axroute.dat F/B - AX.25 Routes (*) /convers.cfg F/A - Convers Cluster Autoconnect file /domain.txt F/A - Domain file /finger/ D - Finger information directory /ftpusers F/A - FTP and Mailbox user Permissions /iproute.dat F/B - IP Routes (autosaved) (*) /nos.rc F/A - FTP Auto Login data /nrroute.dat F/A - NET/ROM Saved routes (*) /popusers F/A - POP user and password file /spool/ D - Mail and News root directory /areas F/A - List of mail areas to forward /forward.bbs F/A - Mail forwarding instructions /help/ D - Mailbox Help file directory /history F/A - Bulletin ID (BID) history file (*) /mail/ D - User Mail files (eg g6dhu.txt) /mail.log F/A - Mail In/Out logfile (*) /mqueue/ D - Outgoing Mail Queue /news/ D - NNTP (News) root directory /news/active F/A - List of active Newsgroups (*) /news/history F/A - NNTP Message ID history file (*) /news/help F/A - NNTP Server Help File /news/junk D - Newsgroups for junking /news/pointer F/A - Pointers to news storage directories (*) /news/poll F/A - NNTP poll file (*) /news/x/news.rc F/A - Last read news for each newsgroup (*) /news/xinfo F/A - NNTP XINFO (site information) file /node.log F/A - Mailbox activity log file (*) /rewrite F/A - Mail Address Rewrite file /rqueue/ D - Mail Router Queue /signatur/ D - Mail 'signature' directory (*) indicates file is automatically created by WNOS Files such as autoexec.nos etc may use the hash "#" character in the first column of the line to denote a comment. Command parameters can be separated with TAB or SPACE characters. In the domain.txt file, TABS should be used to separate fields. 5.2. Directory Structure WNOS needs a defined directory structure in which to operate. This is; /FINGER /PUBLIC /SPOOL /SPOOL/HELP /SPOOL/MAIL /SPOOL/MQUEUE /SPOOL/NEWS /SPOOL/NEWS/JUNK /SPOOL/RQUEUE /SPOOL/SIGNATUR If the "-d" command line option is used at startup, then these directories must exist as subdirectories from the directory(s) specified in that option. For example, if "-d/tcpip" is used, then the directories must be /TCPIP/FINGER and so on. Some files are created automatically by WNOS when running and as such, the first startup will produce some error messages in the command window. It is recommended that WNOS be left to run for at least 20 minutes so that these files can be created and organised properly. The files above (not marked with a (*)) must be manually copied into the directories indicated. 6. Using WNOS Here follows a short description as to how the sysop uses WNOS to start and use sessions and how a typical mailbox session could look. 6.1. The Sysop's View After all the indicated directories have been created and the other files copied to their proper places, the program can be started. First come the copyright messages and then the command prompt. The prompt format is dependant upon the setting of the "hostname" command. If "autoexec.nos" specified "hostname g6dhu.ampr.org", the prompt appears like g6dhu.ampr.org> If no hostname is supplied net> will appear. In either case, WNOS is signalling that it is ready to accept commands. A few seconds later, the status lines will appear at the top of the screen and then probably a few error messages due to failure of the program in finding the autorouter save files. This is normal for the first startup. Sessions can then be accepted and started. We assume that, for the sake of example, we have an AX.25 type 2m interface called "144" available. So, to start a connection to DB0DA, we would type g6dhu.ampr.org> c 144 db0da If DB0DA is not within direct range, digipeaters can be specified after the destination callsign WITHOUT the word "via" needed. For example g6dhu.ampr.org> c 144 db0da db0lj db0zdf would connect to DB0DA using the DB0LJ and DB0ZDF digipeaters. After pressing the return key, the display changes to the AX.25 type session window with the appropriate status lines. The first line in the window will show.... Trying DB0DA on 144... Once the session is connected, the message "AX.25 session 1 connected to DB0DA" will appear. Commands and/or text can then be typed. Pressing Return moves the outgoing text to the top of the screen from the bottom 'input' line and the packet is then sent. The top status line will then show how the session progresses. Incoming text is shown in a different colour or in intensified text to that of outgoing text. Pressing the ESC key will move back to the Command window and the session continues to operate without further intervention and any data waiting to be sent, will be. If new data arrives in a session not currently selected, the lower status line icon for that session will flash and will continue to do so until that session is selected. Before a TCP session can be started, we must have an IP and an ARP route for the destination. The IP route is used to determine which interface the given host is reached over and, if necessary, the address of a host which will forward our packets to the destination. Therefore, it doesn't matter which type of protocol is used to transport the TCP/IP from one host to another. In our example, we only have an AX.25 type interface. This means that we must use ARP to tell WNOS which AX.25 callsign corresponds to the IP address of the host we wish to reach. Let's say that we wish to reach the host dg8fbv.ampr.org and his station is directly reachable over AX.25 interface 144 and his AX.25 callsign is DG8FBV-5. First add the IP route g6dhu.ampr.org> route add dg8fbv 144 and then the ARP route g6dhu.ampr.org> arp add dg8fbv ax25 dg8fbv-5 Note that Hostnames ARE NOT callsigns and vice versa. However, in AMPRNET hostnames are often correspond directly to callsigns. The point is that in the above statements, in both cases, "dg8fbv" is a hostname which gets looked up to see what it's IP address is (in the domain.txt file). So, "dg8fbv" is really a mnemonic by which to remember his IP address. We could just have easily had typed g6dhu.ampr.org> route add 44.130.20.3 144 g6dhu.ampr.org> arp add 44.130.20.3 ax25 dg8fbv-5 instead. The domain file takes away the drudgery of having to remember IP addresses! the string "dg8fbv-5" is of course a callsign. Anyway, on with WNOS...... Once IP and ARP routes are set, all we need type is "telnet dg8fbv". Again, the display changes and switches into a telnet type session. After the AX.25 connection has been made, the TCP connection starts up and much the same "Trying...." and "...connected to..." messages appear. In most cases, telnet sessions will be greeted on connection with a welcome message and an invitation to login ie a "login:" prompt appears. WNOS is no exception but other TCP/IP programs may be. You may also have to type a password to gain access to the remote host. To close sessions. you have 2 choices. Obviously, the first is to send the command to the remote end that closes the connection eg "BYE" on TheNode. The second is to switch back to the command window and type the "close" command. In both cases, the session is disconnected and a message informing you of this fact will appear in that session window. All that remains to be done is to press return to acknowledge it and that is that! If you do not acknowledge the session closed message, it remains in a 'limbo' state and takes up memory and the status line entry and session window will not be cleared. Users of the NOS software will already know its main advantage over all other types of Packet software in that it is possible to have simultaneous multiple sessions using different protocols. WNOS also takes pride in being the first version of NOS that takes real note of the prevailing channel conditions and adjusts its use of channel accordingly through its dynamic timers. 6.2. The View From Outside For most AX.25 users, their first encounter with WNOS usually ends in frustration! On connecting to the system using AX.25, a connect acknowledgement is given and then... nothing happens! Users first need to send a packet to the mailbox to wake it up (just hitting return will do). This comes about since the mailbox can be connected to by three different protocols (TCP, NET/ROM and AX.25) all of which use AX.25 at the link layer. So, to tell it what protocol is being used, it must receive a packet with the PID bit set ie an information frame. This is only the case in AX.25 connects since once the link layer session is established NET/ROM and TCP will immediately send data and WNOS will see the PID bit! So, back to our example. An AX.25 user connects, sends the "wake up" frame and he is then greeted by the WNOS mailbox. Since the mailbox is also used by other mailboxes aswell as users, for Store and Forward (S&F), most of the preamble information serves little purpose for "human" users. The S&F information is the first line ("[WNOS-H$]") followed by the hostname "g6dhu.ampr.org TCP/IP System". If there is a file /spool/help/host.hlp, the contents of this file will appear next, otherwise the short message "'?' for help." will appear instead so that the user knows how to get help. If a "message of the day" (see the "motd" command) is set, this will appear. At this point there may be a short delay whilst the mailbox checks whether mail is waiting or present for this user. New mail for the user will be signalled then, followed by the mailbox command prompt (DB3FL) DB3FL de G6DHU> or in the UK version (Msg #1: DB3FL) DB3FL de G6DHU> The mailbox prompt lends itself to the DieBox mailbox style which shows the mail area, user call and mailbox call. The UK version also keeps track of the current message number. Mailbox informational messages such as "*** Connected to", "*** Busy from" etc match those of the FlexNet networking software and so this and other packet software (eg "SP") can recognise a standard format and use WNOS nodes as autorouters. Similarly, connections over NET/ROM conform to that style, although connections FROM a WNOS node require the use of the "nconnect" command. Since we are connected to the mailbox, we can play with a few commands. Not all commands listed by '?' may be available, since each user has a permission level defined in the /ftpusers file. If there are messages to read, just a press of the Return key starts the message reader. If a specific message is to be read, the "read" command is used. Read mail can be deleted from the mailbox using the "kill" command specifying which message to delete. The list of files available for download can be listed with the "what" command. Text files can be downloaded with the "download" command and binary files (programs etc) with the "du" command. Connections to other stations can also be made from the mailbox. The list of known AX.25 autorouter paths can be determined by the "path" command and these stations can be connected to using the "connect <call>" command. Other connections can be made using "connect <call>" on the default interface or with "connect <iface> <call>" on other interfaces. The sysop can be contacted by using the "c" or "chat" commands. Connections started using the "connect" command can be disconnected at any time by sending the "escape" character (Control-X by default). The mailbox can be disconnected through the "b", "bye", "q" or "quit" commands. 7. Short Descriptions of the Important Protocols This is a brief overview of the terminology and purpose of the networking protocols that WNOS uses. 7.1. ARP (The Address Resolution Protocol) This simple protocol is used to determine which link layer address corresponds to an IP address. The link layers used by WNOS are either AX.25 or Ethernet. An AX.25 address is better known as a callsign eg G6DHU-3 plus SSID. It is not often used in full in WNOS since the ARP table is there to provide immediately, the lookup between IP address and link layer address. If however, the desired link layer address is not found in the ARP table, before the IP frame can be sent, ARP must discover the link layer address itself. This it does by sending out a special "broadcast" which is listened to by all TCP/IP capable software (on AX.25 the broadcast address is "QST"). The broadcast basically says "Hello, I'm 44.131.20.3 and I live at link layer address G6DHU-5, I'm looking for 44.131.20.4, tell me your link layer address". Any TCP/IP system hearing this broadcast examines the "I'm looking for <address>" field and if it matches its IP address, it sends back a reply broadcast filling in the missing information. At that point, the machine sending the initial request makes a temporary addition to it's ARP table noting the information it got. In other words, an internal "arp add" command is executed. As soon as this procedure is complete, the TCP session can start. 7.2. AX.25 (Amateur X.25 Protocol) AX.25 is a basic version of the more complicated commercial X.25 protocol cut down for use in the Packet Radio environment. The protocol supports point-to-point connections in which each sent frame is acknowledged as arriving OK by the receiving end, thus ensuring that no data is lost (in network jargon - a reliable connection oriented protocol). Digipeaters may also be used to forward packets unconditionally. Features implemented by WNOS such as hop-to-hop acknowlegement or the AX.25 autorouter are NOT an extension of the AX.25 protocol. Rather, these are ways of implementing the protocol in different ways to provide certain advantages. 7.3. IP (The Internet Protocol) IP is responsible for routing and packet switching functions for upper layer protocols, usually TCP. An IP frame header is made up of amongst other things, the source and destination IP addresses aswell as other control information. 7.4. IPCAM (Internet Protocol CAMouflage) IPCAM is not really a Protocol as such. IPCAM allows IP frames to be transported across different and mixed protocols. It is only currently implemented for use upon AX.25 link layers. Rather than send the IP frame with an AX.25 PID (Protocol IDentifier) of "IP", it is sent with an PID of "Text". It is this feature that makes it particularly useful since some AX.25 systems may not support, recognise or purposely disallow processing of frames with PID="IP". Using IPCAM allows TCP/IP to be used on such networks. 7.5. ICMP (The Internet Control Message Protocol) This protocol is used to provide TCP/IP hosts with error handling, congestion control or resolution and general diagnostic functions and services. 7.6. TCP (The Transmission Control Protocol) TCP is responsible for the logical connection between two TCP/IP hosts and uses IP for its routing functions. Most importantly it provides a reliable stream based connection and ensures that data reaches the remote host without error and for acknowledging receipt of data from the remote host. All of the following protocols are applications (services) which use TCP for the Transport (Level 4) layer and IP at the Network (Level 3) layer. 7.6.1. Telnet Is a simple protocol which allows remote login to another host running TCP/IP. It can be thought of as the TCP/IP equivalent of a TNC-TNC connect using AX.25. 7.6.2. FTP (The File Transfer Protocol) FTP allows files (both text and binary) to be transferred from one host to another. It is also responsible for ensuring that the transfer is succesfully completed. 7.6.3. SMTP (The Simple Mail Transfer Protocol) SMTP provides an electronic mail facility between hosts. It has the capability to route mail from one host to another, for delivery to a user at the local host and sending locally generated mail to its destination. 7.6.4. NNTP (The Network News Transfer Protocol) NNTP provides a service for the posting and distribution of News. Whereas SMTP is used to handle personal mail, news handles 'broadcast' messages. News is divided into newsgroups, each with a specific topic of interest. For interest, the Usenet news hierarchy contains newsgroups; rec.radio.amateur.misc - Miscellaneous amatuer radio discussion rec.radio.amateur.packet - The Packet Radio newsgroup comp.binaries.ibm.pc - Latest IBM PC software rec.humour.funny - Jokes etc etc The hierarchy names represent the broad divisions of interest. For example rec.* newsgroups are the Recreational newsgroups, comp.*, the Computer newsgroups etc. There are lots more of these. NNTP is the analogue of the mailbox Store and Forward network, where news articles are referred to as bulletins. 7.6.5. POP (The Post Office Protocol) POP allows storage and collection of mail destined for a host that is not always in operation. Mail for such hosts is kept on file until a host comes on line, connects to the POP server and asks for its mail. It is useful for AMPRNET TCP/IP stations who are not on air 24hours a day. 7.7. UDP (The User Datagram Protocol) This is also a Transport layer (level 4) protocol like TCP but is much simpler and does not guarantee a reliable transfer of data from end to end. Receipt of a UDP frame is not acknowledged as in TCP. The domain server uses UDP.