Media Share 9/MEDIASHARE_09.ISO/hamradio/net386.zip/NET386.INF

Text File | 1993-01-07 | 34KB | 818 lines

From usenet.INS.CWRU.Edu!gatech.edu!ucsd!tcp-digest-relay  Tue Jan  5 15:37:51 1993 remote from ncoast
Received: by n8hsp.wariat.org (smail2.5.3-coh) id AA02892; 5 Jan 93 15:37:51
Received: from usenet.INS.CWRU.Edu by ncoast.org with uucp (Smail3.1.28.1 #1)
    id m0n9FL8-0000kYa; Tue, 5 Jan 93 09:33 EST
Received: from gatech.edu by usenet.INS.CWRU.Edu with SMTP (5.65b+ida+/CWRU-1.5.2-UUCPGW)
    id AA01689; Tue, 5 Jan 93 09:24:13 -0500 (from ucsd![e-mail] for n8hsp!tbell)
Received: from ucsd.UUCP by gatech.edu (4.1/Gatech-9.1)
    id AA13952 for ncoast!n8hsp![e-mail]; Tue, 5 Jan 93 09:26:36 EST
Errors-To: usenet.INS.CWRU.Edu!gatech.edu!ucsd!TCP-Group-Errors
Received: by ucsd.edu; id AA14616
    sendmail 5.67/UCSD-2.2-sun
    Tue, 5 Jan 93 04:30:21 -0800
Received: by ucsd.edu; id AA14610
    sendmail 5.67/UCSD-2.2-sun
    Tue, 5 Jan 93 04:30:17 -0800 for /usr/lib/sendmail -oc -odq -oQ/var/spool/lqueue -oi -ftcp-digest-relay tcp-digest-list
Message-Id: <[e-mail]>
Date: Tue,  5 Jan 93 04:30:13 PST
From: Advanced Amateur Radio Networking Group <ncoast!usenet.INS.CWRU.Edu!gatech.edu!ucsd!tcp-group>
Errors-To: usenet.INS.CWRU.Edu!gatech.edu!ucsd!TCP-Group-Errors
Reply-To: usenet.INS.CWRU.Edu!gatech.edu!ucsd!TCP-Group
Precedence: Bulk
Subject: TCP-Group Digest V93 #5
To: gatech.edu!tcp-group-digest
Status: RO


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: <[e-mail]>.
Subscription requests to <[e-mail]>.
Problems you can't solve otherwise to [e-mail].

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: [e-mail] (D. Crompton)
Subject: Digests???
To: [e-mail]

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: [e-mail] (D. Crompton)
Subject: Digests???
To: [e-mail]

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 <[e-mail]>
Subject: Digests???
To: "D. Crompton" <[e-mail]>

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" <[e-mail]>
Subject: Duplicate messages destroyed
To: [e-mail]

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: [e-mail] (Dean S. Anderson)
Subject: GMAIL??
To: [e-mail], [e-mail]

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)
[e-mail]

------------------------------

Date: Mon, 4 Jan 93 09:56:12 EST
From: [e-mail]
Subject: Leave it on
To: [e-mail]

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 <[e-mail]>
Subject: Linux 0.99 kernel TCP
To: [e-mail]

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: [e-mail] (C. Harald Koch)
Subject: Linux 0.99 kernel TCP
To: [e-mail] (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   | [e-mail]                (work-related mail)
and opposite goverment      | [e-mail]     (permanent address)
program.                    | VE3TLA@VE3OY.#SCON.ON.CA.NA            (AMPRNet)

------------------------------

Date: Mon, 04 Jan 1993 11:26:30 PST
From: "Jeffrey D. Angus" <[e-mail]>
Subject: MX records (again)
To: [e-mail]

On Mon,  4 Jan 93 04:06:06 EST, "Mike Bilow" <[e-mail]> 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
[e-mail]. 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:

                [e-mail]

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![e-mail] < the winter solstice is here >
US Mail:  PO Box  4425  Carson, CA  90749-4425    1 [phone]

------------------------------

Date: Tue, 5 Jan 93 02:14:30 -0800
From: Phil Karn <[e-mail]>
Subject: New version of NOS!
To: [e-mail]

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: [e-mail] (D. Crompton)
Subject: NOS BBS
To: [e-mail]

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 [e-mail] 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: [e-mail] (D. Crompton)
Subject: NOS BBS
To: [e-mail]

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 [e-mail]
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 <[e-mail]>
Subject: NOS on Internet?
To: [e-mail]

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
[e-mail]

===========================================================================
Dave Goodwin                                   |
Assistant Director, Academic Computing         | We're all kinds of animals
-----------------------------------------------| coming here.
BitNet   : Goodwin@SMCVAX                      |
Ma Bell  : [phone]                       | 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 <[e-mail]>
Subject: packet driver for parallel port?
To: [e-mail], [e-mail], [e-mail]

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" <[e-mail]>
Subject: packet driver for parallel port?
To: [e-mail]

In article <[e-mail]> 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 <[e-mail]> 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 <[e-mail]>
Subject: packet driver for parallel port?
To: John Paul Morrison <[e-mail]>

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
                [e-mail]

------------------------------

Date: Mon, 4 Jan 93 14:02:29 EST
From: [e-mail] (D. Crompton)
Subject: packet driver for parallel port?
To: [e-mail], [e-mail]

Russ,

 Is/will the new 3com etherlink III card supported?

Doug

------------------------------

Date: Mon, 04 Jan 1993 15:02:26 EST
From: "Russell Nelson" <[e-mail]>
Subject: packet driver for parallel port?
To: "D. Crompton" <[e-mail]>

On Mon, 4 Jan 93 14:02:29 EST, "D. Crompton" <[e-mail]> wrote:

>  Is/will the new 3com etherlink III card supported?

Yes.

--
-russ <[e-mail]> 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: [e-mail] (Andy Warner)
Subject: Perl interface to Packet BBS..
To: [e-mail] (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
[e-mail] 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

[e-mail]    Andy Warner, Cray Research, Inc.    [phone]

------------------------------

Date: Mon, 4 Jan 93 12:13:38 EST
From: [e-mail] (D. Crompton)
Subject: Problem with personal messages
To: [e-mail]

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: [e-mail] (D. Crompton)
Subject: STATUS command and BBS lockup
To: [e-mail]

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 <[e-mail]>
To: [e-mail]

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
******************************