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 / WNOS3MAN.TXT < prev next >

Wrap

Text File | 1992-04-04 | 52.6 KB | 1,496 lines

DB3FL WAMPES NOS (WNOS) Version 3 User Guide Mike Chace (G6DHU) Document Version 1.4 (April 1992) WNOS3 is a new "hybrid" NOS and combines functionality from KA9Q, G1EMM, and PA0GRI NOS with a AX.25 front-end derived from the German WAMPES system. 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 like PacketCluster. 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. It has no need for RSPF and RIP since the WAMPES front-end deals with the auto-routing. WNOS periodically saves all routing information (IP, ARP and AX.25) to all known hosts making it a truly dynamic system. This manual is a guide to the new features in WNOS mainly designed for users of other NOS versions (G1EMM, PA0GRI etc) who might be trying WNOS for the first time. You should also have received a copy of the WNOS3 command reference with the UK release package. THIS DOCUMENT *MUST* BE INCLUDED IN ANY COPY YOU MAKE OF WNOS AND GIVE TO SOMEONE ELSE. 1. What's New in WNOS3 ? 1.1. The User Interface 1.1.1. The Status Line Perhaps the first thing that you'll notice after loading WNOS3 is the command screen. The top line of the screen is permanently occupied by the Status Line. The line can be configured for either colour or mono displays (see the "attribute" command). In use, the status line will look something like this WNOS3 | 22:02 | CMD | 1:R:U:GB7IMB-2 2:g4wrw 3:R:44.131.17.11 4:Chat A B C D E F G A) Is the Program Name B) Is the current time C) Shows the program "mode" CMD = Command mode (at the program prompt) TRA = Trace Screen * = Session mode D) Shows session 1 status. Upper case denotes a session to either an AX.25 station or a NET/ROM host (in this case GB7IMB-2). The "R" denotes that the session is in "record" mode, copying session input and output to a file. The "U" denotes that the session is in "upload" mode and a file is being sent to GB7IMB-2. E) Denotes an TCP/IP based connection to a host. TCP/IP hosts are always displayed in lower case. F) Session 3 is connected to TCP/IP host on address 44.131.17.11 and is in "record" mode. G) Session 4 is a local Chat session (someone typed "chat" from the mailbox). IP Stations telnet'ed/ttylink'ed to your Chat port (TCP port 87) don't display as "Chat", instead the address of that IP station is shown. Connections to you local bbs (that is, you typed "bbs" at the program prompt) are shown in the same format and are marked as LocBBS. 1.1.2. The Program Prompt Instead of the old net> prompt, WNOS3 displays you hostname eg. g6dhu.ampr.org> 1.1.3. Moving Between Sessions WNOS3 differs from all previous version of NOS in that moving between sessions is now accomplished through use of the Function keys.... F1 to F8 : Select sessions 1 through to 8 F9 : Toggles between the "Trace" screen and the last selected screen (session or command) F10 : Return to Command Mode ESCAPE : Return to Command Mode (See the "escape" command ALT+F10 : Select the Trace screen - No Toggling. The use of the return key is two fold depending on whether you are in the Trace or the Command screen. ENTER : From Command Mode - Switches into the last selected session ENTER : From the Trace Screen - Switches into the last selected session Please note that in command mode, with no active sessions, pressing ENTER will have NO EFFECT. It's a bit disconcerting at first but you'll get used to it. All trace output goes into the Trace Screen (selected by F9). It no longer scribbles over sessions or the command display. 1.1.4. Editing Characters The following special keys can be used to edit or redisplay input either to a session or at the prompt. Control-B : Fill rest of command line upto end of last input (see below) Control-R : Recalls the previous (complete) line Control-U : Kills the current line Control-W : Deletes the previous word in the current line Up-Arrow : Scrolls backwards through past input Down-Arrow : Scrolls forwards through past input Control-B needs an example. Say the last (valid) command you typed was 'tcp status'. If you then begin to type a new line and press Control-B, the rest of the previous line is added to the new one. g6dhu.ampr.org> tcp status <output from command> g6dhu.ampr.org> ax2 <type Control-B> gives the input line g6dhu.ampr.org>ax2 status Input history is kept separate for each session and the command window. 1.1.5. Session Notification The status line session summary (eg 2:g4wrw) will blink if that session receives incoming data and will continue to do so until you select that session. Once you close session, the status line summary will be deleted and all other summaries move one to the left. Sessions closed by the remote end will of course remain (blinking) on the status line until you look at them. This is a useful feature, allowing someone to drop you a quick message, which you won't lose! Incoming connections to your 'Chat' port will ring a "bell" to alert you to the fact that someone wishes to chat to you. This happens according to the setting of the "bell" command and whether or not you are "attended" (see below). Input to sessions of type Telnet, Chat, Convers, AX.25 and NET/ROM is in a pseudo "split screen" mode. The text you type ALWAYS appears at the bottom of the screen and allows the other persons text to appear as you are preparing that line. Your text is shown in "normal" (light) text and that from the remote end in "intensified" (bright) text. You can use the cursor (up and down arrow keys) to recall past input and scroll through it whilst preparing outgoing text. On selecting a session, you are taken into that session's "window" (which holds its own, separate input history) and the Status Line entry for the current session is shown in "normal" text (white on black). The other, unselected Status Line session entries remain in "inverse" text (Black on white) 1.1.5.1. Colour Displays The above discussion holds on Mono displays (set "attribute mono"). On Colour displays (set "attribute col") Status line columns A, B and C are shown in Red. Further columns (session indicators) are shown in Blue. The arrival of new data to an unselected session is indicated by it having an inverse Grey bar. The current session is in yellow text upon a Blue background, all other sessions are shown in Grey text upon a Blue background. Another feature unique to WNOS3 is that automatic wrapping of outgoing text is enabled in sessions. You can specify a line length limit (see the "wrap" command), if you type beyond this limit, the next space will force the line to be transmitted and the rest of your input line over the line length limit is put at the start of the next line. This means that you don't have to think about pressing return all the time as you near the end of a line. WNOS detects when you have reached the end of the line and sends that text out without intervention. It also eliminates a messy screen at the remote end of the link where lines go over the 80th column. 1.2. The Auto-Router One of the other major changes to WNOS3 is that the NOS AX.25 front-end has been replaced by that from the German WAMPES system. The WAMPES front-end allows full AX.25 auto-routing as well as saving of all routing information (IP, ARP and AX.25 routes) to disk at regular intervals. Unfortunately, the AX.25 auto-router is only of real use in IP networks where nodes are directly connected. By this is I mean that other hosts are reachable through a direct AX.25 connection (VC or datagram mode) or using AX.25 across a digipeated path. This is because the WAMPES system was primarily designed to work with FlexNet, a networking system in widespread use throughout Europe (but not in the UK hihi). FlexNet is a fast system with 1200bps and 9600bps user access ports and 9600bps backbone links and works on the principle of fixed routes between nodes using hop-to-hop acknowledgements (looks like normal digipeating to end users). The auto-router is however still useful over here in the UK. See the "ax25 route" commands in the Command Summary for details of the autorouter. 1.2.1. Using the Auto router I should also note that the AX.25 auto router can also auto route digipeated packets thereby allowing very effective crossband operation. For example, let's imagine that a WNOS3 node local to you has two interfaces one on 70cm and the other on 2m. That system will of course get to know the AX.25 paths to stations on both interfaces. You can then set up connections via the local node which enter on one frequency and get digipeated on the other. For instance, I have a local WNOS3 node, G4OTJ-2 which has a 70cm and 2m interface. G4OTJ-2 knows that there is a path to the KA-node G1WQU-8 on 70cm. If I am on 2m, I can reach G1WQU-8 without knowing how the crossband connection (and if there are any digis involved) is made simply by using the connect command g6dhu.ampr.org> connect 144 g1wqu-8 g4otj-2 So I send a connect request to G1WQU-8 via G4OTJ-2 and the autorouter at G4OTJ-2 works out how to get to G1WQU-8! And, of course, since my autorouter will now have stored the path to G1WQU-8, the next time I want to connect to that station, all I need type is g6dhu.ampr.org> connect g1wqu-8 WNOS3 does away with the need for you to remember how to get to places and lets the software do it all automatically. As you can see, it makes for a very powerful and flexible system. For further details see the "ax25 digipeat" command. 1.3. Dynamic Route Save Each time an IP frame is processed by an WNOS3 system, the machine records the following information in it's various routing tables 1) An IP route entry 2) An ARP entry 3) An AX.25 Path entry (if the IP frame arrived via AX.25) The system therefore dynamically alters its knowledge of routing to other IP hosts and records ALL information necessary to reach that host. For instance, if a node normally reaching you via NET/ROM manages to deliver a frame via direct AX.25 and say over your UHF rather than VHF interface, your system has saved all this information and can alter its return path in response. Other NOS systems will not be able to do so! Each of the routing tables dynamically written to are saved to disk at regular intervals (see the 'route save', 'ax25 route save' and 'arp save' commands). These files are then read from disk the next time you start up and so you never lose this routing information. 1.4. Compression WNOS3 is unique in that it is the first NOS variant to make use of a NOS feature that has long existed, but never been used before - data compression. In the present release, both e-mail and telnet based sessions (eg chat) have the ability to send and receive compressed data using a method that is completely transparent to the users. It is also backward comaptible with non-compressed systems so if you're the only one using WNOS3 you'll still be able to everything you did before. WNOS3 uses the LZW (Lempel-Ziv) data compression method which is used to "squash" text data using LZW coding before it is sent out over the air. Since text contains a lot of redundant infomation such as tabs and spaces LZW can often compress data to upto 40% of its original size. The basic advantages are obvious - you send less real data which improves performance where it's most felt (across a slow RF link) and you're also thereby doing the network a favour by reducing traffic. Obviously, there is a slight penalty in performace at each end of the link in unpacking the data and converting it back into human-readable text but that is small in comparison with the time it takes to send the data out over the air. Line-by-line protocols such as telnet are compressed when you press the return key at the end of the line and then sent out to the remote end. Message (file) based protocols such as SMTP negotiate with the other end of the link to see if it will accept compressed mail. If you "trace" an outgoing SMTP session, you will see that the machines greet each other in the usual way but a sending WNOS node will then send the command "XLZW". If the other end is also a WNOS3 node it responds with "250 Ok" and the mail (and any subsequent commands eg QUIT) are sent out in compressed form. On completing the mail transfer, the remote end will then uncompress the mail before writing it to the appropriate mailbox. Should the remote end not be a WNOS3 node, it will respond to the XLZW command with "550 Command Unrecognised" and the sending end will forward mail as normal. LZW compression is a mainly experimental feature in WNOS3 and may well be extended to NNTP, POP and convers for example if it found useful. If you find it so please drop me or Mike, DB3FL, a line. I think it is a great step forward and should prove useful on marginal links, of which, there are (let's face it) plenty in the UK. 1.5. Convers Node and Cluster Mode 1.5.1. What Is a Convers Node ? The convers (pronounced like converse) node is much like the G8BPQ "CHAT" system or TheNet Mini-Convers and allows round-table QSOs between a number of users connected to it. If you've never used a Chat node before, it's best imagined in the following way. You and your fellow hams all connect to the convers node. On connecting, you are asked to login so that the system knows your name (or callsign) and can then send messages to you. The convers node has a number of "channels" to which 1, 2 or more people can be connected, talking either to each other as a group or sending private messages to each other. So you can think of it as a multi-user "conferencing" system. You can QSY to other channels if you want a simple private conversation with another person and other users can invite you into the "net" on their channel. The convers node software handles all the conversations on each channel independently and sends the conversation(s) out to each user connected. 1.5.2. The WNOS Convers System WNOS3 supports two distinct convers modes which I'll refer to from now on as "local" and "cluster" mode. I'll cover basic use of the system in the section on local access below. The behaviour under Cluster access being exactly the same. To enable your convers server you must put the line start convers somewhere in your autoexec.nos file. 1.5.2.1. Local Mode Any WNOS3 system can enable it's own internal convers node (or server) (see the "start convers" command). The convers server lives on TCP port number 3600. Your local convers server can be accessed in two ways... 1) Remote users telnet to your port 3600 (ie they type 'telnet g6dhu 3600') 2) Remote users (including AX.25 users) can type 'convers' at your mailbox prompt. You can of course login to your local server by typing (for example) g4otj.ampr.org> telnet g4otj 3600 Users connecting from the mailbox get told to login using the convers "/N <name>" command but if you login locally by telnet you'll need to do this before the server will respond and you will then get the convers login banner. Once logged in, you can use the / commands (see /HELP or /H) for help to inquire about the state of the system, who is logged in etc. Private messages to a named user are sent using the /MSG or /WRITE commands (for example)... /M john Hi there John, Just noticed you login! Anything that you type without a / command will be sent to all users logged into your channel (change channels with the /CHANNEL or /C command). Chatter from your channel is sent to you like this <john>: Did you see that there is a new TCP/IP user in the area ? <dave>: No, What's his callsign ? <mike>: I think it's G6DHU <dave>: No it isn't, it's G4WRW <*pete*>: Who cares ? etc Notice that text directed to everybody on your channel has the ID of the person who sent it eg <mike> (So that user logged in with (/n mike). See also that user "pete" (the cynical one!) sent me a private message (not seen by anyone else on the channel) indicated by the asterisks "*" surrounding his user name. 1.5.2.2. Convers Cluster Mode That last discussion took as its example convers users ALL logged into the convers server running on YOUR machine. As I mentioned before, TCP/IP users can do this either by telnetting to your port 3600 and AX.25 Level 2 users can connect by typing the "convers" command whilst logged into your mailbox. WNOS3 has another very useful feature in which convers servers on a number of WNOS3 nodes can be connected together. This brings about the possibility of a distributed conference system much like TALK or CONFERENCE as found in the PacketCluster system. This then enables users logged in on one machine to transparently join in conversation with other convers users who are logged on at a different machine. The convers servers on each WNOS3 node talk to each other passing the various messages back and forth. To enable cluster mode, each WNOS3 node must set up a file in the WNOS root directory (ie in the same place as the FTPUSERS file). This file called "convers.cfg" identifies the name of your convers server and defines the other convers servers you which to connect in cluster with. PLEASE note that cluster servers **MUST** connect in a "daisy chain" otherwise messages just "ping-pong" back and forth, growing each time and probably resulting in network collapse. By "daisy chain", I mean that if, for instance, you wish to interconnect 4 machines, the most sensible configuration would be g4wrw -> g4otj -> g0lxc -> g6dhu so each machine connects to the next down the chain. All you need to do is decide the network and AVOID ROUTING LOOPS AT ALL COST! The format of convers.cfg is as follows <your_host_name> <remote_host_name> telnet|ax25|netrom <remote_host_name> telnet|ax25|netrom etc <your_host_name> is the name of your machine eg g6dhu. You can enter names of any length but only the first 8 characters are used. <remote_host_name> is the name of the machine to connect to. Again, typically you would use the domain name of a remote machine eg g4wrw. With each remote host you must specify the protocol used to communicate with that machine's convers server, either telnet, AX.25 or NET/ROM. **Please note*** that only telnet method is currently supported, AX.25 and NET/ROM are likely to be added later. Please note that "telnet" means the protocol to be used and that telnet connection can of course be carried by AX.25 datagrams, virtual circuits or NET/ROM just the same as any other telnet connection. AX.25 and NET/ROM connect methods will use those protocols to send the convers messages (and therefore not use TCP). Example convers.cfg files for the above example cluster would be At g6dhu - None needed (end node) At g4otj - g4otj g0lxc telnet Obviously more complicated networks will require more "remote host" entries. Imagine a star network for example. On starting WNOS, the machine will read the convers startup file and auto-connect to the remote machines specified in the file. No operator intervention is needed. Once the connections are set up down the chain all users can talk to each other. For instance, an AX.25 user could have connected to g6dhu's mailbox, typed "convers" and be talking to someone logged on all the way down the chain at g4wrw. You can inquire on the state of cluster links to other machines by logging into your local convers server and using the /LINKS (/L for short) command. 1.6. A New Mailbox Interface WNOS has a re-arranged mailbox interface. The most notable changes are that the prompts are more informative and the "psuedo" NET/ROM node has also been remodelled. On logging into the mailbox, users will see the following... [WNOS3-XH$] g6dhu.ampr.org TCP/IP system. Welcome to the G6DHU TCP/IP Mailbox! The Escape Character is Control-X Type C to Chat, ? for Command List, and 'S mike' to mail me You have 1 message (G6DHU) G6DHU de G6DHU> Note first of all that the mailbox SID banner [WNOS3-XH$] now sports the X flag to denote that it is capable of forwarding BBS mail in compressed format (to compatible boxes). The second line (fixed in the program) just announces your hostname to others. The third, fourth and fifth lines are the contents of the following command strings or files motd (Message Of The Day) = Welcome to the G6DHU TCP/IP Mailbox! host.hlp = The Escape Character is Control-X mbox motd = Type C to Chat,... etc The first and third of those above are standard (derived from the G1EMM version of NOS) commands to set the "Messages of the day". The second is a new feature whereby special messages for the mailbox can be specified in file called "host.hlp" (see the Command Summary). If host.hlp is not present, the program just sends the short string ? for Help The final two lines of mailbox login text are of, a mail flag to show if you have any mail waiting for you to read and of course, the mailbox prompt. The prompt shows the following information (G6XYZ) G6XYZ de G6DHU> | | | | | Mailbox Callsign | User Callsign Current Mail "area" As expected, if the user changes mail area with the "area" command (eg "area tcpip"), the prompt is updated to show (TCPIP) in the first prompt field. 1.6.1. Mailbox Commands This is the output from a ? request to the mailbox (short for HELP!!!). (G6DHU) G6DHU de G6DHU> ? Available commands: area bye connect chat convers download escape finger help info kill list mheard nodes nconnect path quit read send telnet user upload what ? (G6DHU) G6DHU de G6DHU> As I mentioned before, perhaps the most obvious change is that the NET/ROM node is now longer a separate part of the mailbox. All its commands are available directly at the mailbox command line. Typing "nodes" will show you a list of NET/ROM nodes known locally and a NET/ROM connection can be made by typing "nconnect <nodecall>". Other new things are the "path" command which displays a list of known autorouter paths, or if a callsign is given too, the path to that destination. As you might expect, users can just type "connect <call>" to reach an autorouted destination. Digipeaters and interfaces are no longer needed. A minor change is the "mheard" command which, as you would expect shows the monitor heard list from your system. Users returning from outbound connections are always returned to the node on disconnection and are informed of this. For example (G6DHU) G6DHU de G6DHU>convers *** connected to 44.131.20.3:convers conversd @ g6dhu $WNOS_Rev: A.2.17 $ Type /HELP for help. /q *** reconnected to G6DHU (G6DHU) G6DHU de G6DHU> In that case a user connected to the cluster and then quitted from it. The same TNC-like connect message is sent when an AX.25 (raw or autorouted) or NET/ROM connect is made. It should at least make non- TCP/IP users a little less frightened of the technology! The usual help scheme as found in other NOS version is included. "?" will give the command list (as demonstrated above) and detailed help is available by typing "h <command>" where <command> would be "path" for instance. These help files live in the usual place (spool/help/*.hlp). 1.6.1.1. Mailbox Timers The WNOS3 mailbox will disconnect a user after a period of inactivity equal to the value you set for the ax25 t3 timer. For instance, "ax25 t3 180" sets the link inactivity timeout to 3 minutes (180 seconds) and on logging in, users will see the extra message Inactivity Timeout is 3 mins (G6XYZ) G6XYZ de G6DHU> The timeout is also dependent as to whether or not the link timer is active (see the "ax25 t3disc" command). Users connected to the mailbox via telnet (TCP port 23) do not receive this treatment. 1.6.1.2. Remote Sysop Mode This has changed substantially in WNOS3. Remote sysop is useful if WNOS3 is running on a remote computer say on a hill-top site. A password number key is entered (by the autoexec.nos file) via the "sysop" command. A mailbox user wishing to login as remote sysop must firstly have the correct FTPUSERs "sysop" permission bit set before using the mailbox "@" command. Entry is gained in the following manner (the pass number key is say "sysop 12345"). 1. Type @ at the mailbox prompt 2. The mailbox responds with 3 groups of 5 numbers in the prompt 89076, 77613, 11680> 3. The intended remote sysop must then calculate the password according to the following formula. Pass number = (Any number in first column * 1st number in key) + (Any number in second column * 2nd number in key) + (Any number in third column * 3rd number in key) + (Any number in fourth column * 4th number in key) + (Any number in fifth column * 5th number in key) Eg (8 * 1) + (9 * 2) + (6 * 3) + (1 * 4) + (0 * 5) = 48 4. Type the password and you should be logged in 89076, 77613, 11680> 48 Net> Successful login as sysop give you the remote sysop prompt as shown above. Yes, yes, I know it's complicated but it's also *extremely* difficult to break the key. 1.6.1.3. Mailbox Message Scrolling By setting the "mbox more" command to "yes" you can enable a function which passes mail messages to users on a page by page basis, prompting for more (or a quit) and the end of each screenful. This function is only active for users connecting to the mailbox via TCP (telnet to port 23). 1.6.1.4. Mail Signature It is common Internet style that most mail messages end with a short 'signature' which gives details such as the senders home address, e-mail address etc. WNOS can automatically add this signature to mail entered into the system from the local bbs (the "bbs" command). The signature lives in a file called <call>.sig situated in the spool\signatur\ directory. The file SETUP.EXE contains an example signature file (G6DHU.SIG) - the one I use here on my system. Remember to keep it short and free of fancy graphics! Fancy graphics may look great when viewed on the same type of machine from which they were entered but display as meaningless crud on other systems! Please note that the signature is only added to the end of messages that are entered interactively into the bbs and not if an external mail program (eg PCElm) is used. These programs add a signature file of their own which usually is called something else and lives in another place! 1.7. The Not-So-Obvious Improvements In this section I'll outline some of the improvements in WNOS3 over other NOS versions or WNOS2 and any consequent changes in syntax. Please refer to the Command Summary chapter for details of command syntax etc. 1.7.1. New AX.25 Features Since the old NOS AX.25 front-end has been stripped out and replaced by the WAMPES autorouter there have been some changes to ax25 parameters. The AX.25 retransmission timer (ax25 t1) is now dynamically set by measuring the round trip time of the connection. WNOS3 measures the time it takes to get an ACKnowledgement (RR) packet back after sending an information (I) frame, this time is known as the RTT. If this time is recorded for a few sucessive packets, the value can be smoothed over time to produce the SRTT (Smoothed Round Trip Time) of the connection. WNOS3 sets the T1 timer to this value and adjusts it as conditions change and a new SRTT emerges. The result should be a more efficient connection. MAXFRAME (ax25 maxframe) is now also dynamically set. The initial value is set to the value specified in the "ax25 maxframe" command. The connection starts with this value and adjusts it by watching the number of frames that are ACKnowledged by the remote end. For example, if you set a maxframe of 6 and your node has enough traffic queued, it will send out a string of 6 sucessive I-frames. Your node now has 6 outstanding (that means unacknowledged) frames. If, on hearing the RR (ACK) from the remote end, it only acknowledges 3 packets, WNOS will drop the maxframe to this value since it guesses (it's a sensible guess too) that 3 of the 6 frames sent were lost. As you can probably see from this, if you kept a maxframe of 6 you would be wasting time with retransmitting 3 out of every 6 I frames which is inefficient and needlessly hogs the channel with data that is wasted. WNOS actually implements dynamic maxframe by firstly setting the maxframe to that specified by the "ax25 maxframe" command. After the AX.25 T1 timer times out, maxframe is set to 1 and increased every time if sent frames are ACK'ed within the lifetime of T1. WNOS can resequence out of sequence packets. It quite often happens that stations can send you data packets that are out of sequence. For example, you were expecting frames 1, 2 and 3 but you got 1, 3 and 4. Normally, most software will dump all but the first packet and acknowledge it even if number 4 arrives quickly after. WNOS will hold 1, 3 and 4 for a time determined by the reassembly timer (ax25 t5) so if packet number 2 arrives before T5 times out, it can reassemble them all (1, 2, 3 and 4) and acknowledge all 4. Again, this increases efficiency. WNOS can do hop-to-hop acknowledgement. On a marginal link using a digipeater, it is often more efficient to have both halves (or all) of the link operating in hop-to-hop acknowledgement mode. This means that if, for example, someone digipeats via you, instead of digipeating the packets on, your node opens a connection to the desired destination to pass the packets on. Packets are therefore being passed using hop-to-hop acknowledgement rather than digipeating. Again, this can increase effeciency and throughput on marginal links (see that "ax25 digipeat" command) WNOS concatenates short frames. If, for instance, you type 3 short lines (ie they total less than "ax25 paclen" in length), WNOS will concatenate these packets and send them as one packet. A useful idea on a good link. 1.7.2. Memory Management The old 'NOS provided' memory management routines have been replaced by those provided by the Borland BCC (C++) compiler. The result is that memory doesn't suffer from the sort of downward spiral always seen in previous NOS versions. If your system suffers heavy useage, the memory will of course drop since each new connection opened requires memory to hold various pieces of information needed (the Control Blocks). After these connections are closed (and/or at regular intervals) the system will check the memory for "holes" where memory has been freed but is too small to be used usefully by something else. All these holes are then gathered together and turned into one large chunk that can be used again. A process called garbage collection and compaction. If you run the "memory status" command at regular intervals during a busy period, you should see the available free memory counter (coreleft) drop. After connections close, you should, after a few minutes, see the memory coreleft total creep up again. The result is that the machine makes better use of memory and since it recovers as much memory as possible, should last longer! 1.7.3. Setping Setping is a small utility that allows WNOS to announce itself as an end node in an TCP/IP network that uses the RSPF (Radio Shortest Path First) routing system. It allows 'pings' (ICMP Echo Requests) to be sent to any host at a regular interval. Note that the function is not exclusively used for communicating with RSPF machines, you can use it to anyone running TCP/IP software. WNOS keeps a table of how many replies it gets to pings sent to each host and assigns a 'link quality' to that host based on the percentage of replies that came back. Typing the "setping" command will display all the hosts with whom you have setping sessions active and the link quality of each. Hosts are marked as "Bad" (host is most certainly down), "Suspect" (host is probably down) or "Good" (the host is up). Setping sessions are stopped with the "resetping" command. 1.7.4. Mode The "mode" command has been extended to allow you to specify a connection mode to any host individually. You no longer need to set a default (and global) mode to reach all your direct hosts (eg mode 144 vc - use AX.25 Virtual Circuits). Instead the mode to each host is specified separately by its own "mode" statement. For example mode g4otj 144 datagram g4otj-2 mode g4wrw 144 vc mode g6den 432 datagram mode [44.131.20.11] vc g4wrw-4 Note that the sytax of the command also allows a path to be specified with the mode to each host. 1.7.5. Route Saving WNOS will save to disk its routing information at intervals specified by you (I use the defaults which are 10 minutes). Routing information saved (and the corresponding files) is :- IP Routing Table (route) - iproute.dat AX.25 Routing Table (ax25 route) - axroute.dat ARP Statements (arp) - arprout.dat NET/ROM Routing Table (netrom route) - netrom.dat This feature is very useful in that the complete system state is saved when the program exits. Since you may have had connects from users for which you had no route entered before (especially if a new user appears), these will not be lost at the next startup. WNOS records ALL pertinent information when a new connection to it is made (ie IP address, interface, ax25 path or NET/ROM call and ARP entry if it was used to reach you). This feature makes WNOS a truly dynamic system. Note that all .dat files are *binaries* and so cannot be viewed or edited. 1.7.6. Chat The KA9Q/G1EMM/PA0GRI "ttylink" command has been replaced by "chat". This sets up a session to a remote host's TTYlink (on TCP port 87). It's just a shorthand for "telnet <host> 87" which would have the same effect. 1.7.7. Mail and Node Activity Log In WNOS you can selectively log activity on your mailbox and mail server. Details of times and stations connecting to the mailbox will be logged to the spool\node.log. Details of mail sent to and from the system are logged in the file spool\mail.log. See the commands "mbox log" for further details. 1.7.8. Socket Writes You can send text out to any connection (known internally to WNOS by its socket number) by using the "socket" command to find the socket number eg 152. From the command window you can then type, for example write 152 Hello John, This is Mike testing a socket write the text specified will then be sent out on the connection which 'owns' that socket. It is also very useful when logged in remotely to the mailbox as sysop (See the Mailbox "@" command). When logged on as sysop you cannot use any commands that start sessions (after all, how could you send the screen updates and new window out to you ?). The socket command is then useful for sending out a message to someone logged in without starting a session. Note that you cannot do socket writes to stations who are just using your station as a digipeater. You can also send messages to multiple users in the same way just by adding the socket numbers you want to send to. For example (it's late and you want to switch off and go to bed)... write 152 144 163 176 Message from Sysop: System switches off in 3 minutes! obviously much quicker than changing to all 4 sessions and typing the same line into each one! 1.7.9. FTP Auto Login WNOS3 takes the drudgery out of having to remember usernames and passwords for use when logging in as an FTP user at a remote machine. In the NOS root directory, you can create a file "nos.rc" which holds your username and password used to login over FTP. Users of the Unix operating systems will recognise the similarity with the ".netrc" file used for the same purpose. The format of the "nos.rc" file is.... <hostname> <username> <password> <hostname> <username> <password> etc For example, if you use g0lxc as an FTP host, you might have an entry in your "nos.rc" file with the line g0lxc g6dhu mikechace When you FTP to g0lxc, WNOS will login for you, sending the "user <username" and "pass <password>" strings automatically. Once logged in at the FTP host, you will see the ftp> prompt appear. 1.7.10. Domain Features 1.7.10.1. Domain Server WNOS now has a built in domain server. This means, for example, that other users, with no or small domain.txt files can query your domain server for the IP address corresponding to the given domain name. Say you use g4wrw as a domain server (ie you have domain add g4wrw...) in your autoexec.nos startup file. You now type "telnet sys2.g6den". Obviously, the first thing that happens is that your machine will search the local domain.txt file for the IP address of the domain name sys2.g6den.ampr.org. If it is not found, your machine will send out a special "domain query" packet to g4wrw's domain server. It will then search its domain file for the details specified. The results of the query (success or failure) then get sent back to your machine. You can then either procede (since you will have been told the IP address to use) or, in the case of failure, the connection will be closed. 1.7.10.2. domain dfile This command allows you to set a path other than the default (domain.txt - in the 'root' directory) to an alternative domain file. For example domain dfile d:/spool/domfiles/mydom.txt 1.7.10.3. BOOTP Server This is really an extension of the "domain server" concept introduced above. The BOOTP server is much like the domain server with the difference in that it can supply any querying machine with ALL the information it knows about routing and the domain. This means that a querying machine can startup with little or no of its own IP or domain information but have it supplied by interrogating the remote BOOTP server. On receiving a query, the BOOTP server supplies the querying machine with a copy of its own IP route and ARP tables as well as a copy of its domain.txt file. Perhaps you can now see the reason for the name "BOOTP" since the server supplies the "boot parameters" for the querying machine. 2. New NNTP Services For those of you that use NNTP (Network News Transfer Protocol) to send and receive news articles, WNOS3 provides both client and server with a fully auto-configuring news system as well as a gateway that will transfer bulletins handled by the SMTP server into the NNTP system as news articles. 2.1. Auto Configuring NNTP System The NNTP system within WNOS3 is now fully auto configuring. All you need to do is supply the various NNTP parameters (see the "nntp ..." commands). News system sub-directories are automatically created if a new newsgroup is handled and all NNTP system files (eg the active and history files) are updated automatically. Both server and client routines are included and you can therefore send articles to others as well as collect new ones from your list of known news servers. The NNTP system files are also created (if necessary) on startup. These are detailed in the "Files and Directory Structure" section below. Obviously, if you are converting to WNOS3 from another NOS version supporting NNTP you can just transfer all of your NNTP system files and articles (after creating the appropriate article directories) and you will be able to carry on as normal. WNOS3 contains a simple, internal news posting program for you to be able to compose and send news articles and transfer them into the system. (See the 'nntp profile' and 'nntp post' commands) 2.2. SMTP -> NNTP Gateway WNOS3 adds a new feature to the NNTP implementation. Mail messages, usually but not necessarily, bulletins can be automatically sent into the NNTP system by the SMTP server. For example, if another IP node mails you all the AX.25 BBS bulletins sent to TCPIP@GBR, TCPIP@EU and SYSOP@GBR via SMTP, you can transfer them into newsgroups, say ampr.tcpip and gbr.sysop. The SMTP server recognises a bulletin 'group' for transfer to NNTP by a special notation in the Alias file (/alias). Alias entries are made as normal but the name to expand to contains the newsgroup name preceded by an exclamation mark (!). Taking my example above, the alias file entries needed would be tcpip !ampr.tcpip sysop !gbr.sysop The normal operation of the alias file isn't changed in any other way. The bulletins are converted to NNTP news articles by the gateway and can then be distributed to others using NNTP. 2.3. UK Version Notes I have added the following features to DB3FL's standard release source code for executables distributed by me to the UK. 2.3.1. NET/ROM Route Saving Each time the 'netrom obsotimer' kicks, the program will save all netrom routes to a file, "NRROUTE.DAT" in the WNOS root. The routes are saved in plain text and maintain the status of the route (eg Permanent or Recorded). When WNOS3 is restarted, it will read the saved routes file and load each route back into the internal netrom routing table. At present, no check is made to age routes since they were last saved, each route is initialised with an obsolesence count of 6. Obviously, any routes that have since aged, will be slowly dropped in the normal way. All I wanted to avoid by implementing this feature, was to stop having to wait for a NODES broadcast from a local node to reload my netrom routes if I had to take the system down for a short while. I should also note, that this does not affect any netrom routes you may set at startup either - they will still be read in too. 2.3.2. Forward Commands I have also integrated G6PHF's code which adds the commands "forward info" and "forward nic". These are used to set fields in a locally generated Mailbox standard R: header which is added to all mail (bulletins and personal) forwarded by the system onto AX.25. See the Command Reference for details and an example of how to set the fields. 2.3.3. SMTP Header Stripping Also integrated is G3UVQ's code to strip all SMTP headers from mail forwarded from SMTP to AX.25. This is a useful addition to reduce the size of messages sent into the BBS network or to PMSes, PBBSes etc. Obviously, SMTP headers are retained on messages relayed, sent or received via SMTP. 3. WNOS DOS Environment Variables WNOS3 reads the following DOS environment variables 3.1. TZ Timezone. Note the CAPITAL TZ! Sets the timezone to be used in timestamping outgoing mail messages and for adjusting the machine clock time to a local time. For example set TZ=GMT+0UTC GMT is the "official" inital timezone name. By official, I mean a recognised name eg PST, UTC, CET etc. +0 is the difference from the initial timezone. UTC is the real (local) timezone name. For a UK example... set TZ=GMT+1BST Meaning BST is GMT plus one hour. The timezone string itself (UTC, BST, GMT etc) that you set is used to stamp mail messages with the time when they were processed. 3.2. MAILER Set the name and location of the mail program called by the "mail" command set MAILER=c:\tcpip\pcelm30.exe 4. Files and Directory Structure The default files and directories used are... alias # Mail Alias file autoexec.nos # WNOS Startup file arproute.dat # ARP statements (autosaved) axroute.dat # AX.25 Routes (autosaved) convers.cfg # Cluster Autoconnect file domain.txt # Domain file finger\ # Finger information directory ftpusers # FTP and Mailbox user Permissions iproute.dat # IP Routes (autosaved) nos.rc # FTP Auto Login data popusers # POP user and password file spool\ \areas # List of mail areas \forward.bbs # Mail forwarding instructions \help\ # Mailbox Help file directory \history # Bulletin ID (BID) history file \mail\ # User Mail files (eg g6dhu.txt) \mqueue\ # Outgoing Mail Queue \news\ # NNTP root directory \news\active # List of active Newsgroups \news\history # NNTP Message ID history file \news\junk # Newsgroups for junking \news\pointer # Pointers to newsgroup storage directories \news\poll # NNTP poll file \news\xinfo # NNTP XINFO (site information) file \rewrite # Mail Address Rewrite file \rqueue\ # Mail Router Queue \signatur\ # Mail signature directory Directories are shown with a trailing slash, ordinary files without. 5. Source Code Source code for WNOS3 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 the mail me with a message informing me of who the code was given to. This is just so that I can keep track of who has source code and pass on these details to Mike, DB3FL. 6. 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 been built from anything other than the official release sources. Some users will have the source code - to "roll their own" and if they change it and give you a copy of the program built from those sources then direct your bug reports to them - OK ?! I can be reached in the following ways. NTS Mailbox - G6DHU @ GB7IMB 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 WNOS3! Mike - G6DHU 7. Change Log v1.1 30th November 1991 (WNOS3alpha10) First Issue. v1.2 4th Jan 1992 (WNOS3a9) Added sections on NNTP system and SMTP/NNTP Gateway. Second Issue v1.3 31st Jan 1992 (WNOS3a9_1) Cleanup a few point following comments from DB3FL. v1.4 4th April 1992 (WNOS3b1_2) Added bit about mail signature file.