Beijing Paradise BBS Backup

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

/ Beijing Paradise BBS Backup / PARADISE.ISO / software / BBSDOORW / ARPD115.ZIP / ARPD.DOC next >

Wrap

Text File | 1995-01-22 | 28.1 KB | 594 lines

Amateur Radio Packet Door v. 1.15 Land-Line BBS to Packet Radio Access System Copyright 1994 by Pass - the - Buck SoftWare Independence, Mo. (W4KGU) Files included in this package: ARPD.EXE ARPD.DOC CONFIG.TNC DEFAULTS.TNC HELP.TNC INIT.TNC INTRO.TNC TNCNODE.TNC USERS.TNC HISTORY.TXT Please be sure all files are included when you install this software. Please DO NOT distribute this program if ANY files are missing. The A.R.P.D. program was developed and tested on land-line Bulletin Board Systems using the following hardware / software: 386/40 IBM clone 8250 / 16550 UART serial cards PPI 14,400 / 28,800 modems RemoteAccess BBS software (running under MS Windows) MFJ-1270B / 1274C Kenwood TM-2530A While no two systems are alike, one similar to the above should offer few problems in setting up and running A.R.P.D. Of course, you MUST have a working knowledge of packet radio operation, your TNC and your BBS software. Some setup is required and the more your system differs from the above, the more will have to be done. From the users standpoint, operation is very simple. Just hit the key to access the door, wait for the TNC to be initialized and then operate just as if they were using it from their computer. This will require that you screen the users to be sure they are familiar with the operation of your make/model TNC. If the user panics and drops carrier on the door (many will!), the system will NORMALLY recover properly. Under some circumstances the system may feel "All is not well" and will make itself unavailable to other users till reset by the SysOp. The logic involved in this is very simple but quite intelligent. When accessed, the system writes a file in the ARPD directory called TNCB.USY. At exit from the door the system attempts to reset the TNC to defaults, checks the status of the serial port, the phone line, the temperature and humidity, etc. If all goes well in this process the system will delete this semaphore file. At any point where the system suspects a problem it will exit with the file still in place. When the door is accessed with the TNCB.USY file still in the directory it will display a screen to the user which explains that the TNC is not available and to try again at a future time. The door will exit back to the BBS. The TNCB.USY semaphore file serves another purpose in the normal operation of your station. It allows you to share it with your users. A dedicated packet station is beyond the ability (or willingness) of most BBS SysOps to supply for their users. By calling your favorite packet operating software from a batch file such as the one below you can take control of the TNC at any time and the users will be informed that the TNC is not available for their use. The batch includes a safeguard so that you can't try to access the TNC if it is in use by a BBS caller. (Handy when running in Windows!) REM *** Sample batch to call local packet program REM *** Allows use of equipment without BBS user REM *** conflict @echo off if exist d:\ra\arpd\tncb.usy goto nocando REM *** If TNCB.USY exists local packet program will not be called copy d:\ra\arpd\tncnode.tnc d:\ra\arpd\tncb.usy REM *** Makes a copy of the 1 byte file as TNCB.USY so users REM *** will not compete for the serial port kgucomm.exe REM *** Call local packet program del d:\ra\arpd\tncb.usy goto end REM *** This command runs after packet program exits and clears REM *** the file so users will have access again :nocando echo Sorry, the TNC is currently in use on the BBS. REM *** Displays TNC not available message to YOU! pause :end If this batch refuses to operate locally and you know that the door is not in use at the moment, it means that the system has not reset properly and the door is also not available to your users. Delete the TNCB.USY file from the ARPD directory and log on to the TNC and check the parameters. Change any that require changing and then exit. You may also use the door while logged on to the BBS locally, just as any user can. You may prefer the look and feel of the door to your present program, especially if you are using a simple dumb terminal program. In normal operation, if the user has ANSI activated, the screen will be printed in black and white until a connect has been made. When a connect is made the screen will be printed in light green and black. The color of the screen indicating the connect status of the TNC. If the user does NOT have ANSI active on the BBS then all print will be in B&W. A user actually in the door will time out after the length of time specified in the CONFIG.TNC file OR the system time left to him on the BBS, whichever comes first. In the door, there is no keyboard time-out. The opening and closing screens have a keyboard time-out of three minutes with a warning beep at two minutes. If no keyboard entry takes place within the allotted time, the door will exit back to the BBS. A user dropping carrier will cause the system to attempt to reset the TNC and return to the BBS for normal exit. It is at this point that problems may occur. Encourage your users to NOT hang up on the system if at all possible, ESPECIALLY if the TNC is connected at the time. Exiting the door in ANY way while the TNC is in the connected state may lead to abnormal program termination. Features: A.R.P.D. is designed to make life easier for a BBS SysOp who wishes to make on air packet available to system users. Ease of operation was a prime consideration as was low maintenance. Once installed A.R.P.D. requires little attention. All operations are handled automatically by an intelligent operating system requiring little specialized knowledge on the part of the SysOp or the user. When a user accesses the door, the call sign of the TNC is changed to that of the user. This allows him to log on to packet BBS stations and receive traffic as he would from his own home station. The call sign is changed back to that of the System Operator on exit from the door. This has an added advantage of making the user responsible for his own actions on the air. In the event that a station has connected to your TNC from the RF end, a user will not be permitted to enter the door. Changing the callsign of the TNC would leave the connected station in limbo. The connect status at door entry is determined by the status of the carrier detect line from the TNC. Your TNC will, therefore, need to be set so that DCD reflects the connect status. On some models this is a software setting and a jumper setting on others. See your manual if users get rejected at log-on because of an "external" user. All operations are logged in an ASCII text file called ARPD.LOG as well as individual logs for each of the authorized users. As the door is accessed the TNC clock is checked and updated to keep it correct according to system time. This is also handy in the event of a power failure when TNC time might be lost completely. No SysOp intervention is necessary to tell the A.R.P.D. program or the BSB software that the TNC is off line or powered down. If the TNC is not powered on or is not connected to the serial port, the user is notified and the door exits to the BBS. This off-line condition is determined by the condition of the DSR (Data Set Ready) line from the TNC. DSR MUST be true at log-on. If you are using a TNC or RS-232 cable that does not allow this status to be properly reported, you may strap DSR high at the connector and fool the program. I don't recommend this but we are hams and prone to experiment. Since A.R.P.D. now supports software flow control it should be possible though I haven't tried it. Any changes made to TNC settings by you in a local session or by the user in the door should be canceled on entry/exit to the door. This assures that the system will remain well behaved in both modes whether attended or not. It also assures that the system is always in the same condition the user is familiar with when he logs in. This operation is handled automatically by the software if properly configed. On entry to the door, the file INIT.TNC is fed to the TNC as if written line for line from the keyboard. This file should contain parameters that you would normally change in a local packet session. It is particularly handy if you have a local packet program that loads the TNC with settings optimized for a different type of operation. On exit from the door, a COMPLETE set of parameters should be loaded into the TNC. This will assure that anything changed in the system by a creative user will not be held over for you or the next user. The file DEFAULTS.TNC is sent to the TNC on exit from the door just as thought typed from the keyboard line for line. If you use your TNC on HF or RTTY, several of the settings may be changed. Each of the changed settings should be re-set by INIT.TNC. If you're not sure which settings may be changed in your local operation, you may copy the DEFAULTS.TNC file to the INIT.TNC file and do a complete reconditioning of the TNC on both entry and exit. A.R.P.D. has a feature which was not documented in earlier versions, though it has been there all along. Using the <F3> function key, you may enable the local keyboard while a user is online. The user is notified that the SysOp is online in HELP mode. With this option you may take a new packet user by the hand and lead him through the operation of the TNC and even join in a conversation he is having while connected to another station. Pressing the <F3> key once again will cancel the HELP mode and inform the user that you are no longer with him. The <F4> key will put you in CHAT mode with the user. He will be informed of your presence and if he has ANSI enabled will see the print change to yellow on black. Keystrokes from him and the local keyboard are displayed on both terminal screens but are not sent to the TNC. TNC output is inhibited (buffered) during this CHAT. If you chat long enough the circular buffer structure of the A.R.P.D. program will allow the contents of the buffer to be overwritten. This is usually not a problem unless the user is connected and reading a long ASCII text file. Again, pressing the <F4> key a second time will cancel CHAT mode and return the system to normal operation. The <F3> and <F4> functions are mutually exclusive. Entering the other mode will cancel the first. You need not exit CHAT mode to go directly to HELP mode. Just press the key of the option you wish and the transition will take place seemlessly. Technical Stuff: While the A.R.P.D. was written around the RemoteAccess (r) BBS software package, the only thing actually necessary is that the BBS software write an RA style DORINFO1.DEF file. This is a fairly standard drop file and available with most BBS packages. If your BBS uses another drop file there are utilities to change the format available on most large support BBS's. A.R.P.D. runs in a very small amount of memory and it is usually not necessary for the BBS software to swap itself out of memory except on extremely small systems. This allows faster loading/unloading for the user online. In RA a TYPE 7 exit is used to call a batch file. This is done to allow the batch to change the current working directory to the ARPD directory. The menu call in RA is : *C /c d:\ra\arpd.bat ARPD.BAT is simple: REM *** Batch file to run A.R.P.D. cd d:\ra\arpd arpd.exe cd d:\ra You will, of course, have to change the paths to suit your system. In order for your system to process the batch file and for A.R.P.D. to perform DOS functions the call from the BBS software will have it initiate a new instance of COMMAND.COM. See your BBS software documentation to be sure of the procedure for your system. All of the files supplied with this package are necessary for the proper operation of A.R.P.D. They are : CONFIG.TNC ASCII text file describing your system. SETTING | COMMENT ---------------------------------------------------------------- BBS d:\ra | Path to DORINFO1.DEF BBSNAME The HamShack BBS | Name of the BBS DLPATH d:\archive\logfiles | Path to download directory BAUD 9600 | TNC to CPU baud rate TNCPORT 3 | Comm port for TNC TNCINT 7 | Interrupt used by TNC PROTOCOL 8N1 | TNC/CPU mode RTSHIGH | Required for recent MFJ's XFLOW | XON/XOFF flow control NEWLINE 13 | Specify c/r character TIMELIMIT 60 | Max time in door MYCALL W4KGU | TNC call setting command MYALIAS HSBBS | TNC alias setting command MYMCALL W4KGU-1 | TNC mailbox setting command CONNSTRING *** CONNECTED | TNC connect string DISCONNSTRING *** DISCONNECTED | TNC disconnect string Only the left hand portion of the file is included in the actual file. Comments are not allowed in the file. These commands may appear in any order and case is not critical. The DLPATH statement is the path to a directory where users may download files. A log of each stations activities are placed in this directory with the format CALL.LOG. Mine would be W4KGU.LOG. It would probably be best to allow only participating operators access to this directory to keep their files private. If you don't wish to make user logs available online you may make this line the path to the ARPD directory. All logs will be written in that area for your review or file attaching to the user on a quarterly basis. The BAUD, TNCPORT, TNCINT and PROTOCOL settings are for use in initializing the serial port in the computer and have no meaning as far as the RADIO end of the TNC circuit. PLEASE be sure that the comm port and interrupt agree! Any port from 1 thru 4 is valid and interrupts 3 thru 7 are valid. This allows you some latitude in setting A.R.P.D. up on a system with non-standard interrupts. The RTSHIGH is required by late model MFJ TNC's. If the RTS line is pulled low during operation of these units, no output will be sent to the terminal. If you are using an MFJ and can send to it but don't see anything back, try adding this line to the CONFIG.TNC file. If you don't need it - don't use it. XFLOW tells the system that you wish to use XON/XOFF flow control. There are no parameters, if it is there, software flow control is enabled. Hardware flow control is assumed if it is not there. NEWLINE xx allows you to change the character sent to the TNC when the <ENTER> key is pressed. This value MUST be in decimal. Either 11 or 13 are valid. If the line is not present in the CONFIG.TNC 13 ($0D) is used. The TIMELIMIT parameter is the maximum time the user will be allowed in the door. If this time is greater than the time allowed on the system as reported in the DORINFO1.DEF file it will be ignored. If it is less than system time left, the user will have to exit the door after this length of time. A.R.P.D. will allow users to re-enter the door after exiting. If you wish to prevent multiple use in a 24 hour period, you will have to do it with the BBS software. MYCALL, MYALIAS and MYMCALL are commands recognized by the TNC. The strings following the commands are sent character for character to the TNC as if typed from the keyboard. CONNSTRING and DISCONNSTRING are the strings reported by the TNC at connect and disconnect. The strings MUST be character for character as they would appear on the screen. A.R.P.D. uses these strings in conjunction with carrier detect to determine the status of the TNC. This file is space delimited. That means that the command name and the parameter must be separated by a space. No other characters are allowed to appear in the file. Everything after the space is assumed to be part of the parameter and passed to the TNC. INTRO.TNC File that is displayed to the user after the initial LOGO screen that is hard coded into the program. This allows you to personalize the program to your system. HELP.TNC ASCII text file that is displayed to users when the TAB key is pressed. The file will be scrolled 23 lines at a time with a familiar "More? (Y/n)" prompt on the 24th line. TNCNODE.TNC A one byte file which is used to create the TNCB.USY semaphore file. Nothing magic about this file. Just a space inside a text wrapper. If it gets lost you can recreate it easily. If the file does not exist the TNCB.USY file will not be created. Delete this file at your own risk. INIT.TNC A subset of TNC parameters in an ASCII text file used to clear any changes you may normally make in a "local" packet session. This file loads as the door is accessed to relieve you of the task of resetting the changes at the end of a local session. Be sure to include any parameters you might change even occasionally. This file is passed character for character to the TNC, just as if you had typed the commands from the command line. Any command valid for your TNC may be included here. DEFAULTS.TNC Same as the INIT.TNC file but more complete. This file loads the TNC with a complete set of parameters to undo any possible changes made online by a user. If the user gets upset and sets the TNC to beacon every ten seconds with rude comments about your family tree this file will clear it. Be sure it is a COMPLETE set of parameters. This file is passed character for character to the TNC, just as if you had typed the commands from the command line. Any command valid for your TNC may be included here. USERS.TNC This is a list of users who have access to the door. If this information is missing in this file users will not be able to access the TNC even if their security level and flag settings allow access to the door. Users who gain access to the door but are not listed in this file will be shown a screen explaining that they must contact the SysOp for complete access to the door. This file is white space delimited. That means that you may use a space or TAB character(s) between the strings on each line. It has the following format: LOGON NAME CALLSIGN LICENSE CLASS ACCESS ------------------------------------------------------------------ (example) Dave Perry W4KGU-2 EXTRA FULL Craig WA0WPJ WA0WPJ-4 EXTRA FULL Use of the TAB character will keep the file looking neat but one space is all that is really necessary: Dave Perry W4KGU-2 EXTRA FULL Craig WA0WPJ WA0APJ-4 EXTRA FULL would also work. Please note the use of the SSID in the callsign field. This is will prevent the users home station from responding at the same time should it be on the same frequency. Have your users pick an SSID number that will not conflict with any presently in use on other transmitters. At this time only the first two fields are in use by A.R.P.D. but the others are included for planned future expansion of the program. With radios becoming more and more computer aware it may be possible in the future that users online can pick frequencies and bands. It will then be necessary to insure that only those valid for a given user are allowed. If you turn the power off to the TNC, A.R.P.D. will sense this and inform the user that the TNC is not available for use and ask them to please try at a later time. You do not have to change access levels or flags when taking the TNC off line. The TNC clock is updated at each access to the door. This will keep the TNC time in agreement with the system clock. A.R.P.D. uses a direct control method of serial port operation both on the BBS and the TNC ports. If a FOSSIL driver is present in the system it is ignored for the time the door is in operation. This communications driver has been in use and improved over 5 years as the basis for all door programs written by PTB SoftWare and in use by other software authors for remote system access. It works very well in DOS, Windows and in a DOS box under OS/2. In the ALPHA test machine here the port is set at 9600 for TNC operations and at 57,600 for the 28.8kb modem. Internal buffering in the program and the TNC are sufficient for handling 28.8 user connects to 300 baud connects at the radio port with no loss of data in either direction under normal keyboarding conditions. Installation: Installation is simple. Just make a directory under your BBS software directory and place all the files included in this directory. Using an ASCII text editor, edit each of the files as necessary for your installation. Make a menu selection on your BBS that will allow the system to shell out to the A.R.P.D. program. Write a batch file to change the current working directory to the ARPD directory and call the program. Remember that the comm port and interrupt settings are hardware settings. Changing the comm port and interrupt numbers in the CONFIG.TNC file won't make it so. These are just pointers to hardware that must exist on your system when installed. The Land-Line comm port MUST have RTS/CTS DSR/DTR handshaking enabled. You DO NOT have the option of XON/XOFF protocol for the LL port. For ARPD.EXE to work the first time, it MUST be able to talk to the TNC. If the parameters you have set in CONFIG.TNC do not match the modem parameters (protocol - handshaking - etc.), the program will not initialize the TNC. Use a favorite packet or comm program to "condition" the TNC. Usually it is best to put in BBRAM in the TNC the values that will be used in the DEFAULTS.TNC file. If your TNC does not recognize the command strings: MYCALL MYALIAS MYMCALL DA xxxxxxxx then it will NOT work with this version of ARPD.EXE. I write better programs than documents. All of the information you need to install and use the program is here, it just may not be formatted to your taste. Read the entire document carefully and you should be able to install and use it in short order. LEGAL Stuff: This program is copyrighted software with a limited license to be used for its intended purpose without charge. It may not be sold, altered or included in any software or hardware package for any reason without the express written consent of the author. The author can accept no liability for the use or the misuse of this program or any damage resulting from such use. If you cannot accept the terms of this condition and use this program at your own risk then DO NOT USE THIS SOFTWARE. You MUST be a licensed Amateur Radio Operator to use this software. Use of this program to control on air transmissions may be a violation of Federal Law. You should check with the FCC for planned operation on certain bands/frequencies. The author cannot guarantee that under certain circumstances and conditions the use of this program on bands/frequencies where unattended operation is prohibited will not result in a citation for violation. The author can accept NO responsibility for such operation. Please check with your closest FCC office if you have any question. FCC rules and regulations Part 97.5(e) require the posting of the station license at the transmitter sight. It would be prudent to have each user supply a photocopy/fax of their license for posting. Remember, when the user logs onto the system the callsign is changed to his and becomes his transmitter for the duration of use. The user is in effect using his own station under wire-line remote control as permitted by FCC regulations. There is no charge for this program. I would appreciate a QSL or netmail to know that you are using it. I would also appreciate any feedback you may have on its operation and, of course, the inevitable bug reports. I cannot guarantee to update the software and accept no obligation for future releases. This is FREE, you know! If you are using this program in a system substantially different from the one outlined above, I would appreciate a note letting me know of any special steps or settings you have made to make it function for you. I will pass these along to others who may have similar systems or problems with particular pieces of hardware/software. All Hardware and Software products mentioned in this document by name are the sole exclusive property of their manufacturers. You may reach me at any of the following addresses: sysop@f19.n280.z1.fidonet.org InterNet Dave Perry FidoNet 1:280/19 Dave Perry SnailMail W4KGU Current Callbook Address -73-