Date: Sun, 18 Dec 1994 07:34:27 +0000 From: "Brian A. Lantz" To: TNOS Topics Mailing List Subject: Proxy command..... On Tue, 6 Dec 1994, Dave Ewaldz N9HKM wrote: > Reminder- you were going to post some example script files for the proxy > stuff..... > nudge nudge :-) > Thanks! Yes, I forgot this in the distribution! I am NOT going to re-issue 1.10 files with this in them; that will wait to 1.11. Here are the few files needed. I have them in a "scripts" directory off of the root TNOS directory. The "proxy.scr" file should ALSO be in the spool/cmds directory with the name "proxy.cmd" (or under Linux, this can be a symlink). I THINK this is all that's needed! If you discover problems, you know how to ask ;-) ---------------waitprmp.scr----------------------->8 cut here ~ In calling getproxy.scr, the following variables are passed..... ~ ~7 areaname ~ ~8 password ~ ~9 username ~ Stream 1 is set to the BBS connection stream ~ ~ if ax25, skip to BBS prompt ~ Set to BBS stream ~ ~g bbsprompt ~ ~ ~ wait for a BBS login prompt ~a 2 login: ~l loop1 ~# 1 ~n exit ~ get a string from stream 1 into string variable 1 ~v 1 ~ do we have the prompt on this line? if so, give the login... ~h 1 2 1 givename ~ change to user's I/O stream ~ ~# 0 ~ output the line received ~ < ~1 ~g loop1 ~ ~l givename ~# 0 Login request found.... ~# 1 ~n exit ~9 ~ ~ ~ wait for a BBS password prompt ~a 2 assword: ~l loop2 ~# 1 ~n exit ~ get a string from stream 1 into string variable 1 ~v 1 ~ change to user's I/O stream ~# 0 ~ do we have the prompt on this line? if so, give the password... ~h 1 2 1 givepwd ~ output the line received ~ < ~1 ~g loop2 ~ ~ ~l givepwd ~# 0 Password request found.... ~# 1 ~n exit ~8 ~ ~ ~l bbsprompt ~ set up a prompt comparision string equal to ">" ~a 2 > ~ wait for a BBS prompt character ~l loop3 ~# 1 ~n exit ~ get a string from stream 1 into string variable 1 ~v 1 ~ change to user's I/O stream ~# 0 ~ output the line received < ~1 ~ do we have the prompt character in this line? if so, goto exit ~h 1 2 1 exit ~ else, loop back ~g loop3 ~ ~ ~l exit ~# 0 ---------------getproxy.scr----------------------->8 cut here ~ In calling getproxy.scr, the following variables are passed..... ~ ~7 areaname ~ ~8 password ~ ~9 username ~ Stream 1 is set to the BBS connection stream ~ ~ set up a prompt comparision string equal to message indicator ~a 2 Current msg# ~o scripts/proxy.tmp ~se ~# 1 ~7 ~w ~n--------------------------------------------------~n ~w Proxy command: '~7'~n~n ~l loop ~# 1 ~n exit ~ get a string from stream 1 into string variable 1 ~v 1 ~ change to user's I/O stream ~# 0 ~ do we have the indicator string in this line? if so, exitcheck ~h 1 2 1 exitcheck ~ else, add it to the file ~w ~1~n ~ output the line received < ~1 ~g loop ~ ~ ~l exitcheck ~ Check to see if BBS prompt is on this line ~a 2 > ~h 1 2 1 exit ~ else, eat another line ~# 1 ~v 1 ~l exit ~w ~n ~# 0 ---------------opennew.scr------------------------>8 cut here ~f scripts/proxy.tmp ~w Result of ProxyMail from ~h for '~9'~n ~w ~d ~t~n ~w ~n ---------------proxy.scr-------------------------->8 cut here TNOS ProxyMail Opening the TNOS ProxyMail data file ~i0?0 masterproxy ~o spool/proxy.tmp ~g allproxy ~ ~ ~l masterproxy ~o spool/proxy.dat ~l allproxy ~ If found the file, goto the main loop ~y mainloop File "spool/proxy.dat" not found. Ending TNOS ProxyMail... ~x ~ This is the main loop of TNOS ProxyMail ~ It reads the data file until it finds the beginning of the next record ~ ~ The format of the record is: ~ [name] ~ (password) <- this is an optional line, if no pword is needed ~ areaname ~ ...... ~ lastareaname ~ ~ ~l mainloop ~ Read one line into string variable 1 ~r 1 ~e endofmainfile ~ make a new string (2) from string 1, starting at pos 0 for len of 1 ~p 2 1 0 1 ~ compare this first char to a "#", if so, skip the comment ~a 4 # ~c 2 4 mainloop ~ compare this first char to a "[", if so, process it ~a 4 [ ~c 2 4 doentry ~ else, skip this and get next line ~g mainloop ~ We now have the beginning of an entry. The name is in ~1 enclosed in [] ~l doentry ~ get the size of the string, including the []'s, place size in ~i1 ~z 1 1 ~ adjust for the "[]" characters ~i1-2 ~ set string variable 9 to the user name ~p 9 1 1 ~i1 ProxyMail user '~9' found.... ~ create the header for the mail data file ~$ scripts/opennew.scr ~ ~l pwloop ~ Now we need to look to see if there is a password given here ~ save the current file position, in case there is none ~i4=~p ~ read a line ~r 1 ~e endofmainfile ~ make a new string (2) from string 1, starting at pos 0 for len of 1 ~p 2 1 0 1 ~ compare this first char to a "#", if so, skip the comment ~a 4 # ~c 2 4 pwloop ~ compare this first char to a "(", if so, get the password ~a 4 ( ~c 2 4 getpwd ~ else, we are ready to go ~ First, set password to 'proxymail' ~a 8 proxymail ~ then seek back to this line, for "processit" ~sp 4 ~g processit ~ ~ ~ Process the password.... ~l getpwd ~ get the size of the string, including the ()'s, place size in ~i1 ~z 1 1 ~ adjust for the "()" characters ~i1-2 ~ set string variable 8 to the password ~p 8 1 1 ~i1 Password '~8' found for ~9... ~ ~ ~ Now we are ready to ProxyMail the user's desired areas ~l processit ~ save position, in case we are done... ~i2=~p ~ read a line ~r 1 ~e processdone ~ make a new string (2) from string 1, starting at pos 0 for len of 1 ~p 2 1 0 1 ~ compare this first char to a "#", if so, skip the comment ~a 4 # ~c 2 4 processit ~ compare this first char to a "[", if so, we are done with this entry ~a 4 [ ~c 2 4 processdone ~ check for a blank line, if so, skip it ~z 1 1 ~i1?0 processit ~ otherwise, we are looking at a command, copy it to string 7 ~a 7 ~1 ~ ~ ~= 1 ~y alreadyconnected Connecting to 127.0.0.1 ~ Connecting to tbars ~( 1 tel 127.0.0.1 ~ ~( 1 c 2m tbars k0zxf-4 813105 ~n notconnected ~# 0 ~$ scripts/waitprmp.scr ~# 0 ~= 1 ~n notconnected BBS Connection complete..... ~g alreadyconnected ~l notconnected Can't connect to 127.0.0.1 ~ Can't connect via ax25 to tbars! TNOS ProxyMail Aborted! ~x ~l alreadyconnected ~ In calling getproxy.scr, the following variables are passed..... ~ ~7 areaname ~ ~8 password ~ ~9 username ~ Stream 1 is set to the BBS connection stream Adding listing of command '~7'... ~$ scripts/getproxy.scr ~# 0 ~ see if still connected..... ~= 1 ~n huh ~ now we see if there are more.... ~g processit ~ ~ ~l processdone All areas complete! ~ seek back to the beginning of this line ~sp 2 ~ If we are connected (which we SHOULD be) disconnect ~= 1 ~n huh ~# 1 bye ~ ~) 1 ~l waitdisc ~ dummy read, bit bucket...... ~v 1 ~ are we connected - the above ~v senses this condition, so it IS required ~= 1 ~y waitdisc ~# 0 ~l huh ~ now it's time to send the mail message to the user Mailing ProxyMail results to ~9 ~d ~9 scripts/proxy.tmp ~ Go back for more ~g mainloop ~ Normal endoffile - all done ~l endofmainfile End of file - ProxyMail complete! ----------------------------------------------------------- Date: Thu, 5 Jan 1995 00:59:18 +0000 From: "Brian A. Lantz" To: TNOS Topics Mailing List Cc: NOS-BBS Mailing List Subject: Transparent connection - compressed gatewaying This is being sent to NOS-BBS, also, since there will also be some interested parties using JNOS.............. There has always been a problem with making connections from xNOS systems and having fully transparent data flow to the distant station. For instance, an FBB BBS connects to a xNOS system, then does a connect off of the xNOS system to another FBB system. If this is done, they cannot use compressed forwarding. This has been because (1) the escape character, when received as data from the first station, will bring down that second link, and (2) some versions of xNOS have code that looks at the incoming data from the second station that interprets the telnet negotiations, if they occur. This makes at least two of the possible 255 characters unable to pass through the link. Then there has been the fact that the sockets are created in ASCII mode, which means that CR/LF translations happen when a LF is seen in either direction. YES.... I said "has been"........ The following is a way to make totally transparent connections off of a xNOS BBS for BBSs. It has been tested successfully between two FBB stations using AXIP, one in Florida, one in California. While the testing has not been extensive (yet), it is conclusive enough to present this as a solution to this problem........... The following are three routines, all located in mailbox.c of TNOS (possibly in mailbox2.c of JNOS). For TNOS users, you can replace these routines with these new ones. For JNOS users, you will have to do some comparison. What this does is allow you to set a "NO_ESCAPE" bit to a user's ftpuser permissions that (1) makes there be NO outgoing escape character search, (2) no incoming telnet negotiations search, and (3) places both sockets in binary mode during the gateway, preventing CR/LF translations. I honestly can't remember if the NO_ESCAPE came from TNOS or JNOS originally, but it is now a usable option. Now, probably a more accurate name would be "TRANSPARENT", but for now "NO_ESCAPE" will remain. The NO_ESCAPE value is 65536 (0x00010000). One other problem is fixed with this code. There have been times when station 1's link to station 2 breaks down, but station 1 doesn't seem to realize this. Then station 1 continues to send traffic, but to the xNOS system, instead of station 2. This code has a gateway by a "NO_ESCAPE" user end with a disconnect, to prevent this from accidentally happening. James, feel free to add this to JNOS (or ignore it). For those TNOS users that don't "roll their own" compiles, this is one of MANY little changes in release 1.11, coming soon to a computer near you. ----------------------------------------------------------- Date: Thu, 5 Jan 1995 04:12:05 +0000 From: "Brian A. Lantz" To: TNOS Topics Mailing List Cc: NOS-BBS Mailing List Subject: Re: Transparent connection - compressed gatewaying After further testing, it seems that a warning is needed. This transparent fix is ONLY good for non-telnet connects. Telnet cannot be transparent. Also, if you, for instance, try to test this with a the "bbs" command (which IS a telnet session), you will see what happens when you do this. You end up loosing a character after each CR received. This should NOT be a problem, since the only ones who need this kind of fix are non-NOSers............. ----------------------------------------------------------- Date: Sun, 15 Jan 1995 21:35:14 +0000 From: "Brian A. Lantz" To: TNOS Topics Mailing List Subject: Security command..... No, don't do a "?" command at your command session. You won't find it in 1.10, but you WILL find it in 1.11..... Here is a BRIEF description. security ax25perms value The permission level given to an anonymous BBS user who entered the BBS by AX25 or Netrom. The "univperm" value in ftpusers is overridden by this. security ampronly [on|off] A quick override for all anonymous users, limiting them to only ampr.org telnet sessions. No other telnet sites will be available. This overrides their normal permissions. security tipperms value (formerly "mbox tipsecurity") The permission level given to an anonymous BBS user who entered the BBS by TIPMAIL. The "univperm" value in ftpusers is overridden by this. security encode This recalls the routine (automatically called on TNOS startup) that encodes passwords in the ftpusers files (yes, I said FILES. Patience.....) security mbsecure [on|off] (formerly "mbox mbsecure") A quick override for all anonymous users, limiting them from permission to AX25 and Netrom connects. This overrides their normal permissions. security level [levelname pathstring permissions] Allows you to set up a name for a security level, that can be used as a shortcut in the ftpusers files (there it is again). The levelname can be anything descriptive. The pathstring is the same format as the third field of the ftpusers files (tension building). The permissions field is the same format as the fourth field of the ftpusers files (OKAY!). The "security level" command (without the rest of the parameters) displays the currently defined security levels. THE FTPUSERS FILES: (betcha thought I'd NEVER get to this!) There are two new additions to the 'ole ftpusers file. The first is the additions of a "#include filename" directive. If a line of this form is found, the file given will be opened at this point and processed. Control returns to the original FTPUSERS file, if the given user is not found in the included file. You can have as many included files as you wish, but you cannot include a file from WITHIN an included file. Results are guaranteed to be incorrect. You've been warned! The second addition is the format for the security level shortcuts. Use: user password #levelname The "#" is important. It is what tells TNOS that this parameter is a defined security level. Why security levels? If you only have a few users, with none or few changes/additions, you probably won't have much use for it. But if you have a "hoppin'" machine, this can make administration easier. It also allows you to change the permissions for any security level remotely. You can define users, BBSs, sysops, budlists, etc. and then use the shorthand in the ftpusers fileS. Both of these FTPUSERS additions are in ADDITION to all of the pre-1.11 abilities of the FTPUSERS file. They augment, not replace existing syntax. And the "univperm" value (if defined) only applies to anonymous telnet users. There are separate values for ax25/netrom and tipmail users defined by the security command. ----------------------------------------------------------- Date: Sun, 22 Jan 1995 16:30:25 +0000 From: "Brian A. Lantz" To: TNOS Topics Mailing List Subject: Coming soon to a NOS near you..... Another of the features being added with release 1.11 is Mail Filtering. While the term may not be familiar, it's feature is, if you are familiar to most PBBS programs. This allows you to automatically save messages as files, with the filename based on the BID, subject, or with a temp name. You can set up the spool/mbfilter.dat file to match for the following: Sender's callsign FU Sender's BBS (or hostname) FB Addressee's callsign TU Addressee's BBS (or hostname) TB Original BID BD Subject SB Any of these fields can be blank or have a "*" to match any value for that field. The syntax for the mbfilter.dat file is: :FU:FB:TU:TB:BD:SB: =ret @dirname ~filename The definition line ':FU:FB:TU:TB:BD:SB:', always starts and ends with a ':'. The fields are as above. The '=ret' line (optional), allows you to tell the smtp server whether or not to bit-bucket the message. If ret=0, then the message will not be saved by the smtp server. The default for ret is 1, which saves the message, in addition to saving it. The "@dirname" line, defines the directory that you wish the file stored in. If this is not defined, the will be stored in the current directory, or in the path specified by the other criteria. The '~filename' line has several possibilities. ~:bid: uses the bid as the filename ~:subject:x: gets the filename from the subject line, skipping 'x' words. ~:temp:AA: makes a temporary filename starting with the two characters 'AA' ~xxxxxx anything else, gets taken as a filename, with possible explicit or relative pathlist. Blank lines and lines beginning with a '#' are comments. Examples: :*:*:arrl:usa:arl:*: =1 ~:bid: @/nos/public/arrl # :*:*:arl:usa:arl:*: =1 ~:bid: @/nos/public/arrl These two lines that any messages addressed to 'arrl*@usa' or 'arl*@usa' with a bid beginning with 'arl', and stores them in the /nos/public/arrl directory, with a file name taken from the bid. :*:SVRBBS:*:*:*:Subscribed : =0 ~:subject:1: ~/nos/public/subfiles This takes any messages from SVRBBS that have a subject in the form of "Subscribed filename" (probably coming from a TNOS REQSVR), and places them in the directory /nos/public/subfiles. The name is taken out of the subject line, by skipping the first word of the subject. :*:*:all:usa:*:*: =0 This is an effective bitbucket of all messages addressed to "all@usa". No file is saved, and the smtp server is told to ignore it. ----------------------------------------------------------- Date: Sun, 29 Jan 1995 16:37:18 +0000 From: "Brian A. Lantz" To: TNOS Topics Mailing List Subject: Sharing some changes..... On Sun, 29 Jan 1995, Matthias Wermann wrote: > Another thing that I noticed is that some commands (ip hport, ax hport and > ax bcport (if I found all)) only work as a toggle. That means two times > 'ax hport portname off' switches 'on' again. I remember it was an old JNOS > bug. Maybe, if you find the time, you can clean it up. It might be > confusing some other users since some commands accepts on/off. Well, this was not a bug, but a design decision. After getting your message, I've re-thought the matter, and decided to change it. Now: ip hport iface [on | off] ip hport all This goes for all of these type commands. If you leave off the "on | off" from the first syntax, then it toggles. > BTW, I did play with TScript. I really like it.. and users too! I'm using > it with with self-defined commands, e.g. to access the callsign database > on another host. What would you think about adding commands from > usercmd.hlp to the BBS prompt? Funny you should ask, but earlier today I added a "mbox prompt string" command, to allow easy customization of the prompt string. > Also to make them directly executable > (without 'cmd cmdname') would be nice. But thats only an idea, it's really > not needed at the moment ;-). I've been considering a "mbox cmd cmdname cmdline" addition, to allow customized commands. ----------------------------------------------------------- Date: Sun, 29 Jan 1995 21:14:46 +0000 From: "Brian A. Lantz" To: TNOS Topics Mailing List Subject: Re: Sharing some changes..... On Sun, 29 Jan 1995, Brian A. Lantz wrote: > On Sun, 29 Jan 1995, Matthias Wermann wrote: > > > Also to make them directly executable > > (without 'cmd cmdname') would be nice. But thats only an idea, it's really > > not needed at the moment ;-). > > I've been considering a "mbox cmd cmdname cmdline" addition, to allow > customized commands. Well, it was a quick hack, so I did it while it was again on my mind. The syntax is as shown above. The only note is that the "cmdline" must be enclosed in quotes, if it is more than one word. You can even use this to disable (or replace) builtin BBS commands, since it is processed before regular parsing occurs. To disable a builtin command, assign the cmdline of ";". This, along with the custom BBS prompt feature, will allow a greater deal of flexibility and customization without requiring a custom compile. ----------------------------------------------------------- Date: Sat, 4 Feb 1995 15:40:15 +0000 From: "Brian A. Lantz" To: TNOS Topics Mailing List Subject: Happy Valentine's Day, TNOS/DOS users..... Well, I bet you TNOS/DOS users didn't think you were getting any DOS-specific goodies in release 1.11, did you? Well you are getting a BIG Valentine's Day gift, release 1.11. I expect the release to occur next weekend, baring problems. Now for the BIG gift. The is a new TNOS/DOS command, "mem getumbs". This snags all availble Upper Memory Blocks, and adds them to the available memory pool. Depending on your memort manager and HIGH loaded drivers and programs, this can easily be greater than 100K! In addition to the "mem getumbs" command, there is a new command line parameter, "-u", which snags the UMBs before any of the startup code allocates memory. As an example of what a BIG boost this can be, I took my 'ole DOS startup and removed things like the loading of the mouse driver, CD drivers, etc. to make as much UMB memory available as I could (without this, there was almost NONE, since I loaded a bunch of stuff when I USED to use DOS). The memory manager is QEMM. My startup batch file runs QEMM's vidram command, to make the system THINK it was running on a CGA machine, instead of a VGA machine, and gives DOS this memory. With this setup, I had 99056 bytes of usable UMB memory (I don't snag any blocks with less than 1K, BTW). The initial test ran the normal setup and had: HEAPSIZE 53344 AVAILABLE 8096 CORELEFT 151568 after running 'mem getumbs' HEAPSIZE 152400 AVAILABLE 107040 CORELEFT 151568 Not bad, huh! It gets better..... Then I changed my autoexec.bat file to do a 'mem getumbs' at the beginning: HEAPSIZE 123600 AVAILABLE 78208 CORELEFT 180368 And while that was BETTER STILL, I wasn't satisfied, and added the '-u' commandline option. Then I removed the 'mem getumbs' in the autoexec.nos file, and modified the startup batch file to use the new 'u' option: HEAPSIZE 99680 AVAILABLE 54432 CORELEFT 204288 Now, this NEW beta exe is going to the remote TNOS/DOS site I maintain for a real world test, but I don't expect any problems at this point. I suggest as soon as release 1.11 comes out for all TNOS/DOS users to upgrade, if for other reason than this. Even with EMM386, there SHOULD be a big difference. If you are not using QEMM, it might be a good time, too, to REALLY maximize your setup. ----------------------------------------------------------- Date: Sun, 5 Feb 1995 00:46:44 +0000 From: "Brian A. Lantz" To: TNOS Topics Mailing List Subject: UMB follow-up.... The remote system is running with UMB's, and I thought it might be wise to share a few tid-bits, before they depart from this tired mind... First, I have discovered that SOMETIMES when running from a startup batch file, the "-u" doesn't seem to work. Also when running from a batch file, sometimes it takes TWO 'mem getumbs's; the first doesn't do it. Also, for QEMM users, you MUST have a 'lastdrive' command in your config.sys. If you don't, then UMB's seem to be messed up. This is from 7.01. I have not yet tested this on 7.50. Those caviats aside, it works well there, too: BEFORE HEAPSIZE: 71728 AVAILABLE: 14512 CORELEFT: 100864 AFTER HEAPSIZE: 132096 AVAILABLE: 75024 CORELEFT: 143296 Net usable memory gain: 102800 As always, your mileage will vary.... ----------------------------------------------------------- Date: Sun, 5 Feb 1995 23:39:05 +0000 From: "Brian A. Lantz" To: TNOS Topics Mailing List Subject: Stability under DOS.... WELL, that's a big contradiction in terms, huh! The UMB code, while it SEEMED to work, had two BIG problems. Without boring/exciting you with the bloody, grimy, nasty, brutal details (yes, I spent most of the weekend on this), the biggest problem was that some of the Borland library routines BARFED if they got a UMB address. After several approaches (read, 'dead ends'), I finally decided to wrap the original malloc routine inside a wrapper, making all library routine set a "no UMB" flag before calling the original malloc routine. All TNOS routines call the 'okay for UMB' version. The memory allocation code had to be modified to still allow conventional memory to be released back to core when done. While a 'diff' probably wouldn't show much change, just about every piece was tweeked with. I still might come back to here. Net effect, I THINK it's stable, again. I'll put this version on the test machine tomorrow morning. I looked in the dictionary under 'instable', and it said, "see DOS". In looking up 'DOS' I thought it said, "see instable". Or was I looking up 'DOS-users' ;-) I remembered vividly this weekend why I switched to Linux ;-) ----------------------------------------------------------- Date: Mon, 6 Feb 1995 00:36:19 +0000 From: "Brian A. Lantz" To: TNOS Topics Mailing List Subject: Some of the bug fixes.... To help me remember, I'll share.... Mat (dl1bjl@db0fho.ampr.org) contributed several bug reports and a fix or two. Thanks to Mat: > I just found > a way to crash TNOS from the console. If I type 'sp 144 db0ndr db0fho-3' > whre the iface 144 does not exist (it's 'ax0 here, but I used '144' with > my JNOS-system :), TNOS crashes. Seems it happens only if ax25 digipeating > is used and the iface does not exist. The problem does not exist when > doing the same from the mbox. Maybe it's of some interest, but it's not > really a problem with me ;-). fixed... > Now some days are gone and I getting more familiar with the features of TNOS. > I've seen problems when dead FTP-sessions did expire. The problem seems to be > in ftpserv.c in recvit(): fixed... > One of my users reported that the 'SR #' command did reply with > 'Invalid message number %d'. While looking into the code I found the > following in bmutil.c, mbx_reply(): fixed.... > I tried to deny a specific host to get to my gateway. I've done: > > tcp access deny hostname > tcp access permit all > > in the hope that things are ok. Result was that all hosts were denied. So > I looked into tcpcmd.c, tcp_check(). this one has led to the discovery that GCC has a bug. The code for '<<' and '>>' doesn't work properly if given a variable for the shift amount that equals 32. Workarounds are being done.... Assorted: A reminder for the Linux users, that directory names to be accessed from the bbs must be in all lower, since the mbox commandline is converted to lower case. The was a bug, for Linux users, that kept the areas from displaying proper data with the 'AS', and 'AN' commands. This was case related, also, and is fixed. Someone asked me (and I gave a partially wrong answer) if a config file could be auto-read for filename differences without a command line parameter. Yes, it can. Under DOS, the file should be named, 'config.nos' in the current directory. Under Linux, the file should be named, '.nosrc', also in the current directory. There was one ARP bug that didn't get found till after 1.10. It was minor. There were a few forwarding bugs I announced right after 1.10. I have also found cases in the code where attempted forwarding sessions lingered, that has been fixed. The sub-channels code was tweeked. There is still one "opportunity" here, in that if there is more than one in a subchannel with traffic, and the first one is unavailable, when it finishes, it starts at the top again, and tries the SAME station again. This one MAY be fixed before 1.11 releases... 1.11 defines a public directory, overridable by the cfg file, of /public. All Conference Bridge net control log files are prepended with this directory string. MANY, MANY, MANY, MANY clean-ups. Thanks to all for input. Now compiles cleanly under both DOS and Linux. I think Linux has 2 warnings about defines in the system headers (I'm not touching ;-). The DOS stuff (I think) is warning free, and most config.h features can be turned off without errors. ----------------------------------------------------------- Date: Sat, 11 Feb 1995 10:30:54 +0000 From: "Brian A. Lantz" To: TNOS Topics Mailing List Subject: Another long-time bug squashed! Some of you have HEARD of others having this problem, and maybe you had it yourself. A beta-tester here had it, and I decided to KILL it for good. The problem: An email message is entered for a local address, but it NEVER gets out of the smtp queue. The message gets processed, and placed back in the queue. The leading headers get added each pass, and eventually some have crashed when hard disk space got totally consumed. The cause: An entry in the alias file like: joe joe@blow.ampr.org If the system IS blow.ampr.org, then this is the problem. You see, the alias expansion is LATER than the rewrite processing, which usually would have an extry like: *@blow.ampr.org $1 r So, the message gets processed, determined that it is for 'blow.ampr.org' and placed BACK into the queue, reprocessed, etc.... The fix: is complete in release 1.11. No longer will this one crop up. Now there is conditional code that looks to see if it is "*@hostname", and if so, truncates the '@hostname' off. ----------------------------------------------------------- Date: Sat, 11 Feb 1995 21:35:36 +0000 From: "Brian A. Lantz" To: TNOS Topics Mailing List Subject: TCPGATE makes it into release 1.11 The source of this: On Fri, 10 Feb 1995, Matthias Wermann wrote: > - while playing with Wampes I found a nice function. It's the TCPGATE. > This is useful for gatewaying incoming TCP's on specified ports to other > hosts/ports or the unix-kernel. E.g.: > > start tcpgate 3600 unix:/tcp/sockets/convers # tcpgate to pp-conversd > start tcpgate smtp 44.130.12.26:25 # tcpgate to db0fho:smtp > start tcpgate nntp # tcpgate to unix's nntpd > > I'd really like to see it in TNOS too (if you Brian think it's useful ;-). > This feature allows to 'delegate' incoming TCP's to other hosts, e.g. > since TNOS/Linux has no built in NNTP server it could at least let do > the dirty work another host, even if the users do the NNTP-polling on TNOS. > Same on conversd. Since I'm able to run PP-conversd on Linux, I do not > need TNOS's conversd (but TNOS's conversd is nice too!). > Why not letting TNOS's port 3600 connects go through TCPGATE to the > Linux's PP-conversd? Well, I had been wanting to add something like this for a LONG time, but hadn't taken the time to figure out how I wanted to make the syntax to do it. Since the Wampes TCPGATE syntax seemed reasonable, I have used it, for the most part. The code for TCPGATE (rapidly submitted my Mat) wasn't much help, since Wampes is FAR more tightly integrated with UNIX then TNOS/Linux. But the TNOS TCPGATE code should work on any platform xNOS. The syntax is: start tcpgate port hostname:port The hostname:port is NOT optional. In the wampes version, this had defaults that probably make sense there. Unlike Wampes, you can STOP TCPGATE with: stop tcpgate port Works like a champ, both to the Linux side of the same CPU, or to a remote xNOS box over RF. Thanks, Mat, for pointing me to an easy syntax for a neat goodie! ----------------------------------------------------------- Date: Sat, 18 Feb 1995 13:35:46 +0000 From: "Brian A. Lantz" To: TNOS Topics Mailing List Subject: More into release 1.11 Someone asked (can't remember who) earlier about the ability to turn on/off mbx access on a port-by-port basis, saying that it was in JNOS. Looking it over, I must have snagged most of the code for that and sucked it into TNOS when I grabbed a little of the JNOS/Linux code. All that was needed was command session commands to change them. Since JNOS users were already used to certain command names, I used the same names. There are now the following new commands, also coming out in v1.11: mbox noax25 iface # sets/clears flag to deny incoming connects # default is cleared (access allowed) mbox bbsonly iface # sets/clears flag to allow only users # that have the BBS permission into the mbox # defaults to off (not bbs-only) mbox usersonly iface # sets/clears flag to allow only users # that do not have the BBS permission into # the mbox. defaults to off (not user-only) mbox sysoponly iface # sets/clears flag to allow only users # that have the SYSOP permission into the mbox # defaults to off (not sysop-only) These last minute additions got added only because most of the code was already done, and the remaining code took seconds to do. ----------------------------------------------------------- Date: Sun, 19 Feb 1995 18:37:09 +0000 From: "Brian A. Lantz" To: TNOS Topics Mailing List Cc: "Dugal James P." Subject: Also added in release 1.11 On Sun, 12 Feb 1995, Dugal James P. wrote: Thanks to James for accidentally reminding me that I needed to add some finger aliases that had been added into JNOS. > Steve, the finger help file (in cmdshlp1.zip) describes some (all?) > possibilities: > > Certain strings are taken to mean that a Jnos function > should be invoked to display system information, depending on > what configuration options were used to build the server Jnos: > > config_opt output > > conf CONVERS conference bridge /WHO > links CONVERS conference bridge /LINKS > mstat MAILBOX 'mbox mailstat' > mpast MAILBOX 'mbox past' > users MAILBOX 'mbox status' > mailfor MAILFOR 'mbox mailfor' > info ALLCMD 'info' > ax25 AX25 'ax25 stat' > aheard AX25 'ax25 heard' > netrom NETROM 'netrom stat' > iheard all 'ip heard' > memstat all 'mem stat' > socket all 'socket' > tcpview all 'tcp view bytes' > asystat ASY 'asystat' > ripstat RIP 'rip stat' > In doing this, I made it an easy to maintain table (if it is still "if's" in the JNOS source, let me know James, and I'll send a care package;-) In addition to these, in TNOS 1.11, there are: info ALLCMD 'version' (TNOS equiv) version ALLCMD 'version' bbs MAILBOX 'mbox status' and 'mbox mailst' ports all BBS 'ports' stat MAILBOX/CONVERS same as combined 'bbs' and 'conf' Also, if you 'finger @bbs', it will give a better listing of the available ones of these 'special' finger usernames. ----------------------------------------------------------- Date: Sun, 19 Feb 1995 23:33:59 +0000 From: "Brian A. Lantz" To: TNOS Topics Mailing List Subject: More last minute additions.... MORE FOR FINGER: To complete the finger special usernames, there is one more: nodes all 'netrom route' TSCRIPT ADDITION: Also, a requested addition from Ron/n8fow made it in. There is an extension to the TScript language to allow sending mail with a "Reply-to:' RFC 822 header line in the message. ~dr replyto user file delivers (mails) to 'user'. The subject of the message will be the title line of the current script. The message is sent from the MAILER-DAEMON. There is a 'Reply-to:' field added to the message, with 'replyto' as the recepient. The content of the mail message will be the contents of the 'file'. The query status is set to 'y' if the message was successfully queued. The TScript documentation on my WWW pages (http://www.lantz.com) have been updated to reflect this change. WWW PAGES CHANGED: And I have made a few minor changes to the WWW pages, providing info about ko4ks.ampr.org as well as TNOS. Any comments are welcome. FTP CHANGES: Also, some much requested changes to the FTP server. First, the directories reported look like UNIX, that is, a 'cd /' does a cd to the first directory in the ftpuser path, and says, "I'm in '/'". Second, you can now do a "cd ../path". Before you could to a "cd ..", but not a "cd ../anything". Third, the FTP verbose output of a directory LOOKS like a UNIX output, so brain-dead programs that ASSUME a certain output will get it. The only permissions that can be set with MSDOS are the reads and the directory, so the writes and the executes are ALWAYS set. The owner and group are always listed as 'tnos' for MSDOS. I've got to take a few minutes tomorrow and make the UNIX version more complete with permissions and owner/group info than the MSDOS version. Anyone who wants to check the FTP out from Mosaic, etc., try ko4ks.ampr.org. ----------------------------------------------------------- Date: Thu, 23 Feb 1995 08:15:51 +0000 From: "Brian A. Lantz" To: TNOS Topics Mailing List Subject: Ethernet packet driver problem found Thanks to Dave, we have found the problem with packet drivers, and a fix is being tested. It will be fine in 1.11 ----------------------------------------------------------- Date: Sun, 26 Feb 1995 12:32:34 +0000 From: "Brian A. Lantz" To: TNOS Topics Mailing List Subject: Callbook client code.... In getting the callbook client code tested for use with TNOS/Linux, I found and corrected a few buglets, and added a missing error message. Support for callbook clients will be included in the TNOS/Linux distribution exe for 1.11 -----------------------------------------------------------