Date: Tue, 5 Jan 93 04:30:13 PST From: Advanced Amateur Radio Networking Group <tcp-group@ucsd.edu> Errors-To: TCP-Group-Errors@UCSD.Edu Reply-To: TCP-Group@UCSD.Edu Precedence: Bulk Subject: TCP-Group Digest V93 #5 To: tcp-group-digest TCP-Group Digest Tue, 5 Jan 93 Volume 93 : Issue 5 Today's Topics: Digests??? (3 msgs) Duplicate messages destroyed GMAIL?? Leave it on Linux 0.99 kernel TCP (2 msgs) MX records (again) New version of NOS! NOS BBS (2 msgs) NOS on Internet? packet driver for parallel port? (5 msgs) Perl interface to Packet BBS.. Problem with personal messages STATUS command and BBS lockup Send Replies or notes for publication to: <TCP-Group@UCSD.Edu>. Subscription requests to <TCP-Group-REQUEST@UCSD.Edu>. Problems you can't solve otherwise to brian@ucsd.edu. Archives of past issues of the TCP-Group Digest are available (by FTP only) from UCSD.Edu in directory "mailarchives". We trust that readers are intelligent enough to realize that all text herein consists of personal comments and does not represent the official policies or positions of any party. Your mileage may vary. So there. ---------------------------------------------------------------------- Date: Mon, 4 Jan 93 12:19:04 EST From: crompton@NADC.NADC.NAVY.MIL (D. Crompton) Subject: Digests??? To: tcp-group@ucsd.edu I get the full TCP group here at my internet address but on the local AMPR I get the digest from a neighboring group which I then offer NNTP locally. Question that I have - is the digest edited?? If so why do subscribe and mail failure messages appear in it? One recent digest had 4 messages, 3 of which were mail failure messages from hp.com. The message descriptions even listed this. Doug ------------------------------ Date: Mon, 4 Jan 93 22:52:07 EST From: crompton@NADC.NADC.NAVY.MIL (D. Crompton) Subject: Digests??? To: bruce@pixar.com Ok well if it is automatic it possibly could be smart enough to reject messages from 'postmaster' etc. I though a women out at ucsd was taking care of the digest?? No one cares about BW on the internet but when you have a 15K message being sent all over AMPR with about 1K meaningful it makes sense to do some editing. The banner could probably be reduced in size considerably and still convey the message. Doug ------------------------------ Date: Mon, 4 Jan 1993 21:04:10 -0800 (PST) From: Bruce Perens <bruce@pixar.com> Subject: Digests??? To: "D. Crompton" <crompton@NADC.NADC.NAVY.MIL> Well, Brian would know for sure who/what is processing the digest at UCSD. Maybe he could handle a volunteer for "moderator". Anyone with internet access could do it, and with the signal to noise increase as TCP gets actual users, we're starting to need one. Bruce On Mon, 4 Jan 1993, D. Crompton wrote: > Ok well if it is automatic it possibly could be smart enough to reject > messages from 'postmaster' etc. > > I though a women out at ucsd was taking care of the digest?? > > No one cares about BW on the internet but when you have a 15K message > being sent all over AMPR with about 1K meaningful it makes sense to do > some editing. The banner could probably be reduced in size considerably > and still convey the message. > > Doug ------------------------------ Date: Mon, 4 Jan 93 14:29:18 PST From: "Roy Engehausen" <enge@almaden.ibm.com> Subject: Duplicate messages destroyed To: TCP-GROUP@UCSD.EDU Since each message you are sending to the BBS is addressed to a different user, it must carry a different MID. The purpose of the MID is to eliminate duplicate messages and anything with the same MID (even if addressed differently) is considered a duplicate. Roy, AA4RE ------------------------------ Date: Mon, 4 Jan 93 08:58:33 CST From: anderson@cat.ATK.COM (Dean S. Anderson) Subject: GMAIL?? To: crompton@NADC.NAVY.MIL, tcp-group@ucsd.edu Sorry I am taking so long, my life has been very complicated the last several months. I will bring in the current version which has improvements over the last release, but is not yet 'feature complete'. I will make an announcement when I have uploaded to ucsd. 73 de Dean Anderson (ka0mcm) anderson@cat.atk.com ------------------------------ Date: Mon, 4 Jan 93 09:56:12 EST From: kz1f@RELAY.WESTBORO.LEGENT.COM Subject: Leave it on To: tcp-group@ucsd.edu Having been out the last several days, I am perhaps late in my 2(they took away the cents key!) $0.02. One item I think was left out was the notion of power spikes at startup. Not being an EE I cannot quantify this, at this time, but certainly when a motor start the power consumption is highest due to overcoming the coeffecient of starting friction. Whatever the power drain is nominally, at startup there is an instantanious surge of perhaps 10x draw. IMHO, this not only adversely affects the life of the mechanical parts but the line spike can do no good to the other electronic systems. For atleast those reasons I tend to keep my systems on full time. Walt ------------------------------ Date: Mon, 4 Jan 1993 09:17:41 -0800 (PST) From: Bruce Perens <bruce@pixar.com> Subject: Linux 0.99 kernel TCP To: tcp-group@ucsd.edu Linux 0.99.2 has kernel TCP/IP and NFS, and an Ethernet interface, and runs quite respectably on an old 386 system I cobbled together from spare parts. A kernel AX.25 implementation would be a good idea, and there are free versions of most of the clients and servers we'd need in BSD. Is anyone working on this, or is anyone interested? I've been hacking Unix kernels for about 11 years, and could help. Thanks Bruce Perens ------------------------------ Date: Tue, 5 Jan 1993 00:13:04 -0500 From: chk@alias.com (C. Harald Koch) Subject: Linux 0.99 kernel TCP To: bruce@pixar.com (Bruce Perens) > Linux 0.99.2 has kernel TCP/IP and NFS, and an Ethernet interface, and > runs quite respectably on an old 386 system I cobbled together from spare > parts. A kernel AX.25 implementation would be a good idea, and there are > free versions of most of the clients and servers we'd need in BSD. > Is anyone working on this, or is anyone interested? I've been hacking > Unix kernels for about 11 years, and could help. Somebody (Brian Kantor?) has been hacking AX25 into BSD386 (or is it 386/BSD? I'm so confused). He's said that it's painful. I suggest that the easiest way to di this is run a NOS port as a user process, and have it communicate with the kernel through a SLIP link running over a PTY. I do this on an SGI system, and it works great. I got the idea originally from the wampes people, to give credit where credit is due... -- Main's Law: For every | C. Harald Koch Alias Research, Inc. Toronto, ON action, there is an equal | chk@alias.com (work-related mail) and opposite goverment | chk@gpu.utcs.utoronto.ca (permanent address) program. | VE3TLA@VE3OY.#SCON.ON.CA.NA (AMPRNet) ------------------------------ Date: Mon, 04 Jan 1993 11:26:30 PST From: "Jeffrey D. Angus" <jangus@skyld.tele.com> Subject: MX records (again) To: tcp-digest@ucsd.edu On Mon, 4 Jan 93 04:06:06 EST, "Mike Bilow" <MIKEBW@ids.net> contends: > I contend that there are good reasons for my position. The proper meaning > of the smtp gateway is that it is a system which is to be sent mail for > hosts which are not known. Mail addressed to a known thing which is not > a host should be handled differently than mail for a completely unknown > thing. For example, let's say I get a piece of mail with an RFC-822 > address of "ka1az@ka1az". My system will append my current domain suffix > and try to resolve "ka1az.ampr.org" as a hostname, finding 44.104.0.36. > But it so happens that KA1AZ.#SORI.RI.USA.NOAM is a known mail receiver > (PBBS) which is not a host. The smtp gateway kludge will prevent mail > from being addressed to users at the KA1AZ BBS, since the kludge depends > on the BBS name being unresolvable as a hostname. And I repeat, 44.x.y.z is the ampr.org domain. You're either an operable .ampr.org host (a system using tcp protocols) or you're not. If not, then you're not in the domain.txt. Mail eXchange records are used to point to an alternative host in the event that the given host is not available. The domain suffix command assumes that all hosts share the same domain. If we are only sending mail to operable .ampr.org hosts this is fine. This is not the case when mail is sent to addresses like k6ve@k6ve.#soca.ca or even lhurder@arrl.org. Neither host (k6ve.#soca.ca or arrl.org) is going to be in the domain.txt. The station that has to deal with this mail has two choices, either process it, or refuse it. The command smtp gateway defines the host that knows what to do with otherwise undeliverable mail. The mechanisms used to handle "special" mail are; alias, rewrite and forward.bbs. Alias handles smtp mail that should be sent to another .ampr.org host or hosts. Rewrite deals with pattern matching in the address field and can deliver mail locally or requeue it. Forward.bbs then deals with mail that is stored (delivered) locally and delivers it to non-smtp mail hosts. In both alias and rewrite, the actual To: line in the RFC-822 header remains unchanged. What to do with the example, ka1az being both an ampr.org host and an ax.25 BBS. User education. I have informed my users that mail will not go where they want it to if the do not add the #soca designator to several local callsigns. What if you have someone who insists on having all 200+ Kbytes of the 44.x.y.z domain listed as your domain.server. User education again. Tell them that they have to fully qualify name the target host. Appending things to the host name. For example, I remember back when pe1chl was the ax.25 forwarding code to run, ax.25_callsign with the ".bbs" extension listed as the forwarding bbs mail host. For example: w0rli%w0rli.or%k6ve.bbs@wa6fwi.ampr.org And then mail queued up for host k6ve.bbs would be dealt with in the ax25 mail forwarding routine. This was prior to the domain suffix command and things had to be spelled out or the hosts.net table had multiple entries. (Equivalent to CNAME) With the domain suffix command in use, this now creates a subdomain bbs.ampr.org. There has also been a recent comment of appending .ax25 to the callsign, this would result in the same possible conflict. The "s" in smtp means simple. External mail handlers like view, pc-elm and bm all share one common traight. They are designed to work within a single type of mail delivery system. (I know pc-elm works with UUCP as well, but you can not cross over mail for forwarding.) Because of this "feature", "special" mail has to be dealt with through a variety of means. Rewrite and forward.bbs being the ones that were designed into the current code to accomplish this. The bottom line is that until someone ports something like SMAIL over to the amateur smtp mail arena (and makes a manual usable by typical HAMS) all "special" mail going to something other than another .ampr.org host is going to be a hack. 73, Jeff wa6fwi@wa6fwi.#soca.ca.usa.na (for ax25 packet BBS mail) -- netcom!bongo!jangus@skyld.tele.com < the winter solstice is here > US Mail: PO Box 4425 Carson, CA 90749-4425 1 (310) 324-6080 ------------------------------ Date: Tue, 5 Jan 93 02:14:30 -0800 From: Phil Karn <karn@unix.ka9q.ampr.org> Subject: New version of NOS! To: tcp-group@ucsd.edu Hello all, I have uploaded, for the first time in six months, a new version of my "base" NOS code to ucsd.edu. It's in /hamradio/packet/tcpip/ka9q. The files are as follows: rcspub.zip - ZIP archive of source tree in RCS format s930104.zip - ZIP archive of latest versions of sources extracted from RCS for those without RCS (you'll probably have to hack the makefile to remove references to the RCS files) net.386 - executable compiled for 386/486 only I will shortly generate and upload a net.exe that runs on 286 systems. It's been so long I'm sure I can't sit here and produce from memory a complete list of the changes and fixes. However, I have been using RCS quite religiously so anyone who is interested in the gritty details can dump the RCS comments for each source file. Here are the highlights: 1. To make the /ftpusers file a little less sensitive, user passwords are now kept encrypted with a one-way cryptographic hash function (RSADSI's MD-5). The input to the hash function is the user's name immediately followed by the password, without a terminating newline. The 16-byte hash values are stored in hex. At startup, NOS scans /ftpusers and automatically hashes any cleartext passwords it finds. (Passwords starting with * are left unchanged, as are comment lines, blank lines, etc). You can still edit the file normally, as when adding new users or changing privileges. To change someone's password, simply replace the 32 hex characters with the new plaintext password, and NOS will automatically hash it to hex the next time you run it. NOTE! IF YOU WANT TO BE ABLE TO RUN EARLIER/OTHER VERSIONS OF NOS AFTER YOU RUN THIS ONE, FIRST MAKE A COPY OF YOUR /FTPUSERS FILE. ONCE THE PASSWORDS HAVE BEEN HASHED, THERE'S NO WAY TO TURN THEM BACK INTO PLAINTEXT. That's the idea behind hashing -- if somebody steals your /ftpusers file, it's impossible to determine the password that hashes to the value in a user's entry short of trying all possible passwords until one matches. And if the password is long and/or random enough, this is infeasible. 2. I've found another good use for the MD-5 hash function. The FTP server now supports the experimental XMD5 command. It takes a file name as an argument and returns the 16-byte MD5 hash value for that file in hex. The client uses XMD5 to support several nifty new features: the "compare" and "mcompare" commands, and the "update" flag. The "compare" command takes a pair of file names, one local and one remote, and computes and compares their MD5 hash values. On a slow network, this is *much* faster than actually retrieving the remote file and comparing it to the local one. The "mcompare" command does the same thing for a list of files, where the comparisons are between files with the same names on each end. The "update" flag, when set (default is off), modifies the behavior of the mput and mget commands. When update is set and you do a mput or mget, the client automatically compares the hash codes for each each pair of files and skips the transfer if they're the same. The MD-5 hash function can be thought of as a *very* strong CRC; the chances of two different files having the same hash code is thought to be astronomically small. I find the update feature particularly useful for maintaining parallel copies of NOS source code on my machines at work and at home. Even though my SLIP link is relatively fast, it's still pretty slow if I have to copy everything each time, whether or not it has really changed. 3. The terminal emulator now supports a status line. It displays as white on blue on a color display (yes, *color* in NOS!!) and in inverse video on a monochrome display. The status line always shows the session number and the command that invoked the session. If there are unacked characters (TCP) or packets (AX25) on the current connection, this is shown in an Unacked: field. Otherwise the field is blanked. And if the screen is scrolled back (yes, there's now a SCROLLBACK feature!) the number of lines scrolled back is shown. At the moment the same spot on the line is used for the Unack: and Scroll: fields, so only one can appear at a time. (I was concerned about there being enough room for the session command string.) There's also a rudimentary help field in the status line. Right now it just says "F8:nxt F10:cmd", i.e., hit F8 to cycle to the next session, F10 to go to the command session. I may replace this with a simple "Fn:help" and implement a general help facility. Haven't decided yet. To make room for the status line, the active window area is now 24 lines long. The "ansi" entry in /etc/termcap seems to work well. Don't use the "nansi" entry since it assumes 25 lines. 4. As I just mentioned, there's now a scrollback feature. Lines that scroll off the top of the screen are kept in a temporary file, with a default maximum of 1000 lines. (This can be changed with the "scrollback" command, although only before a session is started). The usual keys work in the usual way (home/end/page up/page down/cursor up/cursor down). If your machine doesn't have a fast disk, or if you don't have the space, you can set the scrollback parameter to zero and disable it entirely. Comments are invited on the behavior of the scrollback feature. For example, when a screen clear sequence is sent, should the screen be written into the scrollback file? I don't do this right now, although I could make it an option. I'm also thinking of implementing a key that would toggle the scrollback feature on and off so you could instead have the cursor control keys send ANSI escape sequences (handy when remotely editing with EMACS and vi). 5. The code compiles and runs successfully with the -3 option to Borland C++ 3.1. This took some rewriting of the assembler files to save 32 bit registers properly during interrupts. The -3 option shrunk the resulting net.exe file by 25K bytes. Not bad. Note: if you select the C compiler flags in the makefile that specify -3, you MUST also select the corresponding assembler flags. Otherwise the resulting code *will* quickly crash. 6. The various commands that used to create separate sessions for viewing (FTP dir and read, local dir, etc) no longer do so now that there's scrollback on the command session as well. However, there's a "page" command prefix that still creates a temporary file with the output of a command and then creates a session to view it. You can use "page" as a prefix to any non-interactive command that generates output, e.g., "page dir" or "page ps". While in a page session, the PC's cursor control keys work in the usual fashion. Hit 'q' or ^C to kill the session. 7. There's also a "repeat" command that works something like "page", except that it repeatedly executes the command at a specified rate. E.g., "repeat 1000 tcp stat" will create a session with the output of the "tcp stat" command repeatedly executed every 1000 milliseconds, so you can watch things changing in real time. Again, you can kill a session with ^C. 8. The long form of the "tcp stat" command (invoked on a particular TCB, or through the "socket" command) gives more information than before. It's something to watch, especially when you prefix it with "repeat", if you really want to see how TCP is behaving in real time. It can be quite educational. If you set the "verbosity" level in an FTP session to 4, it will automatically bring up a repeating TCP status display for each transfer. 9. The SLIP auto dialer now takes three script files, one for bringing up a call, a second for dropping it, and a third for answering a call. The latter is invoked by the RI lead from the modem. I found this handy to let me share a single phone line between autodial SLIP and my fax machine, which has an auto voice/fax switchover feature. (Details on request.) Well, have at it, and have fun. Phil ------------------------------ Date: Mon, 4 Jan 93 14:22:08 EST From: crompton@NADC.NADC.NAVY.MIL (D. Crompton) Subject: NOS BBS To: tcp-group@ucsd.edu Over the weekend I tried some things in the BBS code. I had mentioned that the BBS does not append any domain if one is not given, unlike when an external mailer is used. So .ampr.org stuff must be fully qualified in the send command. I modified the mbx_to routine to call domainsuffix. This works but still not exactly the way I would want. This is what seems to happen - if I send mail to wa3dsp@wa3dsp, it becomes wa3dsp@wa3dsp.ampr.org then it gets sent to rewrite. If rewrite has a specific entry for the wa3dsp@wa3dsp combination then it is rewritten to that address, otherwise it picks up on my *.ampr.org and sends it to the domain lookup. If domain lookup fails it finally gets sent to wa3dsp.txt in my /spool/mail. What I would really like to happen is this - assume .ampr.org - check rewrite for match OTHER than .ampr.org - otherwise send to domain lookup x.ampr.org - otherwise send to CHECK. It is the last requirement that is a problem. The rewrite file would need to be rescanned with the .ampr.org removed AFTER domain failed. This could be done because the domain lookup returns an error code LOCAL, DOMAIN, BAD - which could be checked to determine if the rewrite would have to be rescanned. Isn't anyone else having this problem - that is users sending mail in the BBS and failing to append .ampr.org for TCP stations. Maybe someone else has a better way to solve this. Using the normal code (without the mod I mentioned above) I can add (after all other checks) a line in rewrite to append .ampr.org - *@* $1.$2.ampr.org and again it will try a domain lookup and if it fails send the mail to $1.txt on my system - and where I really want it to go is some common error mailbox, like CHECK. Doug ------------------------------ Date: Mon, 4 Jan 93 22:45:46 EST From: crompton@NADC.NADC.NAVY.MIL (D. Crompton) Subject: NOS BBS To: tony@mpg.phys.hawaii.edu Tony, That makes sense but if I do not have the gateway to myself it breaks all kinds of other things - like being able to send mail to w3eee@w3ddd.bbs This would have no domain entry but would have a rewrite entry - But the external mailer - BM/VIEW etc does NOT get scanned by rewrite unless the gateway is set to yourself. Seems like you are damned if youdo damned if you don't!! It is obvious to me now that I can't get where I want to go without some code changes. Doug ------------------------------ Date: 04 Jan 1993 16:20:43 -0500 (EST) From: Dave Goodwin <GOODWIN@SMCVAX.SMCVT.EDU> Subject: NOS on Internet? To: tcp-group@ucsd.edu I hope someone can point me in the right direction with this. I have JNOS v1.07 running on a DEC 486SX with a DEPCA ethernet card in it. I also will have a TNC on the COM1 port, the intention being to setup an Internet link to my home PC. For now, however, I'm just trying to get the ethernet side going, but I have a few difficulties. Let me start by describing our configuration. We have a campus wide ethernet, with our main VAX running Multinet TCP/IP. The Internet comes in through a Cisco router which also sits on the backbone and serves as our Internet gateway. We are on the NEARNET New England network, and they provide DNS service for us, with the VAX maintaining only a small cache of resolved names. My PC is attached to this same ethernet. I've configured NOS as best I'm able, and it is quite happy talking to other systems on the local campus network. I can TELNET, FTP, etc. in both directions with no problem. I can TELNET and FTP outward for those systems whose names are resident in the VAX cache. Other systems hang, however. I thought I had configured the domain server part of NOS correctly, as entries for some of the hung nodes do appear in domain.txt after a lookup. What I'd like to hear from anyone who's doing this successfully is what other steps I might need to take. I added our vax and NS.NIC.DDN.MIL as nameservers, set the default route to the ethernet, both with and without the gateway attribute. When used, the gateway attribute was set to the router's IP address. Domain service is started, translate is on. Any clues would be most appreciated. Thanks in advance... Dave Goodwin@smcvax.smcvt.edu =========================================================================== Dave Goodwin | Assistant Director, Academic Computing | We're all kinds of animals -----------------------------------------------| coming here. BitNet : Goodwin@SMCVAX | Ma Bell : (802)654-2220 | Occasional Demons, too. US Mail : Saint Michael's College | Winooski Park, Colchester, VT 05439 | -Jethro Tull Ham Radio: N1HRO @ W1KOO.#NWVT.VT.USA.NA | =========================================================================== ------------------------------ Date: Mon, 4 Jan 93 12:32:52 GMT From: Alan Cox <iiitac@pyr.swan.ac.uk> Subject: packet driver for parallel port? To: MIKEBW@ids.net, jmorriso@ca.ubc.ee, tcp-group@ucsd.edu I've used PARNET on a pair of Amiga's which is a sort of NFS over the parallel port. Even with just 68000 CPU's you got a good 60-100K a second over it. Alan ------------------------------ Date: Mon, 04 Jan 1993 10:07:40 EST From: "Russell Nelson" <nelson@crynwr.com> Subject: packet driver for parallel port? To: tcp-group@ucsd.edu In article <9301040737.AA20325@toaster.ee.ubc.ca> you write: > has anyone seen a packet driver for the parallel port? > (if one existed, I'm thinking of the possibility of chaining PC's > together, since parallel ports are common, and we have a scarce amount > of ethernet cards and PI cards. I guess I could just use SLIP...yuck) The 11.x packet driver collection, currently in alpha test, will have one. Features: o Uses a laplink-compatible cable. o Will only hook two machines together. o Appears to be a two-node Ethernet network. o Works on any parallel port (doesn't need EPP nor bi-directional ports). -- -russ <nelson@crynwr.com> What canst *thou* say? Crynwr Software Crynwr Software sells packet driver support. 11 Grant St. 315-268-1925 Voice | LPF member - ask me about Potsdam, NY 13676 315-268-9201 FAX | the harm software patents do. ------------------------------ Date: Mon, 4 Jan 1993 09:01:56 -0800 (PST) From: Bruce Perens <bruce@pixar.com> Subject: packet driver for parallel port? To: John Paul Morrison <jmorriso@ee.ubc.ca> The parallel-port disks and file transfer programs do not reverse the direction of the parallel port data bits. Rather, they use the status lines of the parallel port as inputs. As you mention, there are five inputs. One of them is used for synchronization, and the other four become a four-bit data nybble. Rather than fielding one interrupt per nybble, it's simple enough to take an interrupt for the first incoming nybble and transfer several more in a tight loop. You should be able to get a respectably high data transfer rate that way. Not, DMA, but it's cheap. You can probably use about a 20 foot cable run - the parallel-port drivers are single-ended, unlike RS-232, and not meant to drive long cables without RF interference and noise problems. One of the PC magazines had an article, about two months ago, on building a parallel-port transfer cable and software. That would be a good place to start. Bruce Perens, KD6OTD Bruce@Pixar.com ------------------------------ Date: Mon, 4 Jan 93 14:02:29 EST From: crompton@NADC.NADC.NAVY.MIL (D. Crompton) Subject: packet driver for parallel port? To: nelson@crynwr.com, tcp-group@ucsd.edu Russ, Is/will the new 3com etherlink III card supported? Doug ------------------------------ Date: Mon, 04 Jan 1993 15:02:26 EST From: "Russell Nelson" <nelson@crynwr.com> Subject: packet driver for parallel port? To: "D. Crompton" <crompton@NADC.NADC.NAVY.MIL> On Mon, 4 Jan 93 14:02:29 EST, "D. Crompton" <crompton@NADC.NADC.NAVY.MIL> wrote: > Is/will the new 3com etherlink III card supported? Yes. -- -russ <nelson@crynwr.com> What canst *thou* say? Crynwr Software Crynwr Software sells packet driver support. 11 Grant St. 315-268-1925 Voice | LPF member - ask me about Potsdam, NY 13676 315-268-9201 FAX | the harm software patents do. ------------------------------ Date: Mon, 4 Jan 93 12:11:43 CST From: andyw@aspen.cray.com (Andy Warner) Subject: Perl interface to Packet BBS.. To: tcp-group@ucsd.edu (TCP Group) If anyone is interested, I've written some software in Perl which will interface to the PBBS network.. It does the following :- o Provides a server that will accept incoming connections from a PBBS, it honours the SP, SB, F> & B commands, enough to accept & return mail & bulletins. Incoming mail is passed to the mail subsystem (in my case sendmail). Incoming bulletins are passed to inews. BIDs are interpreted into Message-Id: lines and various other mail/news headers are generated from the R: lines etc. BIDs are honoured, and you can configure what bulletins are sent to what bbs/news/mail destination by 3 text files. o Provides a mailer which is spools mail or bulletins for delivery to a PBBS. These will be delivered if/when the destination PBBS initialtes reverse forwarding. This mailer accepts RFC-822 compliant mail and strips the headers out. o Some housekeeping stuff to view & expire BIDs etc.. It needs the following :- o Perl running on the target system. o An ax25 <-> tcp protocol bridge, which has been written & incorporated into NOS by a local up here in the Twin Cities. o A mail subsystem that can route messages to the pbbs mailer. I use IDA-Sendmail, but I'm sure smail3 is up to the task. o inews or something equivalent to inject articles into a news system. Work I still need to do :- o Initiate outgoing connections. o Allow/disallow forwarding according to time rules. o Allow NNTP -> bulletin traffic, honouring any previously existant BID, or generating a new one. o Test it against more PBBS systems. o Document any of this. This is my first attempt at non-trivial programming in Perl, and on the whole it's been a good experience. The complete server part is only something like 800 lines. It also forced me to install IDA-Sendmail on my server, and that was a worthwhile excercise too. I can supply the modifications needed to Sendmail.mc (the sendmail.cf m4 source file) to support the pbbs mailer & associated routing. It also will map From: addresses onto callsigns when using the PBBS mailer as directed by a DBM file. It has proven quite powerful to install this on a machine that was also the smtp gateway for an area, so that mail to aa0zz@wa0abc.xyz.usa.noam is just quietly shunted off the the gateway, where it gets injected into the PBBS system.. It works well as a pseudo-BBS for TCP users in an area, allowing them to send & receive PBBS mail/bulletins using the normal tools. I'm running this under SunOS 4.1.2, so I'm afraid that in it's current state it's a Unix only hack. Anyone interested ? -- andyw. N0REN/G1XRL andyw@aspen.cray.com Andy Warner, Cray Research, Inc. (612) 683-5835 ------------------------------ Date: Mon, 4 Jan 93 12:13:38 EST From: crompton@NADC.NADC.NAVY.MIL (D. Crompton) Subject: Problem with personal messages To: nos-bbs@hydra.carleton.ca Phil, You must hav missed my earlier message in this regard. I discovered it soon after I put 1.07 on the air. I have still not gotten a definitive answer. One that i did get was that the (nos's) operation is correct. That being the case I assume the BBS must be wrong? One problem with BBS's (as opposed to TCP) is that I have never seen any written standards on how these things should work and if there is they sure don't all conform to them. This problem arrises when you try to send two (or more) identical messages to different users at the same BBS. NOS puts a MID on the first message, the BBS accepts it, then the second and later messages with the same MID are rejected, even though they are to different users. BBS's do not know how to handle this since there capability being less than nos's, you cannot send a message to more than one user at a time. So each message gets it's own MID. I suspect that Johan will look at this when he gets back. NOS may have to assign different MIDS somehow to each message, even if the content is the same as long as the addressee is different. Can anyone who knows BBS "standards" give anymore input on what should be done here - who is broken? Doug ------------------------------ Date: Mon, 4 Jan 93 12:14:59 EST From: crompton@NADC.NADC.NAVY.MIL (D. Crompton) Subject: STATUS command and BBS lockup To: nos-bbs@hydra.carleton.ca Phil, Have not seen this or heard of it here - what compiler are you using? BC2.0++ here. Doug ------------------------------ Date: Tue, 5 Jan 93 10:49:03 GMT From: Alan Cox <iiitac@pyr.swan.ac.uk> To: tcp-group@ucsd.edu Someone is doing kernel tcp/ip over ax.25 work under Linux. Last time I saw it running it was just doing ip over ax.25 UI frames and talking fine to the ka9q on my linux box. Alan ------------------------------ End of TCP-Group Digest V93 #5 ****************************** ******************************