MSCID - A Caller ID System for DLG BBS/OS (c) 1992 by Doug McLean ---------------------------------------------------------------------------- What It Does ---------------------------------------------------------------------------- MSCID is intended to implement caller ID security in DLG BBS/OS. It is completely configurable, giving you complete control (or rather, it gives your BBS control) over what happens depending on what number (or non-number?) the user is calling from. PLEASE READ THE ENTIRE DOC FILE BEFORE EVEN THINKING ABOUT SETTING UP MSCID. I really mean this!!! If you don't, you will be hopelessly confused when it doesn't work (and it won't work if you don't set it up right). I wrote these docs for YOUR benefit, not MINE! I already know how this thing works, so I don't need docs. But you will HAVE TO READ EVERYTHING or you WILL have trouble getting it to work. YOU WILL ALSO HAVE TO MODIFY THE AREXX SCRIPT TO BE COMPATIBLE WITH YOUR PHONE SYSTEM. More on this below. If you don't read these docs and read and understand the ARexx script, then you won't be using MSCID on your system. Changes to these docs are at the end of this file (future releases will have a seperate changes file). MSCID will allow you to configure the action to be taken when it detects one of several things. It checks for: - A user calling from a banned number, - When the caller ID (CID) number does not match the phone number in the user's data file, - When the user calls from a PRIVATE number, - When the user calls from a OTHER number, - When the ARexx script can't handle the ID string sent by the modem. - When the numbers match! In this case, no action is taken (aside from logging the call). The actions taken by MSCID are based on user level and which of the above things it checks for it found. The actions MSCID can take are: - No extra action, normal logging only, - Type a text file to user, - Send message to the Sysop and type a text file to user, - Send message to the Sysop and type a text file to user, then boot user off, - Execute a batch file and type a text file to user. All text files are optional, simply don't create the ones you don't want to use. Everything MSCID does is recorded in the cid.log file. Usually, you won't care what number your user's are calling from. While users might usually call from their home number, perhaps sometimes they will call from work, or from a friends house, or from somewhere else. This is fine, MSCID has the flexibility to allow this. But there was an article in a recent FidoNews about a sysop who had trouble with someone calling the BBS and leaving nasty messages, and harassing the BBS and Sysop in general. The Sysop had to go to the police, two phone companies, and court! With caller ID security, it would have been a simple matter to look in the log to determing the caller's number, and then ban this number from the BBS. It might have also have been necessary to ban calls where the id string has been blocked if the caller had this ability. Please don't expect MSCID to do too much, it is a "quickie" project that I threw together in two nights (1 for the ARexx script, which was a pain to figure out, and 1 for the executable to put in login.dlgbatch, which was really easy). Although it is very flexible and configurable, it is NOT intended to be the ultimate caller ID security program. As I write these docs, I am jumping back and forth through the text, doing some here and some there; I am not starting at the top and working down. So, I'm sorry if I say some things two or three times, and leave other things out. But there should be enough info here to get you set up... Please forgive any typing mistakes (I am sure there are plenty), I am tired, it is late (wow! 7:40 am already! I guess it is early!), and I hate writing docs. I've been working on the docs longer than it took to do the program, and I've only got a few (5-6) sections left to write :-(. Time for a nap, I'll finish this later...zzzzzzzz... ---------------------------------------------------------------------------- What You Need ---------------------------------------------------------------------------- To use MSCID you need: - DLG BBS/OS, - TrapDoor, - ARexx, - A modem that supports caller ID (such as the Supra V32bis), - A phone line that supports caller ID, - Lots of patience, and a couple of hours to set it up and test it. In addition to whatever your batch files use, the DLG executables SendMsg and TKill must be in your current search path. MSCID uses these! MSCID has been tested on an Amiga 2000 with a 68020/MMU, KS 2.04, DLG 0.995, TrapDoor 1.80, and a Supra V32bis modem with caller ID ROMs. I have not tested it under 1.3, but it should work fine, I didn't use any 2.0 only functions. However, you may have to modify extra parts of the arexx script, and you will have to modify the batch file that starts the arexx script if you haven't upgraded to 2.04 yet. ---------------------------------------------------------------------------- The Legal Stuff ---------------------------------------------------------------------------- The entire MSCID system is copyright by Doug McLean. You are free to use it without any fee. However, if you improve the ARexx script that MSCID uses, or download or otherwise find an improved version, you must send it to me (I would really like to see a better ARexx script for getting caller ID info from TrapDoor). Also, if you find any other utility to generate the required data file for use by the executable, please send it along. If you write a better arexx script, or modify the included one, why not release it via the ADS? A lot of people would probably like to see it, myself included! If you distribute MSCID, you MUST include all of the files in the original archive. You may include hints, comments, extra docs or extra arexx scripts, but you must include all of the original files unchanged. If you modify the arexx script, you must include the original, unmodified script as well. Any extra files you wish to include should extract to their own directory, this way is easier for users to keep track of everything. I do not accept any responsibility for anything MSCID does or does not do. If you use MSCID, you do so at your own risk. If it works for you, great! If it messes up your hard drive, crashes your system, or does other nasty things, it is your problem, not mine. I have tested MSCID as much as possible locally, by monitoring the log produced by CID.REXX and MSCID, and by generating a fake TL1.cid file to test MSCID by logging on locally. I haven't found any problems so far... Send comments, bug reports, suggestions, etc. to: Doug McLean The Mad Scientist's BBS FREQ V32Bis CM Fido -> 1:255/9.0 AmigaNet -> 40:940/1.0 BBS -> (506) 636-9117 ---------------------------------------------------------------------------- What Is Included ---------------------------------------------------------------------------- The following files are included with MSCID: MSCID - The executable program to read and act on the phone number file, CID.REXX - The ARexx script that communicates with TrapDoor to get the phone number the user is calling from and generate the phone number file. This is FULLY commented, READ IT! I put the comments there for your benifit, not mine. I already know how it works. If you don't understand how it works, then it probably won't work for you. CID.CFG - A sample config file. This can be a bit complex to set up... CID.DOC - If you don't have this, then you are in trouble! CID.BANNED - A sample banned numbers file, CIDRX.BATCH - The batch file to start the arexx script, #?.?.txt - Sample text files used by MSCID, #?.?.bat - Sample batch files used by MSCID. The following files are generated by MSCID and/or CID.REXX: logs:cid.log - The log file where everything is logged (path/name may be changed on the command line and in the arexx script). t:TR0.cid - The file generated by CID.REXX that contains the phone number the user is calling from. This also may be changed in the arexx script if necessary (the executable uses t:%PORT.cid). t: is best assigned to a non-recoverable ram disk. There are a couple of temporary files that MSCID generates (and deletes) that you don't need to worry about. Files provided by you: #?.?.txt - Additional text files as required. #?.?.bat - Additional batch files as required. ---------------------------------------------------------------------------- A Brief (?) Overview Of How It Works ---------------------------------------------------------------------------- The ARexx script runs all the time. It should be started right BEFORE trapdoor, preferably in your dlg.start batch file when you boot. Caller ID info is sent between the first and second ring. However, DO NOT change your trapdoor.cfg to answer on the second ring, the first ring is consumed by CID.REXX, so leave RINGS in your trapdoor.cfg set to 1 (the arexx script will get TD to answer the phone as soon as the script has the id info). Once it is running, the ARexx script tells trapdoor to wait 20 seconds for the string TIME. If, after 20 seconds, trapdoor did not get this string, the script jumps back to the top of a loop and waits for TIME again. This is to let trapdoor process any arexx commands received from other sources (such as traptell or dlgmail). If an arexx command is received by trapdoor while it is waiting for TIME, when it stops waiting it will process any arexx commands it received while waiting in the order that they were received. The last of these will be another command to wait for TIME from CID.REXX. Additionally, you must force TrapDoor to write something to it's log file once it gets TIME. What gets written is the rest of the TIME string. This is so ARexx will have time to send a message to trapdoor telling it that it should send the next line it gets from the modem to the script. This line contains the phone number the user is calling from. So, while trapdoor is writing to it's log, the script is sending an arexx message to trapdoor to tell it that it should send the next line it gets from the modem to the script. To get trapdoor to write to it's log file when necessary, set LOGLEVEL 4:5 and LOGLEVEL 9:5 (not sure of the exact value needed, but 5 works well). If you don't do this, trapdoor won't get the arexx message telling it to send the info to the script until the info is already gone! Am I doing something wrong? Did I miss something in the trapdoor and arexx docs, or is this just the way it works? You may have to experiment with things here to get it to work, but (so far) it is working perfectly here. With these log levels, you will get the remainder of the time string ( = 0930) in your trapdoor log, sorry, this can't be helped. Ok, so a call comes in. The first RING is ignored (the script isn't waiting for a RING, so it gets ignored). Then the caller ID info is sent. When it gets to TIME, trapdoor writes the rest of the TIME string to it's log, the script asks for the next line, trapdoor comes back from writing to the log and sends the next line it gets (the number string) to the script. The script remembers this string and then tells trapdoor to answer the phone, and trapdoor does trapdoor type stuff (spawn BBS, start fido session, whatever). While trapdoor is doing whatever it wants to do, CID.REXX parses the number string, converts it to something readable (the phone system here sends the info in a strange format), outputs some info to the cli (I run it in a RAW: shell on my BBS control screen), writes a file that contains the phone number, and writes to logs:cid.log. It then jumps to the top of the loop and tells trapdoor to wait for TIME again. Trapdoor doesn't process this message until it hangs up, and it will first process any messages it got before the wait. So, by the time the user logs in, there is a file called T:TR0.CID waiting for the executable to read it. If the call was from a node, this file isn't used, and is over-written by CID.REXX on the next call (but you could do something in AFTERSESSION to use this file if you wanted!). In login.dlgbatch, MSCID reads T:TR0.CID, does it's checks, and takes whatever action is called for, if any. It then deletes the number file, and exits. The number file must be in a specific format, when you modify the arexx script it must generate a file that contains one of the following things: - the string OTHER - the string PRIVATE - the string ????? - the users phone number as text (ex: 6369117). There should be no spaces or dashes or other characters in/before/after the number! Just the number! So, 636-9117 is WRONG, and 6369117 is wrong too. These 4 possibilities are more fully explained later. Now, lets say that the ARexx script is running, and DLGMail decides that it wants to call out. Trapdoor is stuck waiting for TIME. What happens is that DLGMail sends the message to trapdoor, and trapdoor stores this message until it is free again. After up to 20 seconds, if trapdoor didn't get TIME in a string, the script continues and jumps back to the top of the loop where it tells trapdoor to wait for TIME again. When trapdoor gets to the command from DLGMail, it acts on it and does whatever is required. While it does this, it gets and stores the next message from CID.REXX. Once it finishes with the command from DLGMail, it will act on the message from the script, and will again be waiting for the string TIME again. ---------------------------------------------------------------------------- Using Parts Of The System Etc. ---------------------------------------------------------------------------- It would be possible to write a C program that is SPAWNed by trapdoor to generate the number file (such a program would be SPAWNed by an arexx command, not the same as spawning the BBS). A program like this would be spawned every 20 seconds and directly monitor the serial port and generate the number file. Such a replacement would execute much faster, and would not rely on trapdoor's arexx port to get the id info. It would have to exit and be re-run every 20 seconds to give trapdoor a chance to process other arexx commands. In the same way, MSCID could be replaced in your login.dlgbatch file with a different executable, or perhaps by an arexx script. You could write a script to replace MSCID, or one to be run before it to compliment it. Whatever you do, if you come up with anything interesting, please let me know! ---------------------------------------------------------------------------- Setting Everything Up ---------------------------------------------------------------------------- Well, this is the last section I have to write (I already finished the other sections). Maybe I can just skip this section? No? Ok, here goes... First, MSCID assumes that all text and batch files are found in DOORS:CID/. So that is where you better put everything! [1] Completely read the docs and arexx script (did I mention this before?) [2] Set your modem to generate formatted caller id info. On the SupraFax, use AT#CID=1&W from within a term program, or from the CLI use TRAPTELL "SMODEM AT#CID=1&W|" [3] Make sure that the following log levels are set to 5 in your trapdoor.cfg: LOGLEVEL 4:5 LOGLEVEL 9:5 Also, you should have RINGS 1 set in your trapdoor config file. The arexx script will tell trapdoor to answer the phone before the second ring. Get trapdoor to re-read the config file. Either re-boot or use traptell. TRAPTELL "CONFIG MAIL:TRAPDOOR.CFG" [4] After a few calls, read your trapdoor log file to figure out how your phone system sends caller ID info and how your modem persents it. [5] Modify the arexx script (CID.REXX) to suit your phone system, modem, and trapdoor/bbs configuration. See below and the comments in the script. [6] Install your modified arexx script. I do this in my dlg.start batch file, just before trapdoor is run. Here is the appropriate section from my dlg.start file: echo ">>>>> Activating Ports <<<<<" newshell "RAW:304/448/336/64/CID/SCREEN BBSScreen" from doors:cid/cidrx.batch dlg:ActivatePort -p TR0 -b "Execute DLGConfig:Batch/td.batch" dlg:ActivatePort -p TL0 -b "" As you can see, the script is run using a newshell command with a FROM file (CIDRX.BATCH). The command line specifies that the window for the new shell should be a RAW: window (so you can't type into it and freeze everything up), and it goes on a public screen called BBSScreen (where my trapdoor, dlgmail, tptcron, and a couple of other windows reside, along with a special shell that has aliases useful for the BBS). If you use 1.3, you will have to change the above until you upgrade, since you don't have public screens. But you should still either use a RAW: window, or use the RUN command with output re-directed to NIL: (or some other null type device?). Here is my cidrx.batch file: rx doors:cid/cid.rexx endcli As you can see, all it does is start the arexx script, and end the cli when the script exits (which only happens when it gets a control C). So, all I am saying in step 6 is to get the arexx script running somehow in your system, preferably before trapdoor, and make sure that you can't accidentally freeze it by typing into it's window (if you run it in a RAW: window, you can't freeze it by mistake, but you can still break it with a control C in the RAW: window). Enough about getting the arexx half running... [7] Now that you have modified the arexx script and have it running, check the cid.log after a few calls to make sure that the data is being handled correctly. Also check some CID number files (T:TRx.CID) to make sure that they have the numbers in correct format. It is a good idea to run just the arexx script without the MSCID executable for a couple fo days just to make sure everything is working ok. [8] Create your CID.CFG file in DOORS:CID/ This is explained elsewhere in these docs. [9] Create any batch files you will need. You will need one batch file for each B action in your config file. Unlike text files, MSCID assumes that any batch files you have configured WILL BE THERE. See below somewhere for info on batch files, their names, and what gets passed to them. [10] Create any text files you want. Each action (except N) for each set of levels can have it's own text file. If MSCID looks for a text file that isn't there, that is fine, it will just be skipped. Note that text files should be short, they are NOT paused every screen like DF does (there is no MORE prompt). There is, however, an ANY KEY prompt displayed at the end of the batch file... [11] Install MSCID as the first line in your DLGCONFIG:BATCH/LOGIN.DLGBATCH file. The command line is: Doors:cid/mscid %PORT LogFile "Sysop Name" The logfile should be the same log file that is used by CID.REXX, this is normally LOGS:CID.LOG. Replace "Sysop Name" with your name, MSCID will use this to send you messages. Here is my entry for MSCID in my login.dlgbatch: doors:cid/mscid %PORT logs:cid.log "Doug McLean" [12] You are ready to go. I hope I didn't leave anything out! Oh ya, in all the above I forgot to mention to get caller ID turned on for your phone line, but I'll assume that you knew you had to do that... ---------------------------------------------------------------------------- Modifying The Arexx Script - DOORS:CID/CID.REXX ---------------------------------------------------------------------------- First, I am *NOT* an arexx programmer. I don't know much about arexx, and CID.REXX is only my second real arexx script. It took me longer to write than it should have because I had to experiment a bit, and look everything up. Although CID.REXX works flawlessly (so far) on my system, I am sure someone who knows more about arexx could do better (someone please give it a try!!!). You MUST modify the arexx script. As you can see from the sample log file near the end of the docs, my phone system presents caller ID info differently than yours (well, it probably does). The CID.REXX script MUST generate a file as explained below under "The CID Number File" if you plan to use MSCID. CID.REXX is fully commented (print it out!), but here are some hints for modifying it: - Do not run CID.REXX at first. Instead, set trapdoor's log levels high enough so that the id info is written to the trapdoor log file. - Use the info from the trapdoor log file as a guide for modifying the arexx script. - Install your modified arexx script but NOT MSCID, and monitor the log file that the script generates. CID.REXX logs the raw id string as well as the converted number, this was a big help for me. - Watch a bunch of calls to make sure the phone is being answered when it should be. If things aren't working right, trapdoor might not answer the phone at all! - Once the arexx script is working properly, install MSCID in your login.dlgbatch file. If the arexx script messes up occasionally (hasn't happened yet, but...), then trapdoor could lock up for 20 seconds. If it really messes up, then trapdoor could always be waiting for TIME and NEVER answer the phone. You might have to play with the script a bit... The script also checks every 20 seconds to make sure trapdoor is running. If trapdoor is down, the script will wait until it goes back up (if you take trapdoor down, you will also get an error message in the window that the script is running in, ignore this message, it is normal). I have not been able to get CID.REXX to read all 4 lines of info that the Supra can send (actually, I don't get NAME up here at all, it isn't supported here by the phone company). If I try to get all 4 lines, when I get the first, the rest flash by at 38400 baud before the script can tell trapdoor it wants them too. I can only get one line reliably, and being somewhat logical, I chose the phone number string (which follows the TIME string). I looked at getting the string as an un-formatted text string (AT#CID=2), using something like the following: STIMEOUT 20 SWAIT 'RING' if result = 'RING' then do SLINE ....... Guess what? It didn't work... In the time between the SWAIT and the RING, the id string flashes by on the screen at 38400 baud. As a result, the SLINE gets the next ring, and completely misses the id string... That's all I'll say about the arexx script. It is fully commented, so read it for further info. ---------------------------------------------------------------------------- The CID Number File - T:TRx.CID ---------------------------------------------------------------------------- If you have been paying attention (hey WAKE UP!) then you know that the CID number file is called T:TRx.CID and is generated by the arexx script. The first line of the CID number file must contain one of the following: [1] The phone number the user is calling from. This must consist of only number digits (0 to 9) with no spaces, dashes, brackets, or other characters. A return must immediately follow the last digit in the number. This is not a binary number, but a text one (human readable) Example: 6369117 [2] The string PRIVATE (upper case). If the user calls from an unlisted number, or uses ID blocking, the file should contain this string. On the phone system here, P is returned in both of these cases. Also, P is returned by the system here if the exchange the caller is calling from does not yet support caller ID. I have no way to distinguish between numbers that do not yet support caller ID and when the user has blocked the ID string. If your system allows you to seperate these, then you are better off if you have the script generate OTHER instead of PRIVATE if the user's exchange does not support caller ID. Example: PRIVATE [3] Up here, when a call comes from another country (and perhaps for other reasons too), it returns an O. In this case, the CID.REXX script writes OTHER to the CID number file. OTHER is intended for when you don't have the actual number, but you know it isn't private and it hasn't been blocked. Example: OTHER [4] If the arexx script encounters anything that it doesn't know how to deal with, it writes ????? to the CID number file. I haven't gotten this in my logs yet, but you need it in case there is some rare type of call that you don't know about. If you get this in the log file, look at the raw string that the modem returned and try to figure out what is going on. Example: ????? The above 4 cases are the ONLY things that are currently acceptable in the first line of the CID number file. Anything else might hopelessly confuse MSCID, and may cause un-expected results. You may include extra lines in this file if you wish. For example, your phone company may provide more info than mine, or you might have better luck getting more than one line of info from trapdoor... You can put whatever info you want starting on the second line of T:TRx.CID... This file is automatically deleted by MSCID, but not until AFTER whatever action that is required has been taken. So, if you are using MSCID to run batch files, you will have access to the CID number file from the batch file, or perhaps you might wish to run some other utility ahead of MSCID to read extra info from the file first. If you wish to preserve this file for any reason, you must copy it before MSCID exits, because it gets deleted at this time... If MSCID cannot find the CID number file, it will log the fact that the file isn't there, and exit (don't worry, a missing number file won't cause your system to mess up or guru). ---------------------------------------------------------------------------- The Config File - DOORS:CID/CID.CFG - And Text And Batch File Names ---------------------------------------------------------------------------- The config file is DOORS:CID/CID.CFG Everything in the config file is POSITION DEPENDANT. DO NOT leave an extra space after the root name, or any spaces except where shown in the example config file. The format for the config file is: LLL - HHH NPOQB ROOT_NAME LLL = a 3 digit number (pad with 0s) lowest user level this line applies to. HHH = a 3 digit number (pad with 0s) highest user level this line applies to. ROOT_NAME = the root file name for text/batch files. NPOQB are reasons for taking action, and are position dependant. The reasons are: N = CID number and number in data file don't match P = CID number is PRIVATE O = CID number is OTHER Q = CID number is ????? (the program that generated number file didn't know what to do) B = CID number is found in cid.banned file These reason letters do not actually appear in the config file, each reason is replaced by an action code. The action code in the N position is for when the numbers don't match, the action code in the P position is for when the CID number is PRIVATE, etc. Action Codes ~~~~~~~~~~~~ N = No extra action, normal logging only T = Display text file to user only M = Send message to Sysop, send text file to user K = Send message to Sysop, send text file to user, boot user off B = Execute batch file, send text file to user Here is a table of actions and file names: # Action Text File Batch File --------------------------------------------------------------------------- N normal logging only T display text file doors:cid/root_name.x.txt M system writes message doors:cid/root_name.x.txt K kick user off doors:cid/root_name.x.txt B execute batch file doors:cid/root_name.x.txt doors:cid/root_name.x.bat --------------------------------------------------------------------------- Where x is the REASON that an action is required, one of N, P, O, Q, or B, as above. If you don't want a text file displayed, simply do not create it. A sample config file might look like: ; 12345 000 - 001 MMNMK newuser 002 - 019 BTNMK valid 020 - 255 TTTMK member Lets look the first line of this config file: - Line one applies to users of level 0 (probably not possible) or 1. - If the number in the user's data file doesn't match the number from the caller ID string (position 1): The text file DOORS:CID/NEWUSER.N.TXT will be displayed, A message will be sent to the sysop. - If the user is calling from a PRIVATE number (position 2): The text file DOORS:CID/NEWUSER.P.TXT will be displayed, A message will be sent to the sysop. - If the user is calling from a OTHER number (position 3): No action will be taken. - If the user is calling from a ????? number, this means that the included ARexx script didn't know how to handle the ID string (position 4): The text file DOORS:CID/NEWUSER.Q.TXT will be displayed, A message will be sent to the sysop. - If the user is calling from a banned number (position 5): The text file DOORS:CID/NEWUSER.B.TXT will be displayed, A message will be sent to the sysop, The BBS will hang up on the user. The other lines operate in a similar manner. As you can see, this gives you complete control over what happens... Note that MSCID does not unconditionally hang up when a user calls from a number in the banned file, instead it takes the action you have set (which in this case is to hang up). If you do not want a text file to be displayed, simply do not create it. In the above example, you wouldn't want a NEWUSER.Q.TXT file. In line 2 of the above example, if the numbers don't match, then a batch file would get executed. In this case, the batch file would be: DOORS:CID/VALID.N.BAT If present, the text file DOORS:CID/VALID.N.TXT would also be shown to the user. Note that there is nothing to say that you can't use the same root name more than once. The following config file would be valid: 000 - 001 MMMMK cidtxt 002 - 255 TTNMK cidtxt In this case, when a new user requires a N, P, or O action, the text file would be shown and a message sent to the sysop. For validated users, a N or P action would display the same text file but the sysop would not get a message, and a O action would be ignored. In both cases, a Q action would send a message to the sysop, and a B action would boot the user off after displaying doors:cid/cidtext.b.txt (if this file exists). The point is, you can use the same text (or batch) files over again for different levels by specifying the same root name. ---------------------------------------------------------------------------- The Batch Files ---------------------------------------------------------------------------- A batch file is executed whenever the B action is required. Read the above for the naming of batch files. The name of the user and the port he is on are passed to the batch file. Using this information, you can use an executable or arexx script to access the ram file for the user, access any of his data files, or the CID number file. Here is a simple batch file that simply prints some info: .key name/a,port/a .bra [ .ket ] echo "*nName: [name] Port: [port]" echo "CID Number file name: T:[port].CID*n" See your AmigaDos manual for more info on batch files... ---------------------------------------------------------------------------- The Banned Numbers File - DOORS:CID/BANNED.CID ---------------------------------------------------------------------------- The banned file contains a list of banned phone numbers, EXACTLY as they would appear in the CID number file. The banned numbers file has nothing to do with the number in the user's data file!!! It is the CID number from the modem that is used for the banned check, the number in the user's data file isn't even looked at during the banned check. Whenever a phone number appears in the CID number file (instead of PRIVATE, OTHER, or ?????), the COMPLETE number is checked against the list of numbers in the banned file. When a banned number is detected, the user is not automatically booted off, but instead whatever action you you have set for that user level is taken (which, of course, could be to kick the user off). When checking to see if a user is calling from a banned number, the WHOLE NUMBER in the CID number file is compared to the whole number in the banned.cid file. So, if you enter numbers into the banned.cid file, they must exactly match what will appear in the CID number file. The number must be immediately followed by a return. Example: 6369117 15058491122 Consider the following log entries: Sunday 01-Nov-92 22:53:17 CALL # : 17 RAW STR: MESG = 030736373234333231 NUMBER : 6724321 Name : Some user CID Number : 6724321 File Number : 506 672-4321 Numbers match Sunday 01-Nov-92 22:53:17 CALL # : 18 RAW STR: MESG = 03073134353530313032 NUMBER : 14550102 Name : Some other user CID Number : 14550102 File Number : (506) 459 2221 Numbers do not match If you wanted to ban both of these numbers, the banned.cid file would contain: 6724321 14550102 Note that even if the user's CID number matches the number in his data file, the banned action will be taken if the CID number is banned. The best way to figure out exactly what to enter into the banned file to ban a particular number is to take the number directly from the CID Number field in the cid.log file... ---------------------------------------------------------------------------- Possible Problems ---------------------------------------------------------------------------- I'll list any potential problems I can think of here... Consider the following. The arexx script waits for 20 seconds for the string TIME. Now, an arexx command from some other source arrives at TDs arexx port, and is waiting to get processed. Just after the arexx command arrives, a user calls. The script gets TIME from this call. Now, the arexx command that was sent from elsewhere gets processed before of the SLINE in the script. The shorter the STIMEOUT in the script, the less likely the probability of this happening (it hasn't happened here yet). However, if this does happen, things should go back to normal for the next call. ---------------------------------------------------------------------------- Anything Else? A Few Additional Notes... ---------------------------------------------------------------------------- When MSCID checks to see if the number in a user's user record is the same as the number he is calling from, only the last 4 digits are used. This is necessary because users don't use always the suggested format (and I can't use a template because I sometimes get calls from Europe, where the numbers are different). So, the last 4 digits of the number in the CID file are compared to the last 4 digits in the user's data file. This should be completely sufficient for checking to see if the user is calling from his registered number. Banned numbers are checked before the other conditions. Banned numbers take priority over all other conditions. If a CID number is banned, the banned action is taken EVEN IF THE CID NUMBER MATCHES THE NUMBER IN THE USERS DATA FILE. Since MSCID runs fairly quickly (the user normally won't even notice it), it usually ignores control C breaking. Usually, by the time it gets a control C, it would be just about ready to exit anyway. However, there is one place where it expects input from the user, this is at the [ANY KEY] prompt at the end of typing a text file. Just before this prompt, control C checking is turned on. MSCID (the executable) will not report errors in the configuration file or other errors to the screen (except if you mess up the command line). Instead, the errors are logged to the log file, and sometimes a message sent to the sysop. Well, these docs are now about 38K. That is bigger than everything else that will go in the archive put together! Sorry, I didn't mean to write a book! Since I am tired of writing docs, and I *think* (hope) I covered just about everything, I'll stop now. I hope I didn't confuse you too badly!!!!! ---------------------------------------------------------------------------- Sample Log File - LOGS:CID.LOG ---------------------------------------------------------------------------- Here is an extract from my logs:cid.log file: Sunday 01-Nov-92 22:09:05 <- Call from a number that is unlisted, CALL # : 16 <- or has caller ID blocked, or (more RAW STR: NMBR = P <- likely) an exchange that does not yet NUMBER : PRIVATE <- support caller ID. Name : Jamie Tait CID Number : PRIVATE File Number : 506-672-1234 Private number No action Sunday 01-Nov-92 22:53:17 <- Normal call from a user at home CALL # : 17 <- where the number agrees with RAW STR: MESG = 030736373234333231 <- the user record. NUMBER : 6724321 Name : Roy Greer CID Number : 6724321 File Number : 506 672-4321 Numbers match Sunday 01-Nov-92 23:17:06 <- This call never made it to the login.dlgbatch CALL # : 18 <- file. The user could have hung up, or it RAW STR: NMBR = O <- could have been a fido call (in this case it NUMBER : OTHER <- was a fido call from out of the country). Sunday 01-Nov-92 23:20:55 CALL # : 19 [... more caller info as the log continues ...] ---------------------------------------------------------------------------- Sample Config File - DOORS:CID/CID.CFG ---------------------------------------------------------------------------- 000 - 001 MMNMK t_newuser 002 - 019 MTNMK t_valid 020 - 255 NNNMK t_member ; ; ; Use ; at the start of a line for comments ; ; Each Line ; ~~~~~~~~~ ; LLL - HHH NPOQB ROOT_NAME ; ; LLL = a 3 digit number (pad with 0s) ; lowest user level this line applies to. ; HHH = is a 3 digit number (pad with 0s) ; highest user level this line applies to. ; ; N = action if numbers don't match ; P = action if number PRIVATE ; O = action if number OTHER ; Q = action if number ????? (program that generated number file ; didn't know what to do) ; B = action if number banned in cid.banned file ; ; ROOT_NAME = the root file name for text/batch files. ; ; It is a good idea to start all root names with the same string ; (something like t_) so they will all appear together when you do a ; directory). ; ; Actions ; ~~~~~~~ ; N = No extra action, normal logging only ; T = Only display text file to user ; M = Message to Sysop, text file to user ; K = Message to Sysop, text file to user, boot user off ; B = Execute batch file, text file to user ---------------------------------------------------------------------------- Changes For The Initial Release ---------------------------------------------------------------------------- Rather than try to change the docs (which took long enough to do), I'll just list any changes here... - Added a bit more from MSCID in the log. - CID.rexx no longer answers the phone with ANSWER IMMEDIATE. Things seem to work better if I let TrapDoor answer on the second ring instead. - You can disable CID.rexx temporarily with an environment variable. To pause CID.rexx, at the CLI use: setenv cid off and to un-pause it use: setenv cid on (or anything not starting with off) or simply delete the file env:cid. This is very handy when you want to use TrapDoor's arexx port with something else, perhaps another script.