| I've placed the archive in:
NORSE""::AMIGA:[000000.UPLOAD]DNET_V2_0_BETA.ZOO
It is in STREAM_LF format (i.e. uploaded with YMODEM), and is
ready for VMS Zoo to unpack it.
For those of you who do not receive USENET or missed the
announcement, here is the README and DNET.Doc files from
the distribution archive.
Mark
DNET V2.00
1 MARCH 1989
DNET (c)Copyright 1987-1989 Matthew Dillon, All Rights Reserved
Matthew Dillon
891 Regal Rd
Berkeley, Ca. 94708
USA
...!ihnp4!ucbvax!dillon USENET
dillon@ucbvax.Berkeley.edu ARPANET
ucbvax.berkeley.edu pub/amiga ARPANET-FTP
WHAT IS DNET
DNet is a link protocol and should properly be called DLink, but
the name DNet stuck and so it will stay. DNet allows one to connect two
amigas together and run multiple connections between them. For example,
you can open a talk window or two or three and be doing an upload and be
doing a download all at the same time.
Currently, DNet can be used to connect two Amiga's together or
an Amiga to a 4.2BSD/4.3BSD compatible UNIX.
** AN 8 BIT PATH MUST BE AVAILABLE TO RUN DNET ** DNet must be
able to send and receive all 256 character codes. This is generally not
a problem between two amigas connected via modem. This can be a problem
connecting to UNIX boxes over a port selector or terminal concentrator.
INSTALLING DNET ON YOUR AMIGA
(1) copy dres.library to libs:
(2) copy the DNet binary and all client and server program to
somewhere accessable on your path.
(3) copy s/dnet.servers to s:
* modify s:dnet.servers so all server paths point to whereever
you stuck the servers
(4) copy s/dnet.config to s:
* you may have to modify s:dnet.config too ... look into the
DOC directory for more information.
CALL A FRIEND WHO HAS GOT DNET INSTALLED
1> RUN DNET -X -8 -b1200
warning: The defaults for -X (manual mode) in S:DNET.CONFIG
turn off security. Please read documentation in the doc directory
for more information. This README file is only intended to get
you up and running. The above line also sets the baud to 1200...
the idea is you set it to what is proper for your modem. Again,
read DOC/DNET.DOC for more options and information.
A small DNET window should appear from which you can dialup your
friend's amiga. On CONNECT, DNET should automatically adjust the
baud rate. It may be necessary to modify S:DNET.CONFIG in this
regard (read the docs!)
After connecting, executing the START DNET menu option from either
end will start the protocol. The small dnet window should go away
and DNET should attempt to run the FTERM client program, which
connects to an STERM server program on the other end. Your friend's
amiga will do the same.
If all goes ok, it should flash the window size in the title bar
and you can type. If not, the window will go away and an error
message will be printed out in your CLI: "unable to connect".
WARNING: Even if there are no windows open (no clients active),
DNet is still running!!!! us the CLI BREAK command to kill DNet
and give you back the initial DNet window, from which you can
hit the close-window gadget.
breaking the DNet protocol will kill any active clients.
Unless specified with the -h option, if the modem carrier is lost
DNet will kill all clients and re-open its initial window.
SERVERS AND CLIENTS
DNet has a notion of servers and clients. That is, you run the
protocol as described above, then run other external programs that talk
to the core program "DNet". These other external programs "FTerm",
"GetFiles", "PutFiles", etc... obtain virtual connections to special
server programs on the remote machine.
Thus, when you started the protocol above DNet automatically
ran the FTERM client... you can run as many FTERMs as you have memory
for (well, actually, DNet is limited to 64 simultanious channels). When
a client program such as FTERM is run on computer A, it causes the
appropriate server program (STERM in this case) to automatically be run
on computer B. The client and server need some way to rendezvous, and they
do this by giving the same PORT NUMBER to the protocol driver.
This is what the S:DNET.SERVERS file is ... when you run a client
on computer A it asks for server #<blah> (e.g. 8195 for an FTERM) on the
remote machine. computer B (the remote machine) looks up 8195 in the
S:DNET.SERVERS file, finds the path to the server in question, and runs it
automatically.
PORT CLIENT SERVER PURPOSE
8192 PutFiles SCopy send files to remote computer
8195 FTerm STerm open a talk window on both computers
8196 ------ ------ reserved for shell server which does
not currently work well.
8197 LoadAv ------ Load-Average window (when running DNet
to a UNIX machine)
8198 ------ SPrint printer server
8199 DLogin SPasswd password server. Used to gain security
access (NOT IMPLEMENTED YET!)
8201 GetFiles SGCopy download files from remote computer
READ THE DOCS FOR EACH OF THESE SERVERS
SECURITY
Read DOC/DNET.DOC and documentation for each client/server. DNet
implements various levels of security. This is intended for BBS
support but I have not finished my DNet-BBS program yet. The security
is still there, however.
One example: If the DNET_READ security option (env: var is set
automatically from S:DNET.CONFIG depending on the option you give
DNET when you first run it) is anything less than 9, the SGCopy
server for GetFiles will only allow uploading from directories with
their comment field set a certain way. That is, you can control
exactly what you allow other people to download.
********************************************************************
AMIGA-DNET V2.00
AMIGA CONFIGURATION
ENV: must be assigned and writable.
S:DNET.CONFIG contains configuration info for DNet
S:DNET.SERVERS contains the server list for dnet (and paths to
the server executables)
Any DNet clients you wish to run or have DNet run must be in your path.
(i.e. FTERM, PUTFILES, GETFILES ...)
Other files will be required if you intend to run DNet *as* a BBS.
DNET OPTIONS
(please refer to S:DNET.CONFIG while reading this)
DNet runs in three basic modes: AutoAnswer (-a), DialOut (default),
and Manual (-X). Each mode has its own default set of security
parameters. The shipped defaults assume a hostile enviroment.
Generally, AutoAnswer is assumed to be the most hostile since you
do not know who is calling you up. DialOut is less so since you know
who you are dialing, and Manual assumes a non-hostile enviroment.
These three modes also cause DNet to work differently.
AMIGA/DNET
DialOutMode: The default mode is DialOutMode (neither -X or -a
given). DNet will look for a CONNECT message on carrier
detect and modify the baud rate according to the AUTA
resources.
DNet will set the security modes to the ENVO (originate)
resources in s:dnet.config
NOTE: response through the initial window will be slow due
to DNet's scanning of the resource file s:dnet.config.
-X Manual mode. DNet will look for a CONNECT message on
carrier detect and modify the baud rate on connect
appropriately.
DNet will set the security modes to the ENVM resources
which assumes a friendly connection.
-a Auto Answer mode. DNet will send the RESM resources at
the originally specified baud rate to reset the modem
whenever carrier is lost.
The security modes are set the the ENVA resources, which
normally assume a hostile enviroment.
-8 Use 8 bits no parity for the initial window rather than
7 bits even parity. NOTE! This only effects the initial
login window. The Protocol, when running, always uses
8 bits no parity.
-bbaud Set Initial Baud rate (otherwise uses preferences baud
rate)
-Bbaud Set Baud used to determine timeouts. If not set, the
current baud rate, whatever that is, is used. If set,
this value is used to calculate timeouts forever after
no matter what the actual line baud rate is.
For example, setting this value lower than whatever baud
rate you normally use will allow for longer line delays
(such as when dialing through networks and things)
-sclient Run the specified client program on protocol start. If
running a BBS you want to specify the BBS client program
here.
NOTE: If the DNET_NORUNCLIENT enviroment variable is set,
no client program will be run even if this option is
specified. This is used by DBBS to ensure that DNet does
not start it several times. This enviroment variable is
automatically deleted when DNET is first run.
The default is to run the FTERM client.
-nhostname Set the hostname (not used)
-h0 Disable the auto-hangup feature. This only works when
in DialOut (default) or Manual (-X) mode and causes DNet to
ignore the carrier detect line. CD MUST be implemented for
AutoAnswer.
-U# Set the unit number for the low level serial-like device
to talk over.
-Ddevice Set the device name for the low level serial-like device
to talk over (i.e. "serial.device").
-N# Set the network ID for local client/server rendezvous
-p Packet Debug mode
-d Debug mode on
---------------------------------------------------
SECURITY
The following enviroment variables should exist:
DNET_LEVEL, DNET_READ, DNET_WRITE, DNET_GROUP, DNET_USERID
These are setup automatically by the S:dnet.config file depending on
the mode (Manual, DialOut (-X), AutoAnswer (-a)) and are read by local
servers to determine what the remote machine is allowed to do. These
variables each hold a single value, normally 0-9 (except for DNET_GROUP
which can be any number 0-32767).
SGCOPY (server for getfiles):
This is a new server.
DNET_READ and DNET_GROUP determine which files the remote machine may download
(read). In order for the remote to be able to download a file,
that file and all its parent directories are scanned. At least
one comment field must have an AC entry (AC=n) less than or
equal to the current DNET_READ enviroment variable or sgcopy will
disallow the download. If NO comment fields have an AC entry
the download is disallowed. If any comment field has an AC
entry > DNET_READ, the download is disallowed unless a GP entry
was found (GR=n).
A comment field may have multiple GR entries (GR=n GR=n ...). If
any matches DNET_GROUP and all (if any) AC fields are <= DNET_READ,
the download is allowed.
After that point a download will begin and files/dirs need not have
AC entries. However, if any do, it will be checked again DNET_READ
and the download (for that file or directory) disallowed.
SCOPY (server for putfiles)
This server allows remote machines to upload a file. That is,
transfer from the remote machine to the local machine. DNET_WRITE
must be 9 or higher or the upload will be disallowed. Currently,
the remote machine may upload anywhere so it is suggested that you
either NOT have the SCOPY server installed or do not set DNET_WRITE
to 9 or beyond when talking to possibly hostile remote machines.
SPRINT (printer server)
This server copies a stream to PRT: DNET_WRITE must be at least
6 or the remote machine will not be allowed to use this server.
SCLI (CLI server)
This server is currently a big hack and requires a special pipe
device to work (The 1.3 pipe: will not work).
DNET_LEVEL must be at least 9 for a remote machine to be able to
start a remote cli
STERM (terminal window server)
This server requires no permissions to operate and allows the
remote machine to bring up a 'terminal window' to talk you
through.
AUTOMATIC ENVIROMENT VARIABLE CONFIGURATION CAN BE DONE FROM
S:DNET.CONFIG
---------------------------------------------------
TALKING TO A DBBS
Amiga users wishing to connect to DBBS hosts should use the following
command line:
Run dnet -8 -sbbsterm
The -8 is required only if you have a stupid 'smart' modem which
figures out the parity and then stays with it forever after. Since
neither -a or -X have been given, you are in the medium-security
'dial-out' mode.
Then, dial up the BBS in question. If the other end is indeed a
DNET-BBS running under automatic operation, the protocol should start
up almost immediately. On protocol startup, your side will
automatically attempt to run the BBSTERM program (which connects to the
BBS server on the other end). NOTE that the BBSTERM executable and
FTERM executable are one and the same. The naming 'BBSTERM' causes
it to use the BBS's port (8200) instead of the STERM port (8195)
Currently the BBS server will allow only one connection at a time and
return other attempts with an error. However, you can still download,
upload, readmail, and talk to the sysop all at the same time.
Downloading files from the DBBS
The getfiles client program is used to retrieve files from the DBBS.
The DBBS will set security options and such to allow you to download
files.
Allowing the DBBS to upload files from you
At least one of the directories in the path leading to the eventual
file/dir that you want to upload to the BBS must have a comment
field containing the string AC=<n> (e.g. AC=1) where <n> is at least
whatever read security level you have set (the DNET_READ enviroment
variable, for example: setenv DNET_READ 1), or the DBBS will be unable
to retrieve the file(s)/dir(s) and will tell you so.
---------------------------------------------------
EMAIL NETWORK
Has not been implemented yet, but will eventually be just another
server. This is one of the reasons why the connect-to-BBS is done
by the caller rather than have the BBS automatically startup an STERM
on protocol startup ... this way, future enhancements such as an
automated email network can be added without the burden of automatically
starting up a BBS everytime.
I also plan to implement a CRON based auto-dialer for email transfer.
----------------------------------------------
RUNNING AS A DBBS
The DBBS server program is a BBS system for the Amiga which runs under
DNet. The following is an example command line for automatic
operation. Your modem must implement the CD (carrier detect) line and
must disconnect when DTR is dropped.
Run dnet -8 -a -bmaxbaud -sdbbs (other options may apply)
That is, 8 bits no parity for the initial window (doesn't matter unless
you have one of those stupid-smart modems), answer mode (automatic
protocol startup on carrier detect), the maximum baud rate your modem
can handle, and to run the DBBS client on protocol startup.
The DBBS program is the BBS program itself. It is a client in that you
RUN it (or allow DNET to run it via the -s option). It is a server in
that it passively waits for connections from the remote end. This
program also handles disconnecting users when their time runs out or
they are idle too long.
REFER to DBBS.DOC FOR FURTHER INFORMATION
Since PUTFILES is a security hole right now, rather than have users
of the BBS PUTFILES to upload, they will request the BBS to GETFILES
the files to upload.
*NEVER SET YOUR DNET_LEVEL or DNET_WRITE TO 9 OR ABOVE! Doing so gives
remote users sysop level access to DNet.
NOTE: I intend to implement a mail network at some point. Remember
that in the future, users will dial up and connect to your machine to
do things other than just use the DBBS (i.e. they'll connect to the
EMAIL server in many cases for an automated mail transfer).
|