MINI-MANUAL for the mods to KA9Q's Internet Protocol Package NOS.EXE version 911229 WG7J's JNOS v1.06 November 19, 1992 Copyright, 1992 Johan. K. Reinalda, WG7J/PA3DIS (email: johan@ece.orst.edu, packet: wg7j@wg7j.or.usa.na) INTRODUCTION. This mini-manual attempts to explain some of the modifications I made to the KA9Q NOS.EXE program. It is NOT a 'beginner's intro' for the NOS.EXE program. I assume users have a basic knowledge of the NOS.EXE program; ie. users should be familiar with using and setting up the basics of the program. The file INTRONOS.ZIP contains an introduction document written and copyrighted by John Ackerman, AG9V. It is included in this distribution with his permission. Please ALSO read the 'README.NOW' file. This has a cronological and much more complete listing of the mods i've made in each of the versions. Another usefull document might be 'JNOS40.MAN'. This is the manual for the port of NOS to the Kantronics Data Engine. A lot of the commands in that version are similar to the JNOS code (same author, so that happens :-) )... It has sections on setting up ax.25, netrom, etc. that might be useful for jnos users. Some of the sections in this document are copied directly from JNOS40.MAN, since i considered them important issues (and why re-invent the wheel :) Some of the modifications I made have been ported into the 'mainstream' release of PA0GRI's versions 1.9c and later. They are documented in PA0GRI's NOS_1229.MAN, that accompanies his releases. Those mods will not be discussed unless needed. (this concerns mods from v0.93 and earlier) Furthermore this manual gives an example of how to use this code as a full-service BBS. I run the code as the full- service BBS for Corvallis, OR and surroundings. The example files listed are from this setup. I do NOT claim that this is the best way to setup NOS for such purpose. I simply provide the setup as ONE possible way to configure things. The examples and their explanations are far from a good tutorial. They are simply meant to show the 'reasoning' I use with handling mail on my system. Users deciding to use NOS as a fullservice bbs could use this as a starting point and go from there... For those interfacing with both tcpip based SMTP mail and the bbs network, I have included a few hints, too. WHAT'S NEW See the file 'readme.now' for a short description of all the mods for each version... QUESTIONS BUGS, COMMENTS, REQUESTS, ETC... should go to the addresses listed above (in that order of preference!) CONTENTS: COMMANDS/CHANGES. 1. mbox commands 1.1 attend 1.2 convers 1.3 fwdinfo 1.4 haddress 1.5 hideport 1.6 jumpstart 1.7 kick 1.8 mailfor 1.9 maxmsg 1.10 motd 1.11 mailstats 1.12 mport 1.13 newmail 1.14 nrid 1.15 past 1.16 password 1.17 qth 1.18 secure 1.19 sendquery 1.20 smtptoo 1.21 status 1.22 timer 1.23 tdisc 1.24 tmsg 1.25 trace 1.26 utc 1.27 zipcode 2. netrom commands 2.1 alias 2.2 bcnodes 2.3 bcpoll 2.4 call 2.5 hidden 2.6 interface 2.7 load 2.8 neighbour 2.9 tdisc 2.10 route info 3. onexit.nos 4. at command 5. bulletin command 5.1 check 5.2 date 5.3 loophold 5.4 return 6. callserver 7. user permissions 8. mailbox user commands 9. oldbid 10. expire 11. ftptdisc and the ftp client 12. TRACING 13. F-Key SESSION SWITCHING 14. NTS traffic deletion. 15. FORWARDING. 16. SETTING UP THE CONFERENCE SERVER 17. OF PACLEN'S, MTU'S, MSS'S AND MORE 18. INTERFACE BUFFERS 19. PER INTERFACE PARAMETERS 20. IP-heard CONFIGURING NOS.EXE AS A FULLSERVICE BBS. /autoexec.nos /ftpusers /alias /spool/areas /spool/rewrite /spool/forward.bbs /onexit.nos GATEWAYING BETWEEN SMTP AND AX.25 MAIL. mail from smtp -> ax.25 mail from ax25 -> smtp POP SERVICES IN NOS EPILOGUE. /***************************************************************/ COMMANDS. --------- 1. 'mbox' This is the main command used to set most of the mailbox options. There are quite a few subcommands, some of wich are discussed here. 1.1 mbox attend [on|off] This displays or sets the attend flag. If set, users can initiate chat with the sysop via the O)perator mailbox command. (You need to have started the ttylink server for this !) 1.2 mbox convers [on|off] This displays or set the convers flag. If set, users are allowed access to the conference bridge by giving the mailbox 'C' command. 1.3 mbox fwdinfo [string] This displays or sets the string that is used in the BBS R: header when forwarding mail to other bbs's. 1.4 mbox haddress [string] This displays or sets your systems hierarchical bbs address. You do not need the bbs call, nor the '.' between the bbs call and the hierachical address. EG. mbox ha or.usa.na 1.5 mbox hideport This command allows you to hide a port from the mailbox 'P' display. If you set a port to be hidden, a user can not 'see' the port unless the user has sysop permissions. AX.25 connections will also be disallowed. This is usefull for forward-only ports, etc... 1.6 'mbox jumpstart ' and 'mbox jumpstart exclude [call1 call2 ...]' subcommands The standard 'vanilla' KA9Q code requires users connecting to the system to hit an additional line in order to trigger the mailbox. This is a problem inherent to the AX.25 protocol. If jumpstart is off, the code behaves like this. When jumpstart is on, incoming connections that satisfy the criteria described next, will get the prompt IMMEDIATELY ! Presently, incoming connections can be requested for five different reasons: A - user connections, B - node connections to carry netrom 'circuits', C - IP in VC mode, D - RSPF run in VC mode, and E - others (am I forgetting any ?). In many situations most AX.25 connections will be coming from users wanting to connect to the mailbox. When jumpstart is on, a 'smart guess' is made. The mailbox is jumpstarted IF: - the incoming connection is NOT a known neighbour node (case B) - and the interface that the connection came in on is NOT in VC mode (case C) - and the call of the incoming station is not on the excluded list (cases D and E); see later IF the incoming connection satisfies all these requirements, the mailbox is jumpstarted and the prompt is send immediately. Some known situations that can cause the mailbox incorrectly to be jumpstarted are the following: -If nodes try to connect before we have heard there nodes-broadcast we will not know of them as a netrom system and jumpstart the mailbox. (this should be solved with the 'netrom load' command now working; see later) -If RPSF is run in VC mode, route updates will be send over a connection instead of with UI frames. This will also incorrectly cause a jumpstart to occur In order to prevent these situations, the exclude command can be used. 'mbox jumpstart exclude call1 call2 call3 ...' will build a list of calls to exclude from jumpstarting. You can give several call with one exclude command, or give multiple exclude commands. A simple 'mbox jumpstart exclude' will show the list... eg. if you want to make sure that neighbour node k7uyx-1 does not trigger the mailbox before we've heard one of his node broadcasts, add mbox jumpstart exclude k7uyx-1 eg. if w7abc is sending rspf route updates via VC, the following helps: mbox jumpstart exclude w7abc 1.7 mbox kick This is an immediate command. If forces the system to start a new bbs forwarding cycle. 1.8 'mbox mailfor [interval]' or 'mbox mailfor exclude [area area]' Interval is in seconds, and if set, every so often the system reads all none-area mailboxes and checks them for unread mail. Next a beacon is sent on all active interfaces. (see 'mbox mport' command). This beacon packet is addressed to the AX.25 address 'MAIL'. The data in this packet contains a list of the mailboxes with unread mail. This is sent in a 'Mail for: ... ' line. Systems like LAN-LINK can trigger mail-snatches off this. A simple 'mbox mailfor' will show the status of the timer and list mailboxes with unread mail. In certain cases you might not want a private area to show up in the mail beacon. Eg. private areas to be forwarded to other bbs's. You can exclude those from the beacon by adding exclude commands. 'mbox mailfor exclude area1 area2 area3' will disable these area names from the beacon. You can give multiple exclude commands to build the list. A simple 'mbox mailfor exclude' shows the list. 1.9 mbox maxmsg [n] This displays or set the maximum number of messages in a mailbox file, for both private and public (ie area-) mail. If there are more the n messages, the user will only see the first n messages. 1.10 mbox motd [string] This displays or set the message of the day. This message is displayed when regular users log on to the system. 1.11 mbox mailstats This commands shows how many messages have been read and sent by users and how many messages have been received from and forwarded to bbs's. 1.12 mbox mport [] Displays or sets the interfaces that 'MAIL' beacons are sent on. Only ports that have this flags set send the beacons, so you need to have one of these line for all ports you want the mail beacon to be sent on. 1.13 mbox newmail [on|off] If on, users will be notified during the login stage wich areas have new mail in them. This uses a time stamp on a status file for each message area, and compares this to the last time the user logged out. The information shown can later be repeated with the 'AN' mailbox command. 1.14 mbox nrid [on|off] This displays or sets the netrom-id flag. If set, the first time a user log on to the system, the system will add the netrom node id in NODE:CALL format to the prompt. Users can then change it with the mailbox XN command. The system will acknowledge the new prompt format as set by the user the next time the user logs in. 1.15 mbox past This is displays the users that have logged on since the system has been running. 1.16 mbox password This sets a new remote sysop password. 1.17 mbox qth [location] This displays or sets the location of your system, and uses it in the R: headers when doing bbs forwarding. 1.18 mbox secure on|off This displays or sets the mailbox secure flag. If set, only users coming on over netrom and ax25 connections can make gateway connects if they have the right priveledges. If not set, anyone with the right privs can do a telnet connect. 1.19 mbox sendquery [on|off] If on, users will be queried if they really want to send the message after they have typed the ^Z or /ex when sending a message. 'N' or 'n' will abort, anything else will send the message. 1.20 mbox smtptoo [on|off] This displays or sets the smtp headers flag. If set, the system will include most smtp header when forwarding the message via bbs forwarding. If not set, they will be stripped (the default) 1.21 mbox status This displays the current users of the system. 1.22 mbox timer [] This displays the forwarding timer value. This sets the interval between forwarding attempts. 1.23 mbox tdisc [] This command sets an inactivity timer, in seconds. If no user input has been received while connected to the mailbox, the user will be disconnected. Default time is 0 seconds, ie no timeout. 1.24 mbox tmsg This displays or sets the 'telnet message'. This is a message sent to telnet connections before the login prompt is sent! 1.25 mbox trace [on|off] This displays or sets the value of the trace flag. If set, the mailbox is verbose about certains aspect of the forwarding cycle... 1.26 mbox utc [n] This displays or set the offset from UTC for this system. It is used in the forward code to calculate the current time. 1.27 mbox zipcode [] This allows you to set (or show) the systems mail zip-code. This is used in the R: line when forwarding. 2. netrom command These commands all influence netrom behaviour. Not all are discussed here. 2. 'netrom' subcommands 2.1 netrom alias Set or show the netrom alias. There is just one alias for the system. 2.2 netrom bcnodes This will force a broadcast of the nodes list on the given interface. 2.3 netrom bcpoll This will force a broadcast poll on the given interface. Systems running JNOS1.05 or later, or DataEngines running JNOS40, will respond to this by broadcasting their nodes list. This speeds up route-discovery at boot time ! Eg. add this to the autoexec file for each activated netrom interface. This was primarily written for the DataEngine code, that doesn't have the 'netrom load' from disk capability. 2.4 netrom call Set or show the netrom interface call. This can be different from the ax.25 mycall parameter, but if not set will default to this. This is the call used for all netrom connections and broadcasts. Setting the netrom call with 'netrom call' is analogous to 'ifconfig netrom linkaddress ' 2.5 netrom hidden [on|off] This displays or sets the hidden flag. If set, the mailbox nodes listing (the N command) will not show nodes who's alias starts with a '#' character. 2.6 netrom interface [ [v] ] Without arguments, it displays the currently active netrom interfaces. If iface and quality are given, it will activate, or change, that interface for netrom traffic with the given quality. The default broadcast method is non-verbose, ie broadcast ourself only. If you want verbose broadcasting, add the optional v parameter. 2.7 netrom load This now works as advertized. It will load the netrom routing table from the file '/netrom.sav' as written by a previous 'netrom save' command. 2.8 netrom neigbour Shows a detailed listing of known netrom neighbours. 2.9 netrom tdisc This is the same as the AX.25 t4 timer. If set, when no data has come in for the timeout period (over the Netrom connection), the circuit is reset. 2.10 netrom route info [node name] This command, without any node name, gives info about all known netrom routes off the system. If given with a node name, it will give info about that node only. 3. /onexit.nos If present, the 'exit' command will execute commands in the /onexit.nos file, before the system exits. (this code by iw0cnb, inspired by pe1chl's net.exe) 4. 'at' command The 'at' command allows timed execution of valid NOS commands. (this command is also from iw0cnb's code, with a few mods.) The "at" command with no arguments shows the list of events that are to be executed. There are a couple of forms of setting up timed execution: at yymmddhhmm Executes at specified date, expressed in Year-Month-Day-Hour-Min. If specified date is past, the command is not executed. at hhmm Executes at specified hour and minute of the current day, or of the next day if the specified time is past. at mm Executes at the specific minutes past the hour at the first occurence possible. This is usefull to start things like forward cycles at certain minutes into the hour. at now+hhmm Executes hh hours and mm minutes from now. hh and mm can be up to 99. at now+mm Executes when it is mm minutes past the hour. Eg. if it's 1:32 now, and you give a 'at 14 ', then at 2:14 the command '?' will be executed. Notes and examples: may be any valid NOS command, possibly enclosed in quotes, as well as a DOS shell command. If you want multiple commands to be executed, use the "source " command. The third mode of operation requires the exact writing "now+" in lower case and without spaces between hhmm. Single command execution examples: at 9202150900 exit /* Shuts off on 15 Feb 92 at 9:00am */ at 2245 "! /c pkzip oldmail \spool\mail\*.*" at 25 "mb timer 3600" at now+0500 "smtp kick" Multiple command execution examples: at now+0859 "source cleanup.net" When multiple command execution is setup, this command allows all sorts of interesting things; if for example 'cleanup.net' has the line 'at now+0859 "source cleanup.net" then the commands in the command-file 'cleanup.net' will be executed every 9 hours 5. 'bulletin' command All of the subcommands have to do with interpreting the R: lines sent when a bbs is forwarding to our system. 5.1 bulletin check [] If 'on', a list of bbs's that we forward to is automatically read from forward.bbs. Next, when a bbs forwards mail to us, all 'B' type messages and all mail with a BID is checked. The R: headers trail is read and checked for bbs's in our list. If found, X-Forwarded-To headers are added to the internal mail headers of the message. These headers are read by the forward code and prevent forward attempts for messages that are already at the destination forward bbs. This makes the forward code more efficient. (All messages with a BID are checked to make it work with things like 'sp sysop @ allusw < $bid') Plain 'bulletin check' will show status, and if on, the check-list. 5.2 bulletin date [] If 'on', when a message is forwarded to us from a bbs, the R: headers will be read to obtain the message origination date from the last R: header present. This will then be used as the 'Date: ...' line in the message, thus better indicating the message's age. 5.3 bulletin loophold [<#>] This sets or shows the number of loops after wich a message will be held and not forwarded anymore. Default is 2. If a message if receive that already has this number of our header lines (ie. R: lines) in the message-headers, it will be marked as held. 5.4 bulletin return [] If on, when a message is received via bbs-forwarding a 'valid bbs-style return address' will be taken from the last R: header, if one is present. This works with any message type that starts with R:-headers (so personal mail as well). This address will then be used as the 'From: ...' line in the message eg. If the message is forwarded as 'SP W7ABC < W6XYZ' and the last R:-header is R:920312/1200z @:N7PQR.AB.CD.EF [TEST] #:0 Z:1 then the 'From:' line will read: 'From: w6xyz@n7pqr.ab.cd.ef' IMPORTANT !!!! Since in most of these occasions, the from-hosts will NOT be tcp/ip hostnames (eg. wg7j.ampr.org) but rather bbs H-addresses (eg. WG7J.OR.USA.NA) YOU (ie. the sysop) HAVE TO MAKE SURE your system can handle these new addresses by setting up the ALIAS and REWRITE files to handle these, and then setup bbs-forwarding (if needed) as well with FORWARD.BBS (see later for examples) 6. 'callserver ' command This configures the (ie. hostname or address) and tcp to be used in the mailbox 'CALL' command (See later). This 'CALL' command is an alias or shortcut for an automatic telnet connect to set host and port. This is mainly useful for gateway systems on Internet. It allows users to use a tcp-reachable callbook-server in an easy way. (or for that matter, any service reachable via telnet) Note: User needs to have telnet permissions eg: 'callserver marvin.cs.buffalo.edu 2000' then the mailbox 'call' command will try to telnet to this host/port and users will be connected to the callbook server. 7. MAILBOX USER PERMISSIONS The user permission in 'ftpusers' have the following values: #define FTP_READ 1 /* Read files */ #define FTP_CREATE 2 /* Create new files */ #define FTP_WRITE 4 /* Overwrite or delete existing files */ #define AX25_CMD 8 /* AX.25 gateway operation allowed */ #define TELNET_CMD 16 /* Telnet gateway operation allowed */ #define NETROM_CMD 32 /* NET/ROM gateway operation allowed */ #define SYSOP_CMD 64 /* Remote sysop access allowed */ #define EXCLUDED_CMD 128 /* This user is banned from the BBS */ /* 256 and 512 are used in PPP*/ #define NO_SENDCMD 1024 /*Disallow send command*/ #define NO_READCMD 2048 /*Disallow read command*/ #define NO_3PARTY 4096 /*Disallow third-party mail*/ #define IS_BBS 8192 /*This user is a bbs*/ #define IS_EXPERT 16384 /*This user is an expert*/ #define NO_CONVERS 32768 /*Disallow convers command */ NOTE: the 'mbox expert' command is gone; each user now has a status bit for this. The mailbox 'X' command will toggle status, but not upgrade ftpusers... 8. MAILBOX USER COMMAND CHANGES First of all, the present code KEEPS TRACK of the user's 'progress' in public areas. The message id of the last message listed in remembered and when the user changes areas or logs off, the id is stored in a .USR file. These files are automatically created as needed in ~/spool/mail . Next time a user changes to the area, the L command will only list messages newer than the last one previously listed. There is one exception: the area 'HELP' (if it exists) will NEVER be kept track off. All messages will ALWAYS be new. My users agreed that this was a good way of easily accesing help-messages. My 'mbox motd' points out the help area, and not logging this causes all help messages to be listed each time the 'L' command is given. New users do not need the LM, LA, and LL subcommands... The mailbox supports several new commands; several of them implement popular user commands from other bbs software. - A, AF and AN A will give a listing of available message areas; AF gives the same listing, plus a description of each area if set by the sysop AN will list wich areas have new mail since a user last logged out. - IP show the ip routes the system maintains. - RM and VM is now supported. It will 'read' or 'verbose' at most 19 new messages in the current area. (19 is inherent to the cmdparser and the current implementation of RM and V) - RH to Read with Headers, is the same as 'V' - KM to Kill Mine, kills all read messages in current area. - KU to Un-kill a message that was previously marked to be killed. - LM, LA, 'L> xyz' and 'L< xyz' are now supported. LM is the same as 'L', and simply lists new messages. LA will list ALL messages in the current area. L> and L< will search for the string 'xyz' in the To: and From: field, respectively. - M, ML, and MS The 'M' command shows Mailbox-users and their activities. (reading, sending, uploading, idle, etc...) Users in sysop mode will show as Idle to regular users and as 'Sysop mode' to users with sysop privs ML shows all users that have connected since the system was started, how many times they logged in, and the time since they last logged in. MS shows the status of messages (same as 'mbox mailstatus'), and also gives a few system 'health and use' parameters. - CALL If compiled in, tries to establish an automatic connect to a host and port as setup with the 'callserver' command. This is mainly useful for systems on internet that want to allow users to access callbook servers (eg. marvin.cs.buffalo.edu:2000). - NR Nroutes will show a detailed list of all known netrom neigbours (same as 'netrom neigbour' subcommand) - 'N *' This gives info on all routes - Q call If compiled in and configured, this will query the HamBase CD-Rom callbook for the given call. - X will toggle the prompt between long and short version -XA will toggle the area indication on and off. -XN will toggle the netrom-id prompt on and off. - XM shows the number of line before more? will be prompted. Defaults to 0 on anything but telnet connects and 24 on telnets. XM n will set the more? prompt to n lines. NOTE: the above X command setting are retained across logins. - SR and SC SR: Send Reply works again. SC: Send with Carbon copy. The system will ask the user for a list of addresses to also send the message to. It prompts "Cc: " User can then type additional addresses, separated by comma's to wich the message should go aswell eg: you type: "SC johan"" system replies: "Cc: " you type: "ron@wa7tas,ka7ehk@wg7j, allor" system replies: "Subject:" etc... 9. 'Oldbid' command As of v1.01 all bid's (bulletin id's) stored have a timestamp added. This facilitates the automatic deletion of old bid's. The 'oldbid' command will expire bid's older then a certain age. To setup bid expiry, the format of the command is: oldbid interval [age] where interval is the interval time in hours, age is the age of the bid in days. If no age is specified, it defaults to 21 days. When the command is first given, the bid file is scanned for old entries, and then every 'interval' hours it is scanned again. The old bid file (/spool/history) will be renamed to /spool/history.bak, and then all entries still valid are copied over to a new history file. Giving plain 'oldbid' will show the status of the timer and the age set. 10. 'expire' command. As of v1.01, there is a very simple automatic message expiration capability. Messages older then a given number of days will be deleted from the mailbox file after a backup copy of the whole file has been made. Configuring automatic expiration consists of 2 parts: a - setting the interval timer. This is done with 'expire n', where n is the number of hours between expire checks. * A simple 'expire' will show the status of the timer. * 'expire now' will start expiration immediately and restart the timer (if set) b - Configuring the '/spool/expire.dat' file. This file is the control file read by the expiry process. It contains entries of mailfiles and ages. The format is 'areaname age', where areaname is a valid mailbox file in /spool/mail and age is the maximum age in days. Any format to indicate mailfiles in subdirectories below /spool/mail is valid, so either '/', '\' or '.' can be used. Lines starting with '#' or blank lines will be ignored. NOTE1: the areaname should NOT have the .txt extension added !! NOTE2: the 2 fields have to be separated by one space!! NOTE3: expiring messages in subdirectories has only been tested with smtp mail files, NOT with NNTP originated messages. Thus it might not work with those... NOTE4: the date used is the entry in the 'Date: ' header, NOT the entry in the 'From ' line that starts the message. Thus, if the 'bulletin date' command is on, the origination date, not the reception date, is what expires a bbs message. Some examples: in autoexec.nos: # expire once a day 'expire 24' in /spool/expire.dat: #keep this area very short allusa 7 #this is in a subdirectory below /spool/mail rec.radio/amateur\packet 21 #and so on allor 14 pnw 10 HINT: if you want the expiration of bulletins to occur at a certain time of the day INDEPENDENT from when you start NOS, use the 'at' command eg: if you want it to happen in the middle of the night (assuming your system's clock is in local time ;-) ) 'expire 24' #sets the interval 'at 0200 "expire now" ' #forces expiration, and restarts the timer 11. 'ftptdisc' command This commands sets or shows the ftp user inactivity timeout. If not zero, when a user connects to the ftpserver, the timer will be started. If user doesn't give a command for the timeout period, the session will be closed. This is disabled during any transfer; ie it only works while the user is in command state... Doug Crompton, WA3DSP, has added some online help for the ftp command, the iw0cnb resume code, and more. Here is what Doup writes about that: I have added some FTP commands and updated some others. This is going in my direction of a more user friendly NOS. FTP added commands (at the ftp prompt) 'h' || '?" Display FTP help - list ftp available commands 'lcd' List current LOCAL directory. The local directory inherits the system current directory at FTP start. Each ftp session started by the client has it's OWN copy of the state of current directory. This directory prefix based on the rules below is applied to local filenames used in put/get/mput/mget commands. Path names entered are checked for validity of both drive and directory on the current system. This should work for any valid DOS drive/directory on the system such as CDROMS. 'ldir ' List directory. Current directory is listed if path is omitted. Path is appended to current local directory unless it contains a '/' in the first position, a ":" in the name, or the '.' or '..' charcters. Examples: If the working directory (set by lcd) is set to 'c:/temp' and the ldir command path is not entered the path becomes 'c:/temp/*.*' If the ldir path is '/nos' the path becomes 'c:/nos/*.*' If the ldir path is 'a:' the path becomes 'a:*.*' and if the ldir path is 'temp2' the path becomes 'c:/temp/temp2/*.*' In short it is what you would expect. '.' and '..' are supported in both directory paths and filenames. 'lmkdir ' Same rules apply as above. 'rput ' Resume putting the file at a remote server. This will restart a previously interrupted put. Note that you must have overwrite priveledge at the server to do this. 'resume ' Resume getting a file from the remote server. This will restart a previously interrupted 'get' Both of these commands depend on an unchanged source file and a partial file. The partial file is compared to the original and only the remaining bytes are sent. An example of the use of these commands would be: ftp wa3dsp login ... connected ... ftp>cd /pub/docs ^P ftp>lcd c:/tcpip << directory exists ftp>mkdir docs ftp>lcd docs ftp>mget *.* This would copy all files at the server in diretory /pub/docs to the local directory c:/tcpip/docs This is just one example, often you would set the remote directory 'cd ' and the local directory 'lcd ' and then simply say 'get ' or 'put '. Added to this flexibility is the ability to do this in multiple sessions to different or the same server(s). Further Directory Examples: ftp>lcd Current Directory - c:/tcpip ftp> lcd spool Current Directory - c:/tcpip/spool ftp> lcd .. Current Directory - c:/tcpip ftp> lcd d: Current Directory - d:/dosdir << if 'd' drive exists and this is ftp> lcd temp the first logon to this drive Current Directroy - d:/dosdir/temp it assumes the DOS current ftp> lcd c: directory for this drive. Current Directory - c:/tcpip ftp> d:/ Current Directory - d:/ The Nos main command 'dir' now uses the same rules as 'ldir' above. You can now do 'dir a:' - which expands to 'dir a:*.*' Example: EXPANDS TO pwd c:/nos dir >> dir c:/nos/*.* dir spool >> dir c:/nos/spool/*.* dir /spool >> dir c:/spool/*.* dir a: >> dir a:*.* dir spool/mail/*.txt >> dir c:/nos/spool/mail/*.txt Try this one... get anyfile.xxx (wait until half or some portion of the file is received) F10 reset Establish the ftp connection again resume anyfile.xxx (must be same name as above) (and the rest of the file will be sent) Added Functions - In ftpcli.c static int doldir __ARGS((int argc,char *argv[],void *p)); static int dolcd __ARGS((int argc,char *argv[],void *p)); static int dolmkdir __ARGS((int argc,char *argv[],void *p)); In dirutil.c char * make_dir_path(int count,char *arg,char* curdir); char * make_fname(char * curdir, char * fname); char * init_dirs(struct cur_dirs * dirs); void free_dirs(struct cur_dirs * dirs); int dir_ok(char * path,struct cur_dirs * dirs); struct cur_dirs { int drv; char * curdir[27]; char * dir; } ; In pathname.c and pathname.h Function 'crunch' - remove 'static' definition Using these functions - Example: #include "dirutil.h" and other required headers... main() { char newpath[128],fname[128], *p; /* * Create Structure 'dirs' which stores * local status of system drives and directories */ struct cur_dirs dirs; printf("Local Directory - %s\n",init_dirs(&dirs); gets(newpath); /* * Pass Requested path and dirs structure * to 'dir_ok' - returns 1 on success, 0 failure */ if (dir_ok(newpath,&dirs) { p=dirs.dir; printf("Current Directory - %s\n",p); } else { printf("Invalid Directory - %s\n",path); } gets(fname); /* * Pass Requested filename and current directory pointer * to 'make_fname' - returns pointer to fully qualified * name */ printf("Fullpath = %s\n",make_fname(p,fname)); /* * Cleanup allocations done in above functions */ free_dirs(&dirs); } An example of how this is done in NOS code is in 'ftpcli.c' Here a structure pointer to 'dirs' is stored in the 'ftp' structure. Pathname is changed in the 'lcd' function and calling parameters follow the requirements for passing a structure to a structure. In ftpcli.c function 'doftp' struct cur_dirs dirs; ftp.curdirs = &dirs; ..... tprintf("Local Directory - %s\n",init_dirs(&dirs)); ..... free_dirs(&dirs); functions to get/put local files - ftp structure passed vvvvvvvvvvvvvvvvv if((filel = fopen(make_fname(ftp->curdirs->dir,&argv[i][1]), "r")) == NU LLFILE){ tprintf("Can't open listfile: %s\n", &argv[i][1]); continue; } lcd function - ftp structure passed vvvvvvvvvvvv if (!dir_ok(argv[1],ftp->curdirs)) { tprintf("Invalid Drive/Directory - %s\n",argv[1]); return 1; } } vvvvvvvvvvvvvvvvv tprintf("Local Directory - %s\n",ftp->curdirs->dir); return 0; ************************************************************************* In general the current directory/filename handling in NOS needs to be looked at. It is not clear what depends on the system working directory. I would rather see nothing depend on it since it is a global value which effects all file and directory operations. Since NOS is a multitasking system it makes sense to keep this value private as needed in each session. The dirutil.c file needs some cleanup which I did not get to. In particuliar I suspect the wildcardize function is obsolete given the new code. Also as the function parameters are always put through 'undosify' (\ to /) tests for '\\' are not needed. If your function needs '\'s changed to '/'s call undosify(char *) This applies to MANY places in NOS where this conversion is done over and over. Granted it is just a couple of lines but that adds up!! Has anyone ever compiled a list of all of the functions in NOS with a brief description of what they do so that others can use existing code? There is no reason to change either the drive or directory at the DOS level in NOS and in fact with a multi-tasking system this is kinda dangerous. Especially if other functions are not aware of it. Better yet use FULLY qualified drive/directory names. These functions have been applied to the ftp client routines but there is no reason why they could not be used in the server also. Maybe with an additional 'permission file' drives and directories could be authorized. Something like: c:/pub/ * 3 < trailing slash - this and all below c:/games * 3 < none below d:/ * 3 m:/ * 1 < maybe a cdrom c:/myfiles mypass 7 < password protected This would allow a user to specify drive/directory authorization on a system and even specify a password for that directory - assuming the authentication code was used (future) this would work. The ftpusers files would specify the login user/pass and the login directory. This file would specify what drive/directories were permitted on the system and what level of permission each had. Doug WA3DSP 12. TRACING Tracing can now be done to a separate session. This is the new default. You can toggle to and from this trace session with the F9 key. Sometimes there are times you want to see the tracing while typing some commands. This can be done with the new command 'strace on/off'. This defaults to ON, but when turned off, tracing will go to the command screen. If then turned on again, it will go to the trace (F9) screen again... For the memory hungry, session tracing can be turned off from the command line that starts NOS.EXE. Start it with a '-n' option to save about 4 kbyte of memory. This turns of the functionality of the 'strace' command... eg 'nos -n' 13. F-Key SESSION SWITCHING Funtion keys F1-F8, if not defined as macros by the 'fkey' commands, will switch FROM ANY SESSION to the session of that numbers. eg. F3 will switch to session 3, no matter wether you are currently in the command, trace or any other session. If any of these F-keys is defined with the 'fkey' command, that session switch is disabled. (I use F5-F8 here for some quick keys, which leaves the first 4 session one keystroke away !) 14. NTS traffic deletion. In order to ease NTS traffic handling, ANY user can now delete ANY message in areas who's name starts with "nts" (case is not significant). This allows users to delete traffic after delivery, without having to give them permission to delete all other mail as well (we wouldn't want that now, would we ;-) So area names like "nts", "ntslocal", or whatever you want to rewrite nts traffic to fall in this category. Any "nts*" mailfile (i mean wildcard here) that is NOT an area (ie not in /spool/areas) is still 'untouchable' (unless offcourse the user has permission to do so) 15. FORWARDING. BBS forwarding now can be 'scripted'. The format of forward.bbs file is expanded: w0rli <- still the bbs to forward to ax25 ax0 w0rli <- still how to forward to [ multiples of: .send this text +continue if this string is received @wait_this_long for a reply ] w0rli <- the areas to forward... pnw north ----------- <- end of this entry Valid connect-script lines are: '.' lines are like before. The text following will be sent over the connection. This line doesn't need to contain text. In that case, a only gets send. NOTE: This will also reset the '+' reply search string to null! '+' lines set a reply string to search for when a line is being received with the @ command. '@' lines set a timeout in seconds in wich to receive a line over the connection. This is the maximum time the system will wait for a reply. At this point, an attempt is made to receive a line from the connection in the time specified. If nothing is received after the timeout time, forwarding for this entry is cancelled. If something is received, and a search string was set with the + command, forwarding will be continued only if the search string appears somewhere in the line received. If the search string was not set, forwarding is continued. NOTE: if the value after @ can not be converted to a number, the default is 90 seconds. NOTE: the search string is reset if forwarding continues after the @ command. You can have as many of these lines to establish a connection. They need not be in any particular order. CAVEAT: Replies from the connection need to be full lines; ie they have to be terminated by a proper end-of-line sequence. This means you can not wait for the login prompt from a NOS system, since those are NOT terminated with a end-of-line sequence. (see the examples) You need to know the EXACT reply from systems you connect through. Each @ command reads only one line of data from the connection (if any, offcourse). This means that if a system replies multiple lines after a connection is made, you need multiple @ commands. (see the examples below). This makes it hard to connect via systems that can have varying replies, like NOS systems that do not have your system marked as a BBS, and thus will send welcome messages and varying message-of-the-day etc... Some examples: 1- a connection via a netrom neigbour: w0rli ax25 ax0 k7uyx-1 <- initial connection to netrom node .c rlimb <- ask for a netrom connect from this node +Connected <- if we don't get this, things went wrong @60 <- maximum one minute wait ! w0rli <- forward these areas... pnw allor --------- 2- a connection via a JNOS system . This assumes that you are marked as a BBS at the JNOS system, so that you only get a '[JNOS...] and '>' prompt... n7dxt ax25 iposu <- initial connection to the JNOS system +[JNOS <- wait for sign-on message from the JNOS box @15 <- don't wait longer then 15 seconds +> <- wait for the prompt @15 <- wait 15 seconds at the most .c ax0 n7dxt <- next, request a gateway connect +Trying <- NOS replies it's trying... @15 <- wait 15 secs max. +Connected <- wait for 'IPOSU:WG7J-3} Connected to N7DXT' @60 <- wait 60 secs max n7dxt <- send these following areas pnw allor ---------- 3- A connection to a JNOS system, and from there a telnet to a remote bbs (again, assumes your system is marked as a bbs !) wg7j ax25 con iposu <- initial connection to JNOS +[JNOS <- sign-on from JNOS @15 <- shouldn't take too long +> <- next is the prompt @15 <- not too long either .t wg7j.ampr.org. <- ask for a telnet connect +Trying <- JNOS is trying @15 <- should come pretty soon +connected <- wait for '*** connected to xxx' @45 <- might take a while @30 <- wait for another (blank) line +NOS <- now come the telnet sign-on message @30 <- wait for this @30 <- after this is a blank line, wait for it .w0rli <- now we get 'login:' and "Password:" prompts, .whomever <- but they have no 's, so just answer sysop <- we're there, forward these areas. allor wg7j pnw nos ------ SETTING UP THE CONFERENCE BRIDGE -------------------------------- The conference facilities in JNOS40 can be accessed in three different ways. Each way can independently be turned on or off. Before you enable any of these, you should set the convers hostname to an appropriate name with the 'convers host' command. If not, it will default to the hostname. CONFERENCE CALL ACCESS First, a user can do an ax25 connect to the conference call. You can set this call with the 'convers mycall' command. You can set a separate inactivity timeout for these connections with the 'convers t4' command. Eg. our local node is CRV:K7UYX-1 in Corvallis, OR. You could set the conference call to 'convers mycall QSO' and users can connect to it to get directly to the conference bridge. If you want a long timeout, use eg. 'convers t4 3600' for a one hour timeout. (default is 2 hours) Next, you need to tell the system wich interfaces you want the conference call to be active on. You might not want conference call connections on backbones, or to avoid confusion with other systems using the same alias for the conference call, etc. Note: you can only do this AFTER you have attached the interfaces ! convers interface 1 convers interface 2 convers interface 3 NODE ACCESS Second, a user can connect to the regular node call, by connection to the netrom alias (if used), the interface call or the netrom call (if used). Then the user can give the 'C' command to join the conference bridge. The permission to do so defaults to on, but can be turned of with 'mbox convers off'. CONVERS SERVER ACCESS Last, there is the network server. This service listens to telnet port 3600 and allows both users and remote conference servers to link to you. It defaults to on, but can be stopped with 'stop convers'. LINKING TO REMOTE SERVERS. If you want to link to other conference servers, configure them with as many lines as you need. You can add new links at any time. Eg: 'convers link 44.26.0.4' NOTE: is is very important to avoid link loops. They cause messages to fly around in circles, thus overloading the network. Eg. if you link to w0xyz, who in turn links to w0abc, there is no need for either one of those to link back to you ! So to wrap it all up, something like this should work: convers host Corvallis convers mycall qso convers t4 3600 convers interface 1 convers link 44.26.0.4 convers link 44.26.0.3 mbox convers off #if you don't want nodeshell access A litte on CONFERENCE INTERNALS. The conference server in JNOS40 is modified from the convers code in NOS.EXE, but is identical to the stuff in the JNOS releases. Messages sent by a user get sent to all users on the local system as well as all users on remote systems. All local users get their own copy of a message. For users at remote systems, only one copy of the message is send across all the remote links available. Say there are 3 local users, and 2 remote links with 5 and 4 users respectively. If a local user sends a message, there will be 4 copies sent: 2 to the 2 remaining local users, and 1 message each across the 2 links. The message sent across the links will then be distributed to the users at each of the linked servers. OF PACLEN'S, MTU'S, MSS'S AND MORE ---------------------------------- Setting Bufsize, Paclen, Maxframe, MTU, MSS and Window Many Nos users are confused by these parameters and do not know how to set them properly. This chapter will first review these parameters and then dis- cuss how to choose values for them. Special emphasis is given to avoiding interoperability problems that may appear when communicating with non-Nos implementations of AX.25. 1. AX25 Parameters 1.1. Paclen Paclen limits the size of the data field in an AX.25 I-frame. This value does not include the AX.25 protocol header (source, destination, digipeater addresses, control and pid bytes). The AX.25 V2 protocol specifies a maximum of 256 bytes for the paclen. Be aware that some AX.25 implementations can not handle paclen greater then this, however NOS derived systems can handle this situation. This may cause interoperability problems. Even Nos may have trouble with cer- tain KISS TNCs because of fixed-size buffers. The original KISS TNC code for the TNC-2 by K3MC can handle frames limited in size only by the RAM in the TNC, but some other KISS TNCs cannot. Since unconnected-mode (datagram) AX.25 uses UI frames, the paclen value has no effect in unconnected mode. IE. if you run IP in Datagram mode, you can still have an MTU > Paclen ! (As long as your receive buffers can handle the mtu size; see INTERFACE BUFFERS...) In JNOS40, and JNOS v1.05 (and greater), paclen can be set on a per interface basis with the 'ifconfig paclen ###' command. Thus you can have a paclen of 256 on one interface and a smaller or larger on other interfaces. When you first attach an interface, the paclen defaults to the value of the 'ax25 paclen' setting (this defaults to 256.) If you want to carry netrom data over ax.25 links, the system needs to make sure the paclen is large enough to handle the netrom MTU sized data. Net/rom mtu is a maximum of 236; with a 20 byte header for the routing, this gives a data size of 256 to be send with ax.25 packets. In most versions of NOS.EXE, you can get problems when you use netrom and set the paclen < 256. When the ax.25 layer gets to send netrom frames, it cannot handle the whole data in one packet. It will then split it up in several smaller frames, using the AX.25 Version 2.1 fragmentation scheme. However, TheNet, Net/Rom, G8BPQ, MSYS and other nodes CAN NOT handle this type of fragmentation, resulting in impossible connections ! However, if you are running JNOS40, or JNOS v1.05 (or greater) for the PC, you need not worry about this. These 2 version of NOS have been modified to never provide more then paclen sized netrom data to the ax.25 layer ! Thus the above problem will never happen... 1.2. Maxframe This parameter controls the number of I-frames that may be send on an AX.25 connection before it must stop and wait for an acknowledgement. Since the AX.25/LAPB sequence number field is 3 bits wide, this number cannot be larger than 7. It can be shown that the optimal value is 1. Since unconnected-mode (datagram) AX.25 uses UI frames that do not have sequence numbers, this parameter does not apply to unconnected mode. 2. IP and TCP Parameters 2.1. MTU The MTU (Maximum Transmission Unit) is an interface parameter that limits the size of the largest IP datagram that it may handle. The MTU is the sum of the size of the data inside the IP header (TCP of UDP most likely), and the size of the IP header itself. IP datagrams routed to an interface that are larger than its MTU are each split into two or more IP fragments. Each fragment has its own IP header and is handled by the network as if it were a distinct IP datagram, but when it arrives at the destination it is held by the IP layer until all of the other fragments belonging to the original datagram have arrived. Then they are reassembled back into the com- plete, original IP datagram. The minimum acceptable interface MTU is 28 bytes: 20 bytes for the IP (fragment) header, plus 8 bytes of data. There is no default MTU in Nos; it must be explicitly specified for each interface as part of the 'attach' command. This is not the case for the netrom interface. Since ip data is carried inside a 'regular' netrom frame, the ip data should never be larger then the maximum data size the netrom protocol can handle. The default mtu here is 236, wich is the protocol maximum. If you plan on running IP in Datagram mode (the default), you can have an MTU that is larger then the paclen for that interface. However, you should still be aware of the constraints of the receiver buffer size! (See INTERFACE BUFFERS) If you plan on using IP in Virtual Connect, or VC, mode, you should be aware of the following. If you set the IP MTU larger then paclen for the interface, you will hand a packet to the ax.25 layer that is larger then what it can send in one packet. Thus you will get AX.25 V2.1 fragmentation. If you are exchanging ip data with NOS based stations only, you have no problems (other then the fragmentation). If you are interfacing with stations other then NOS bases systems, you again will have troubles, like with netrom. They will most likely not be able to handle the packets correctly. Thus be aware that in this case you should set the mtu to equal the paclen, to avoid these problems. 2.2. MSS MSS (Maximum Segment Size) is a TCP-level parameter that limits the amount of data that the remote TCP will send in a single TCP packet. MSS values are exchanged in the SYN (connection request) packets that open a TCP connection. In the Nos implementation of TCP, the MSS actually used by TCP is further reduced in order to avoid fragmentation at the local IP interface. That is, the local TCP asks IP for the MTU of the interface that will be used to reach the destination. It then subtracts 40 from the MTU value to allow for the overhead of the TCP (20 bytes) and IP (20 bytes) headers. If the result is less than the MSS received from the remote TCP, it is used instead. 2.3. Window This is a TCP-level parameter that controls how much data the local TCP will allow the remote TCP to send before it must stop and wait for an acknowledge- ment. The actual window value used by TCP when deciding how much more data to send is referred to as the effective window. This is the smaller of two values: the window advertised by the remote TCP minus the unacknowledged data in flight, and the congestion window, an automatically computed time-varying estimate of how much data the network can handle. 2.4. Discussion 2.4.1. IP Fragmentation vs AX.25 Segmentation IP-level fragmentation often makes it possible to interconnect two dissimilar networks, but it is best avoided whenever possible. One reason is that when a single IP fragment is lost, all other fragments belonging to the same datagram are effectively also lost and the entire datagram must be retransmitted by the source. Even without loss, fragments require the allo- cation of temporary buffer memory at the destination, and it is never easy to decide how long to wait for missing fragments before giving up and discarding those that have already arrived. A reassembly timer controls this process. In Nos it is (re)initialized with the 'ip rtimer' parameter (default 30 seconds) whenever progress is made in reassembling a datagram (i.e., a new fragment is received). It is not necessary that all of the fragments belong- ing to a datagram arrive within a single timeout interval, only that the interval between fragments be less than the timeout. Most subnetworks that carry IP have MTUs of 576 bytes or more, so intercon- necting them with subnetworks having smaller values can result in consider- able fragmentation. For this reason, IP implementors working with links or subnets having unusually small packet size limits are encouraged to use tran- sparent fragmentation, that is, to devise schemes to break up large IP datagrams into a sequence of link or subnet frames that are immediately reassembled on the other end of the link or subnet into the original, whole IP datagram without the use of IP-level fragmentation. Such a scheme is provided in AX.25 Version 2.1. It can break a large IP or NET/ROM datagram into a series of paclen-sized AX.25 segments (not to be confused with TCP segments), one per AX.25 I-frame, for transmission and reassemble them into a single datagram at the other end of the link before handing it up to the IP or NET/ROM module. Unfortunately, the segmentation procedure is a new feature in AX.25 and is not yet widely implemented; in fact, Nos and derived software, is so far the only known implementation. For regular NOS systems this can create some interoperability problems between Nos and non-Nos nodes. However, JNOS40 and JNOS 1.05 (or later) have provisions built in to avoid these problems. This problem is discussed further in the section on setting the MTU. 2.4.2. Setting MTU TCP/IP header overhead considerations similar to those of the AX.25 layer when setting paclen apply when choosing an MTU. However, certain subnetwork types supported by Nos have well-established MTUs, and these should always be used unless you know what you're doing: 1500 bytes for Ethernet, and 508 bytes for ARCNET. The MTU for PPP is automatically negotiated, and defaults to 1500. Other subnet types, including SLIP and AX.25, are not as well standardized. SLIP has no official MTU, but the most common implementation (for BSD UNIX) uses an MTU of 1006 bytes. Although Nos has no hard wired limit on the size of a received SLIP frame, this is not true for other systems. Interoperabil- ity problems may therefore result if larger MTUs are used in Nos. Choosing an MTU for an AX.25 interface is more complex. When the interface operates in datagram (UI-frame) mode, the paclen parameter does not apply. The MTU effectively becomes the paclen of the link. However, when using AX.25 CONNECTIONS to send IP packets, data will be automatically segmented into I-frames no larger than paclen bytes. Unfortunately, as also mentioned earlier, Nos is so far the only known implementation of the new AX.25 segmentation procedure. Thus, if you are exchanging IP over connections (ie. VC mode) with none-NOS based systems, it might be needed to avoid AX.25 segmentation. Thus you should make sure that packets larger than paclen are never handed to AX.25. In order to assure this, you should not set the MTU greater then the paclen. On the other hand, if you do not send IP over connections, but in datagram mode, you can use a larger MTU. Here, you are limited by the receive buffer size (and the tolerance of other network users for your large packets and proportionally greater bandwidth share !). For connections carrying IP between NOS systems (ie NOS-NOS VC mode), you can let AX.25 segmentation do it's thing. If you choose an MTU on the order of 1000-1500 bytes, you can largely avoid IP-level fragmentation and reduce TCP/IP-level header overhead on file transfers to a very low level. And you are still free to pick whatever paclen value is appropriate for the link. 2.4.5. Setting MSS The setting of this TCP-level parameter is somewhat less critical than the IP and AX.25 level parameters already discussed, mainly because it is automati- cally lowered according to the MTU of the local interface when a connection is created. Although this is, strictly speaking, a protocol layering viola- tion (TCP is not supposed to have any knowledge of the workings of lower layers) this technique does work well in practice. However, it can be fooled; for example, if a routing change occurs after the connection has been opened and the new local interface has a smaller MTU than the previous one, IP fragmentation may occur in the local system. The only drawback to setting a large MSS is that it might cause avoidable fragmentation at some other point within the network path if it includes a "bottleneck" subnet with an MTU smaller than that of the local interface. (Unfortunately, there is presently no way to know when this is the case. There is ongoing work within the Internet Engineering Task Force on a "MTU Discovery" procedure to determine the largest datagram that may be sent over a given path without fragmentation, but it is not yet complete.) Also, since the MSS you specify is sent to the remote system, and not all other TCPs do the MSS-lowering procedure yet, this might cause the remote system to gen- erate IP fragments unnecessarily. On the other hand, a too-small MSS can result in a considerable performance loss, especially when operating over fast LANs and networks that can handle larger packets. So the best value for MSS is probably 40 less than the larg- est MTU on your system, with the 40-byte margin allowing for the TCP and IP headers. For example, if you have a SLIP interface with a 1006 byte MTU and an Ethernet interface with a 1500 byte MTU, set MSS to 1460 bytes. This allows you to receive maximum-sized Ethernet packets, assuming the path to your system does not have any bottleneck subnets with smaller MTUs. 2.4.6. Setting Window A sliding window protocol like TCP cannot transfer more than one window's worth of data per round trip time interval. So this TCP-level parameter con- trols the ability of the remote TCP to keep a long "pipe" full. That is, when operating over a path with many hops, offering a large TCP window will help keep all those hops busy when you're receiving data. On the other hand, offering too large a window can congest the network if it cannot buffer all that data. Fortunately, new algorithms for dynamic controlling the effective TCP flow control window have been developed over the past few years and are now widely deployed. Nos includes them, and you can watch them in action with the 'tcp status ' or 'socket <#>' commands. Look at the cwind (congestion window) value. In most cases it is safe to set the TCP window to a small integer multiple of the MSS, (eg. 4times), or larger if necessary to fully utilize a high bandwidth*delay product path. One thing to keep in mind, however, is that advertising a certain TCP window value declares that the system has that much buffer space available for incoming data. Nos does not actually preallocate this space; it keeps it in a common pool and may well "overbook" it, exploit- ing the fact that many TCP connections are idle for long periods and gambling that most applications will read incoming data from an active connection as soon as it arrives, thereby quickly freeing the buffer memory. However, it is possible to run Nos out of memory if excessive TCP window sizes are adver- tised and either the applications go to sleep indefinitely (eg. suspended Telnet sessions) or a lot of out-of-sequence data arrives. It is wise to keep an eye on the amount of available memory and to decrease the TCP window size (or limit the number of simultaneous connections) if it gets too low. Depending on the channel access method and link level protocol, the use of a window setting that exceeds the MSS may cause an increase in channel colli- sions. In particular, collisions between data packets and returning ack- nowledgements during a bulk file transfer may become common. Although this is, strictly speaking, not TCP's fault, it is possible to work around the problem at the TCP level by decreasing the window so that the protocol operates in stop-and-wait mode. This is done by making the window value equal to the MSS. INTERFACE BUFFERS. ------------------ There are two different types of interface buffers associated with attaching interfaces. The first type is the ring buffer or fifo that is used when attaching a serial port. This buffer is allocated just once, and is used throughout the life of the interface. The asynchrounous (or serial port) receiver interrupt code puts characters in this buffer in a circular fashion. Ie. when the end of the buffer is reached, the next character will be stored at the beginning. The receiver process for that interface will read the characters from this fifo-buffer into memory buffers or mbufs, that are used internally to handle and pass around data. Setting the size of this buffer is a bit quess work. A good place to start is to set it to twice the size of the packet length used over the serial port. Once you have the interface running, you can monitor the usage of the fifo buffer with the 'asy' command. This will show you the 'buf hi' (for JNOS40 code) or 'sw hi' for PC based NOS. This is the high of the maximum number of characters that were waiting in the fifo buffer to be read by the receiver process. If this number is close to the fifo buffer size, or if the 'asy' command shows buffer overflows ('buf over' for JNOS40 code and 'sw over' for NOS.EXE), you should increase the buffer size. If however the number is significantly smaller, you could decrease the buffer size. The second type of interface buffers are also receiver buffers. However, these are buffers that are allocated time and time around, and (almost always) are allocated during interrupts service routines, ie. with the interrupts off! In order to keep the service routine short, the buffer is allocated from a special 'interrupt buffer queue'. This is because a regular memory allocation would take far too long. In NOS.EXE , things like the SCC, PI and PACKET drivers use these buffers. In JNOS40, the two internal modem drivers use them. Since one interrupt buffer pool services all the drivers that need buffers during interrupt, the size and number of these buffers are quite critical to a system's 'well-being'. A buffer aquired from the interrupt buffer pool needs to be able to store received data from all interfaces that use it. In other words, it needs to be large enough to handle the largest packet from those interfaces. A good rule to estimate the size of the interrupt buffers needed is as follows. You should set 'memory ibufsize' to (the largest + extra) of: 1 - the largest ax.25 paclen parameter of the interfaces using ibufs. 2 - the largest ip mtu parameter of the interfaces using ibufs. The mtu is important because on ax.25 interfaces where the mtu is larger then the paclen, there is a possibility of receiving larger ip frames, if IP traffic is carried in Datagram mode. This possibility does not exist if IP traffic is carried in Virtual Connect mode, since the data will be split in several paclen sized ax.25 packets (this is the AX.25 V2.1 fragmentation at work for you !) In the last case, you can ignore these mtu values in finding the ibuf size. (However, for NOS.EXE you still need to use the mtu for ethernet interfaces !) The 'extra' in the above is another interesting number ! It accounts for the additional protocol info, and internal headers, needed in the buffer. The maximum of this will be 72 bytes for a maximum ax.25 header (10 calls * 7 bytes, plus pid and control bytes), and space for the internal phdr structure, currently 8 bytes. Ie. the 'extra' value can be as large as 80 bytes ! Eg. if you have an ax.25 interface with paclen of 256, mtu of 256, another with paclen of 256 and mtu of 512, you should set the 'memory ibufsize' to at least 512 + 80 ! JNOS40 ibufs default to 600 bytes, and thus they should suffice for paclen's or mtu's up to 512. NOS.EXE has a default ibufsize of 2k (ie 2048 bytes), wich suffices for the standard Ethernet MTU of 1500 bytes. Determining the number of buffers needed is another empirical process. Start with, say, ten buffers (ie 'memory nibufs 10'), and see if you get a lot of memory ibuffails in the 'mem stat' display. If this is the case you should increase the number of buffers. NOTE: if you are not using any drivers that require interrupt buffers, there is no need to keep them around. In that case, simple set the 'mem nibuf' to zero. PER INTERFACE PARAMETERS ------------------------ As of V1.05, there are quite a few new parameters that are on a per-interface basis. This means they can be set for interface xyz without effecting the settings for interface abc. As of 1.06, these commands now TOGGLE the flags !!! Ie. you can turn the options ON by issuing the command, off again by issuing the command again ! These settings are shown in the 'ifconfig' display, in the 'flags' value shown here. In the code, they are defined as: #define DATAGRAM_MODE 0 /* Send datagrams in raw link frames */ #define CONNECT_MODE 1 /* Send datagrams in connected mode */ #define IS_NR_IFACE 2 /* Activated for NET/ROM - WG7J */ #define NR_VERBOSE 4 /* NET/ROM broadcast is verbose - WG7J */ #define IS_CONV_IFACE 8 /* Activated for conference call access - WG7J */ #define AX25_BEACON 16 /* Broadcast AX.25 beacons */ #define MAIL_BEACON 32 /* Send MAIL beacons */ #define HIDE_PORT 64 /* Don't show port in mbox P command */ #define AX25_DIGI 128 /* Allow digipeating */ NEW in 1.06: #define ARP_EAVESDROP 256 /* Listen to ARP replies */ #define ARP_KEEPALIVE 512 /* Keep arp entries alive after timeout */ #define LOG_AXHEARD 1024 /* Do ax.25 heard logging on this interface */ #define LOG_IPHEARD 2048 /* Do IP heard logging on this interface */ In order to find the options, add the correct set of options to get the number shown in the 'flags' field... These options can be set with the following commands: mode datagram|vc netrom interface [n] convers interface ax25 bcport mbox mport mbox hideport ax25 digipeat As of 1.06, there are a few new one: arp eaves - toggle arp eaves dropping; this will build the arp table will all arps heard on the interface given. arp poll - toggle arp keep-alive polling when an arp entry expires. AX25 heard is now settable per interface !!! ax hport You can set the maximum size of the ax heard table with ax hsize n It defaults to 0, wich means no limit. ip hport - do ip-heard logging on the interface named. this shows with 'ip heard', or the mailbox IH command. The size of the ip-heard list can be set with ip hsize n . 0 means no limit. Default is 16 CONFIGURING NOS.EXE AS A FULLSERVICE BBS. ----------------------------------------- Given in the appendices are all the configuration files as I use them for the Corvallis area bbs wg7j.or.usa.na. I simply provide them as an example of a possible configuration. I leave it up to the individual user 'to find there own little comfort zone' These files are undergoing continuous evolution as new bbs's, new bulletin types etc. show up... In our area we do not use rspf, nntp, pop or any of the 'exotic' stuff like that, so all that is not configured. /AUTOEXEC.NOS ------------ My autoexec.nos is pretty straight forward, and I leave it up to you figure most of it out. I'll elaborate on a few things. I use a SCC card, and the SCC driver. We have a 256 byte mtu/paclen, so buffers of 400 bytes is enough (see elsewhere for more) me ibufsize 400 me nibufs 20 I run with Watchdog on, just in case the system locks up. Sometime i like to watch memory status for debugging purposes... watchdog yes mem debug on Next, i setup some some global things: call, tcp hostname and ip address ax25 mycall wg7j hostname wg7j ip address 44.26.1.20 The ax.25 setup is pretty straigt forward. ax25 version 2 ax25 maxframe 1 ax25 retry 5 ax25 window 1024 ax25 irtt 4500 ax25 timer linear ax25 t3 0 Give the a 10 minute timeout ax25 t4 600 AX.25 beaconing; read FCC part 97, and do as you think is according to the rules... ax25 bci 600 ax25 bct "CRVBBS in Corvallis, run by Johan, WG7J. (TCP/IP -> 44.26.0.80)" I have 2 interfaces, one scc card with one radio port (2m) and a remote pc that talks over a serial port (sysop). #com3 = kiss to home.wg7j attach asy 0x3f8 4 ax25 sysop 1536 1024 9600 ifconfig sysop linkaddress bbs ifconfig sysop descr "to remote sysop PC" #attach an SCC card at IRQ 4 #init it first attach scc 2 init 150 4 2 0 1 168 7 p4915200 attach scc 0 ax25 2m 256 d1200 350 I configure the 2m interface for a few small things, like our tcpip subnet ifc 2m netm 0xffffff00 ifc 2m broad 44.26.1.0 ifc 2m descr "SCC port 1 on 144.92 MHz" Now i have to activate beacons and mail beacons, and digipeat ax25 bcport 2m mbox mport 2m ax25 digipeat 2m If you had a tnc in kiss mode, you could set the txtail, etc... parameters #KISS setup to TNC #tx-delay (300 ms) #param 2m 1 30 #persistence #param 2m 2 63 #slot-time (10ms) #param 2m 3 16 #tx-tail (50 ms) #param 2m 4 5 #half duplex channel ! #param 2m 5 0 I forward to some bbs's via an AXIP Internet Wormhole. I have some exotic digipeater routes to them: #some routes for wormhole fowarding ax25 route add k9iu-13 2m wg7j-13 ax25 route add ke7kd 2m wg7j-14 n8khn-2 Time to attach the NET/ROM stuff #NET/ROM SETUP #attach pseudo netrom interface attach netrom netrom alias crvbbs Activate the interfaces for netrom, both are in 'verbose' mode netrom interface 2m 192 netrom interface sysop 224 Setup some timing and retry maximums netrom retries 5 netrom timer linear Load the routes files saved at last exit netrom load Don't show users '#' nodes ! netrom hidden no Time for a few IP and TCP related things, see the discussion elsewhere for more information ip ttl 25 tcp mss 432 tcp window 864 tcp timer linear Now the IP routes. The local subnet is on the 2m port. route add 44.26.1/24 2m My remote sysop PC sits on the serial connection route add 44.26.1.19 sysop Default everything to the Internet gateway #add the ip routes route add default 2m 44.26.1.16 IP over netrom is fun to play with. Currently all Portland area goes to Hank's system in Portland. add a route to a gateway for all 44.116 traffic #add w0lri as gateway over netrom route add 44.116/16 netrom 44.116.0.70 Next adds the appropriate arp entry for that gateway. arp add 44.116.0.70 netrom w0rli-3 A few things about domain domain suffix ampr.org. domain translate off SMTP needs to be quite, and I use the internet gateway as my default route, if my rewrite/alias files don't catch the message smtp quiet yes smtp mode route smtp batch on smtp gateway 44.26.1.16 Start the log log \spool\net.log Now start all servers ##ready to start all servers now start smtp ##turn on the bbs for ax25, netrom and telnet connects start ax25 start netrom start telnet start ftp start smtp remote -s your-password-here start remote start finger attend off Setup the mailbox stuff #we're not home ! mbox attend off #forward every hour mb timer 3600 #start forwarding at 10 minutes past the hour at 10 "start forward" #'mail for' beacon every half hour mb mailfor 1800 #don't beacon for these private mailboxes. mb mailfor exclude indy nevada w0rli n7dxt wa7shp sysop check north south nts #notify users when new area mail is in mb new on #also ask for the 'okay to send' mb sendquery on #max 150 messages per group mb max 150 #the message-of-the-day mb motd "'?' or 'h command` for help; 'd commands.txt' for command cheat sheet...\nSend local messages to 'users' .Questions to sysop or wg7j...\nEnjoy." #no jumpstart for these guys mb jumpstart exclude k7uyx-1 wg7j-3 wg7j-1 mb jumpstart on mb haddress or.usa.na mb qth "Corvallis, OR" mb zip 97330 #don't forward smtp headers over the bbs circuit mb smtp no #optimize forwarding by checking the R: lines bulletin check yes #use the bulletins origination date bulletin date yes #grab return address from R: lines bulletin return yes #hold forward loop messages after 2 loops bulletin loophold 2 #set some timeout values ftptdisc 600 mbox tdisc 600 netrom tdisc 600 #start some cycles at a certain time # expire messages each night at 1pm (i'm using utc time) at 0900 "expire 24" #delete old bid's every night at 2pm, limit is 21 days at 1000 "oldbid 24 21" Finally tell the network we;re there, and poll other jnos1.05 or jnos40 nodes for their netrom routes ##finally tell the netrom network we're there !! netrom bcnodes 2m netrom bcpoll 2m /FTPUSERS -------- Appendix B, ftpusers, contains entries for the bbs's that forward to me, as well as those users that have sysop priviledges. All other regular users are taken care off with the univperm entry; thus no long list of users is needed. Offcourse you can setup entries for specific users that have special needs... (one note: it is imperative that you have one space, and nothing else, between fields on a line!!!) The numbers in the file are those found in the MAILBOX USER PERMISSION section. /ALIAS ----- Appendix C, alias, is a simple list of alias names the system recognized. I like to be known as 'johan' as well as 'wg7j' but always read mail as wg7j (line 1). Ron, wa7tas, receives his mail via smtp on his 24hrs setup (line 2). Same for k7mkg. /SPOOL/AREAS ------------ Appendix D, /spool/areas, simply list all the public mail areas I let my users access. You should recognize such things as 'allusa', 'amsat' etc... /SPOOL/REWRITE -------------- Appendix E, /spool/rewrite, is where the fun starts ! Before i get into my 'philosophy'; if you don't feel comfortable with the rewrite mechanism, please refer to or read the 'mailbox.txt' destributed with this document. That document, written by NQ0I and SM0RGV, explains the bbs well. Credit goes to those gentlemen. Again, the following is by no means the best or only way to configure your system's rewrite mechanism. It is simply the way I run it, and is shown as an example only. My systems tends to not take a lot of bulletins, to keep the load down (most are old anyway), but you might decide to do things different. Now to the way I 'run mail'. First thing I want to do is catch all Internet style (ie. SMTP targeted) mail, and make sure that those messages go as is. Lines 1-4 take care of this by catching most of the top-level Internet domain names. *@*.edu $1@$2.edu *@*.com $1@$2.com *@*.gov $1@$2.gov *@*.org $1@$2.org Next is an example of catching some things you don't want; here in Oregon some-one pumps in daily astronomical stuff. By the time it gets to my system it's way old :-( By rewriting it to 'refuse', the bbs will send a 'NO' as if it already has receive it. Same for some other things the wormhole bbs's are trying to forward to me. astro@* refuse *@dist9 refuse *@allin refuse *@okipn refuse *@allil* refuse msys@* refuse fbb@* refuse mods@* refuse *@ww refuse I want users to be able to send mail to sysop on my system without it being forwarded elsewhere. I take care of this by rewriting it to the 'wg7j' area (ie. my private mail area) sysop wg7j sysop@wg7j* wg7j Next I send everything else that comes in for sysops to the 'sysop' area. That way I can participate in receiving and forwarding stuff like 'sb sysop@allor' etc... sysop@* sysop Next I place anything addresses to specific mail areas as setup with the '/spool/areas' files into those mailboxes tcpip@* tcpip wanted@* wanted want@* wanted need@* wanted sale@* sale 4sale@* sale trade@* sale dx@* dx humor@* humor jokes@* humor happy@* humor races@* races fcc@* fcc amsat@* amsat arrl@* arrl ares@* ares swap@* sale nasa@* nasa Then the same thing for the @-distribution names: *@nasa nasa *@amsat amsat *@ares* ares *@arrl arrl *@arl arrl *@pnw pnw *@allor* allor *@allusw allusw *@allus* allusa NOTE: if you follow this style, it is important that the lines above are kept in that order (Ie TO sorting FIRST, then AT sorting !!) Otherwize something like 'amsat@allusa' will end up in the 'allusa' area instead of the 'amsat' area where I prefer it. Next I will catch anything destined for my bbs that hasn't been already caught by a previous rule. At this point, this only be private mail. *@wg7j* $1 Then I will catch any mail destined for the bbs's i forward to and place it in their mailbox to be forwarded. *@wa7tas* wa7tas *@wa7shp* wa7shp *@w0rli* w0rli *@n7dxt* n7dxt I place anything destined for a few in-state (ie OR) bbs's that are north of me into the 'north' mailbox. They get forwarded north-ward (see forward.bbs) *@n7hae* north *@n7vyn* north *@n7koj* north *@n7pwf* north *@wa6gfp* north *@n7jqk* north *@ka7agh* north *@kb7dbd* north Then I take all local NTS traffic and places it in it's own area. *@97321* ntslocal *@9733* ntslocal *@97370* ntslocal *@97389* ntslocal Other in-state NTS goes into the right direction. *@98* north *@970* north *@971* north *@972* north *@9730* wa7shp All out-of-state NTS traffic gets placed into the 'nts' area for forwarding *@ntswa* north *@nts* nts They idea is, that by rewriting every in-state bbs north of me into the north area, everything in-state left has to go south ! (Luckily, N7DXT, who gets my south traffic, is forgiving and will send my mistakes north anyway !) *@*.or* south A few other states that go south: *@*.ca* south *@*.az* south *@*.tx* south These states go to K9IU in Indiana via the wormhole: *@*.in* indy *@*.oh* indy *@*.mi* indy *@*.ky* indy *@*.tn* indy And lonesome KE7KD in Reno get the Nevada traffic: *@*.nv* nevada Send all remaining North American mail north (to w0rli, who has an HF port...) *@*.eu north Catch 2 more continents: *@*.oc south *@*.as north And finally, I will catch anything that is left at this point. It puts it in the 'check' area. The idea here is that I can manually check the 'check' area and adjust '/spool/rewrite' accordingly ! (and append that mail to the right mailbox file so it goes out!) 'check' is actually an alias, that sends copy of the message to both the 'check' area and my private mailbox, so that i will know right away when some thing unknown has shown up... *@* check /SPOOL/FORWARD.BBS ------------------ As of v1.05, forwarding can now hand 'connect scripts' in the forward.bbs file. The format of forward.bbs file is expanded: w0rli <- still the bbs to forward to ax25 ax0 w0rli <- still how to forward to [ multiples of: .send this text +continue if this string is received @wait_this_long for a reply ] w0rli <- the areas to forward... pnw north ----------- <- end of this entry Valid connect-script lines are: '.' lines are like before. The text following will be sent over the connection. This line doesn't need to contain text. In that case, a only gets send. NOTE: This will also reset the '+' reply search string to null! '+' lines set a reply string to search for when a line is being received with the @ command. '@' lines set a timeout in seconds in wich to receive a line over the connection. This is the maximum time the system will wait for a reply. At this point, an attempt is made to receive a line from the connection in the time specified. If nothing is received after the timeout time, forwarding for this entry is cancelled. If something is received, and a search string set with the + command, forwarding will be continued only if the search string appears somewhere in the line received. If the search string was not set, forwarding is continued. NOTE: if the value after @ can not be converted to a number, the default is 90 seconds. NOTE: the search string is reset if forwarding continues after the @ command. You can have as many of these lines to establish a connection. They need not be in any particular order. CAVEAT: Replies from the connection need to be full lines; ie they have to be terminated by a proper end-of-line sequence. This means you can not wait for the login prompt from a NOS system, since those are NOT terminated with a end-of-line sequence. (see the examples) You need to know the EXACT reply from systems you connect through. Each @ command reads only one line of data from the connection (if any, offcourse). This means that if a system replies multiple lines after a connection is made, you need multiple @ commands. (see the examples below). This makes it hard to connect via systems that can have varying replies, like NOS systems that do not have your system marked as a BBS, and thus will send welcome messages and varying message-of-the-day etc... Some examples: 1- a connection via a netrom neigbour: w0rli ax25 ax0 k7uyx-1 <- initial connection to netrom node .c rlimb <- ask for a netrom connect from this node +Connected <- if we don't get this, things went wrong @60 <- maximum one minute wait ! w0rli <- forward these areas... pnw allor --------- 2- a connection via a JNOS system . This assumes that you are marked as a BBS at the JNOS system, so that you only get a '[JNOS...] and '>' prompt... n7dxt ax25 iposu <- initial connection to the JNOS system +[JNOS <- wait for sign-on message from the JNOS box @15 <- don't wait longer then 15 seconds +> <- wait for the prompt @15 <- wait 15 seconds at the most .c ax0 n7dxt <- next, request a gateway connect +Trying <- NOS replies it's trying... @15 <- wait 15 secs max. +Connected <- wait for 'IPOSU:WG7J-3} Connected to N7DXT' @60 <- wait 60 secs max n7dxt <- send these following areas pnw allor ---------- 3- A connection to a JNOS system, and from there a telnet to a remote bbs (again, assumes your system is marked as a bbs !) wg7j ax25 con iposu <- initial connection to JNOS +[JNOS <- sign-on from JNOS @15 <- shouldn't take too long +> <- next is the prompt @15 <- not too long either .t wg7j.ampr.org. <- ask for a telnet connect +Trying <- JNOS is trying @15 <- should come pretty soon +connected <- wait for '*** connected to xxx' @45 <- might take a while @30 <- wait for another (blank) line +NOS <- now come the telnet sign-on message @30 <- wait for this @30 <- after this is a blank line, wait for it .w0rli <- now we get 'login:' and "Password:" prompts, .whomever <- but they have 's, so just send them sysop <- we're there, forward these areas. allor wg7j pnw nos ------ Appendix F, /spool/forward.bbs, details the forwarding my system will attempt. I don't care when forwarding occurs, so none of the first line entries have time fields (lines 1,10 and 19). Lines 2,11 and 20 show how I attempt to connect to the remote bbs. All go over netrom (my only way out :-( ), but for WA7SHP I need to downlink from a distant node (salem) to his bbs (lines 21,22 and 23) The areas I forward are mostly regional bulletins, nts traffic, and personal mail (as shown earlier, the north and south entries) I don't forward any of amsat,allusa,allusw because I don't want to clutter an already loaded system; the surrounding area bbs's get these things to each other just fine without my 'interference :-)' /ONEXIT.NOS ----------- Appendix G, /onexit.nos, simply is a set of valid NOS.EXE commands to be executed before returning to DOS. In line 1, I tell the netrom system one last time I am there (to try to keep my route alive while I am gone). Next I save the netrom routes to disk for later retrieval at startup via the netrom load command. GATEWAYING BETWEEN SMTP AND AX.25 BBS STYLE MAIL ------------------------------------------------ If your system is serving both the 'regular' packet community (ie. people with just tnc's) as well as the tcp/ip-ers with mail forwarding, here are a few hints on how one could set things up. The following assumes that the host 'ka7ehk.ampr.org' sends mail to 'w0rli@w0rli.or.usa.na', and uses 'wg7j.ampr.org' as the mail gateway that talks to the bbs-network. wg7j's bbs style H-Address is WG7J.OR.USA.NA . The rewrite file in appendix E is also used as an example of how the gateway system handles mail. NOS.EXE is fully capable of exchanging mail from SMTP world to BBS world and vice versa. Thus it can act as the gateway between the two different systems. The key to understanding how this works is to realize that the smtp-server ALSO READS REWRITE when mail comes in that way ! (as a matter of fact, even mailbox mail goes through the smtp-server !) You should also (again) check the diagram in mailbox.txt... MAIL FROM SMTP --> AX.25. -------------------------- When sending mail via smtp that eventually should end up in the bbs network, the meaning of the previous is as follows: When ka7ehk.ampr.org connects to wg7j.ampr.org and sends the address of the mail, the smtp-server will deposit this in the 'w0rli.txt' mailbox (rewrite line 24). Next time the forward timer ticks, forwarding will be attempted, and you're in business ! How does one set this up on the user side ? The easiest way to set this up for the user is to tell the user to use your system as the mail gateway ! The 'smtp gateway' commands sets a hostname that ALL UNKNOWN MAIL will be sent to. Unknown mail is mail to addresses that cannot be found in /domain.txt (or from the domain name server if configured). Since most bbs style addresses will not be in there, this means that those mails will go to the gateway ! (remember: tcpip hostnames most often end in ampr.org, whereas bbs style H-Address are something like WG7J.OR.USA.NA. The latter thus will not be found in /domain.txt!) Thus a simple 'smtp gateway yourhost' where yourhost is the gateway's name (as in domain.txt) or ip-address, suffices ! There is another way a user can send the above mail. However this a bit more involved and is not as easy for users. It involves a little more of an understanding of the ways smtp addressing works. It also requires an additional line in rewrite ! It simply given for completeness. User's can manually address mail to a gateway, with the to-address format 'user%hostname@gateway'. Eg. the above mail could be addressed as 'w0rli%w0rli.or.usa.na@wg7j.ampr.org' In order to handle these sorts of mail address,es you should add a line similar to '*%*@wg7j* $1@$2 r' to your rewrite file. Just replace wg7j with the your system's name. This line will rewrite all %-addresses into a regular address (ie. the above becomes 'w0rli@w0rli.or.usa.na'), and then rescan with the new address to find more rewrite rules. Thus the mail ends up in the 'w0rli.txt' mailbox again. Then ka7ehk.ampr.org would again deliver the mail to wg7j.ampr.org, and the process would be identical to described above. MAIL FROM AX.25 --> SMTP -------------------------- Let's use as an example a reply from w0rli to ka7ehk. Since bbs's use the last R: header as the return system, a reply mail will be sent to my system as 'S KA7EHK@WG7J.OR.USA.NA < W0RLI' , or as 'S KA7EHK < W0RLI' depending on the pbbs software. In order to deal with the first case, rewrite line 22 is needed. This rewrites the address into simply 'ka7ehk' Next, you as sysop have 3 options for delivery of the message: 1 - ka7ehk has to login to your system in order to read his mail. Simply do nothing ! 2 - you want to forward mail to ka7ehk on his home system using smtp You need to add an alias to handle this. The line 'ka7ehk ka7ehk@ka7ehk.ampr.org' will do the job. This might cause lots of attempts for smtp if ka7ehk's system isn't on the air a lots (ie. like most users!) Better then is: 3 - Let ka7ehk automatically get his mail with POP each time he turns his system on. The gateway sysop and the user both need to configure this appropriately. See nos_1229.man for more details. POP SERVICES IN NOS ------------------- The following is also contributed by Doug Cromptom, WA3DSP: How to use POP in NOS --------------------- The HOST should establish a 'POPUSERS.' file in root with the following format: username:password: username:password: etc. There should be an entry for each user of your POP system. We generally use call letters for both entries. I.E. wa3dsp:wa3dsp: The following applies to the old NOS POP2 server/client prior to WG7J 1.02 ------------- The HOST must also start the pop server 'start pop' which should go in your NOS autoexec. Each USER must add the following lines to there autoexec: 'pop mailbox CALL' Where CALL is the name of the mailbox on the host to retrieve mail from. The /spool/mail/CALL.txt file. Usually the users call. 'pop mailhost hostname' This specifies what host to pop from. I.E. 'pop mailhost wa3dsp.ampr.org' 'pop userdata user password' This data should match the data in the hosts /popuser file. I.E. 'pop userdata wa3dsp wa3dsp' 'pop timer 3600' For stations that are on for extended periods and receive there mail via pop from a mailhost this timer must be set to interrogate the host on a regular basis. Alternatively they could do a 'pop kick' to check for mail. Time should be set to probably no less than 1/2 hour on a radio circuit. 'pop kick' This should be entered at the end of your autoexec to check for mail from your mailhost at startup. So the autoexec entries would look like this for USER w3iwi... pop mailbox w3iwi pop mailhost wa3dsp.ampr.org pop userdata w3iwi w3iwi pop timer 3600 pop kick and HOST wa3dsp's autoexec... start pop HOST wa3dsp's popusers. in root.... w3iwi:w3iwi: For NOS POP2/3 server client WG7J 1.02 and later. ------------ The method of entering client pop server information has been changed!! All information is added on one line with the 'pop addserver' command. It has the following syntax: pop add Using the above old version example it would be entered like this: pop add wa3dsp.ampr.org 3600 pop2 w3iwi w3iwi w3iwi This is assuming POP2 protocol. It is advisable to use POP3 and if your server supported it the POP2 would be replaced with POP3. NOS can be compiled to include any combination of POP2/3 server client. If one protocol was not supported in your compile it would not be allowed in the command. Refer to the old version above for a definition of the fields. Since multiple servers can be defined using the 'pop add' command the 'pop kick' command now takes the form 'pop kick ' or in the above example: pop kick wa3dsp The 'pop add' and 'pop kick commands are the only ones needed in the autoexec file to initialize pop. 'pop list' will show the current defined servers. The server must start pop. Since both pop2 and pop3 servers can now be present the appropriate command are: start pop2 start pop3 -------------------- A few other points... If a pop users wants mail to be delivered to the host for them to pick up via POP they should enter a 'reply to' field in BM.RC to direct mail to the host and not back to them. POP is a very good service for Amateur Radio. It is especially good when a flood of messages are sent out to all users. This is a condition that often causes crashes on memory marginal systems using SMTP. Also alot of unnecessary traffic is sent out to stations that are not on the air. With POP the user asks for and gets mail. This is naturally a random operation. Lowering channel congestion and NOS memory usage. Mail that is POP'ed from the host is deleted from the /spool/mail directory upon successful transfer. The USER is notified that new mail has arrived at the completion of the entire transfer. One drawback that I notice with POP is that the messages (many could build up) for a user are sent as a group. If the circuit fails with a hard error halfway thru a POP xfer of a message group, no messages are saved at the user end, even though some got thru. It is an all or none with POP. This reminds me of the stupidity of BBS's in this regard. Hopefully users will not let messages build up. I have some users who let the mail build up to 30 or 40K over a few weeks. EPILOGUE. -------- I hope all this proves helpful for those interested in setting up JNOS in a mixed environment... 73 and happy packeteering, Johan /*************************************************************************/ APPENDIX A: /autoexec.nos me ibufsize 400 me nibufs 20 watchdog yes mem debug on ax25 mycall wg7j hostname wg7j ip address 44.26.1.20 #AX.25 SETUP #use (UI) frames for ip over ax.25 !!!!! ax25 version 2 ax25 maxframe 1 ax25 retry 5 ax25 window 1024 ax25 irtt 4500 ax25 timer linear ax25 t3 0 ax25 t4 600 ax25 bci 600 ax25 bct "CRVBBS in Corvallis, run by Johan, WG7J. (TCP/IP -> 44.26.0.80)" #com3 = kiss to home.wg7j attach asy 0x3f8 4 ax25 sysop 1536 1024 9600 ifconfig sysop linkaddress bbs ifconfig sysop descr "to remote sysop PC" #attach an SCC card at IRQ 4 #init it first attach scc 2 init 150 4 2 0 1 168 7 p4915200 attach scc 0 ax25 2m 256 d1200 350 ifc 2m netm 0xffffff00 ifc 2m broad 44.26.1.0 ifc 2m descr "SCC port 1 on 144.92 MHz" #active beacons and mail beacons ax25 bcport 2m mbox mport 2m ax25 digipeat 2m #KISS setup to TNC #tx-delay (300 ms) #param 2m 1 30 #persistence #param 2m 2 63 #slot-time (10ms) #param 2m 3 16 #tx-tail (50 ms) #param 2m 4 5 #half duplex channel ! #param 2m 5 0 #some routes for wormhole fowarding ax25 route add k9iu-13 2m wg7j-13 ax25 route add ke7kd 2m wg7j-14 n8khn-2 #NET/ROM SETUP #attach pseudo netrom interface attach netrom netrom alias crvbbs netrom interface 2m 192 netrom interface sysop 224 netrom retries 5 netrom timer linear netrom load netrom hidden no ip ttl 25 tcp mss 432 tcp window 864 tcp timer linear #add the ip routes route add default 2m 44.26.1.16 #remote sysop pc route add 44.26.1.19 sysop #add w0lri over netrom route add 44.116/16 netrom w0rli.ampr.org arp add 44.116.0.70 netrom w0rli-3 domain suffix ampr.org. domain translate off smtp quiet yes smtp mode route smtp batch on smtp gateway 44.26.1.16 log \spool\net.log ##ready to start all servers now start smtp ##turn on the bbs for ax25, netrom and telnet connects start ax25 start netrom start telnet start ftp start smtp remote -s wg7jjj start remote start finger attend off mbox attend off #forward every hour mb timer 3600 at 10 "start forward" #'mail for' beacon every half hour mb mailfor exclude indy nevada w0rli n7dxt wa7shp sysop check north south nts mb mailfor 1800 mb new on mb sendquery on #max 150 messages per group mb max 150 mb motd "'?' or 'h command` for help; 'd commands.txt' for command cheat sheet...\nSend local messages to 'users' .Questions to sysop or wg7j...\nEnjoy." mb jumpstart exclude kf7dq-1 wg7j-3 wg7j-1 mb jumpstart on mb haddress or.usa.na mb qth "Corvallis, OR" mb zip 97330 mb smtp no bulletin check yes bulletin date yes bulletin return yes bulletin loophold 2 #set some timeout values ftptdisc 600 mbox tdisc 600 netrom tdisc 600 #start some cycles at a certain time # expire messages each night at 1pm (i'm using utc time) at 0900 "expire 24" #delete old bid's every night at 2pm, limit is 21 days at 1000 "oldbid 24 21" ##finally tell the netrom network we're there !! netrom bcnodes 2m netrom bcnodes 2m #trace 2m 111 #arp for my home.wg7j system arp publish 44.26.1.19 ax25 wg7j 2m APPENDIX B: /ftpusers 1: wg7j password / 16511 2: johan password / 16511 3: ka7ehk password / 16511 4: n7dxt password /public 8195 5: w0rli password /public 8195 6: wa7shp password /public 8195 7: w7vtw password /public 8195 8: univperm * /public 16403 9: #sysops: 16511 10: #regular users: 16403 11: #bbs's: 8195 APPENDIX C: /alias 1: johan wg7j 2: wa7tas wa7tas@wa7tas.ampr.org 3: k7mkg k7mkg@k7mkg.ampr.org APPENDIX D: /spool/areas 1: allor - All of Oregon stuff 2: allusa - ALLUSA bulletins 3: amsat - AMSAT bulletins 4: anonymous - info for new/anonymous users 5: arrl - ARRL bulletins 6: help - help about this system 7: ntslocal - Corvallis area NTS traffic 8: osuarc - Oregon State University ARC stuff 9: pnw - Pacific North West stuff 10: sale - 'for sale' bulletins 11: tcpip - TCP/IP related stuff APPENDIX E: /spool/rewrite *@*.edu $1@$2.edu *@*.com $1@$2.com *@*.gov $1@$2.gov *@*.org $1@$2.org *%*@wg7j* $1@$2 r astro@* refuse *@dist9 refuse *@allin refuse *@okipn refuse *@allil* refuse msys@* refuse fbb@* refuse mods@* refuse *@ww refuse n8hkn@* nevada ke7kd@* nevada sysop wg7j sysop@wg7j* wg7j sysop@* sysop tcpip@* tcpip wanted@* wanted want@* wanted need@* wanted sale@* sale 4sale@* sale trade@* sale dx@* dx humor@* humor jokes@* humor happy@* humor races@* races fcc@* fcc amsat@* amsat arrl@* arrl ares@* ares swap@* sale nasa@* nasa *@nasa nasa *@amsat amsat *@ares* ares *@arrl arrl *@arl arrl *@pnw pnw *@allor* allor *@allusw allusw *@allus* allusa *@wg7j* $1 *@wa7tas* wa7tas *@wa7shp* wa7shp *@w0rli* w0rli *@n7dxt* n7dxt *@n7hae* north *@n7vyn* north *@n7koj* north *@n7pwf* north *@wa6gfp* north *@n7jqk* north *@ka7agh* north *@kb7dbd* north *@wa7ari* wa7shp *@k7myu* wa7shp *@97321* ntslocal *@9733* ntslocal *@97370* ntslocal *@97389* ntslocal *@98* north *@970* north *@971* north *@972* north *@9730* wa7shp *@ntswa* north *@nts* nts *@*.or* south *@*.ca* south *@*.az* south *@*.tx* south *@*.nv* nevada *@*.in* indy *@*.oh* indy *@*.mi* indy *@*.ky* indy *@*.tn* indy *@*.eu north *@*.oc south *@*.as north *@* check *@*.usa north *@*.noam north *@*.na north APPENDIX F: /spool/forward.bbs w0rli netrom w0rli-2 w0rli north south allor pnw tcpip arrl amsat sysop allusa -------- n7dxt netrom n7dxt n7dxt south nts allor pnw tcpip arrl amsat sysop allusa -------- wa7shp netrom af7s-1 .c 1 wa7shp wa7shp north south allor pnw arrl amsat sysop -------- k9iu 0517 ax25 2m k9iu-13 indy -------- ke7kd 0517 ax25 2m ke7kd nevada allor allusw pnw ---------- wg7j ax25 sysop wg7j-2 test ---------- APPENDIX G: /onexit.nos net bcn 2m netrom save