World of Ham Radio 1994 January/AMSOFT_1994.iso/packet/docs/pd198705.doc

Text File | 1993-12-31 | 146.4 KB | 3,685 lines

May-87 00:16:25-EDT,3015;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 1 May 87 00:16-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7 id <[e-mail]>; Thu, 30 Apr 87 23:27:03 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7 id <[e-mail]>; Thu, 30 Apr 87 23:26:47 EDT
Received: by june.cs.washington.edu (5.52.1/6.2)
    id AA17603; Thu, 30 Apr 87 20:27:01 PDT
Return-Path: <rutgers!lll-lcc!pyramid!ncc![e-mail]>
Date: 30 Apr 87 09:09:25 GMT
From: rutgers!lll-lcc!pyramid!ncc![e-mail] (Lyndon Nerenberg)
To: [e-mail]
Subject: Re: Cheap IP relays?
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Organization: Nexus Computing Corp.,  Edmonton, AB

This is a "folloup" to something I sent to the tcp-group mailing list
which I still don't trust... (delivery wise)

To make TCP/IP work well, we need a low cost hardware implementation.
To build a "TNC" to handle TCP, we need something capable of dealing
with many "real time" events. I have seen systems developed by a friend
of mine that have been able to handle transaction processing on an
X.25 network servicing terminals for automatic bank machines and
"teller terminals" in real time quite reliably for over two years.

These boxes are 6809 or 68000 single boards running OS/9. I have seen
some nice advantages to the architecture... All the code is (or should be)
ROMable. The CPU, ROM, serial ports, etc. can fit on a *small* board, and
can be implemented in CMOS for use in remote locations. Development can
be done on inexpensive machines (Radio Shaft Co-Co [gawd what an ugly name]
computers).

I've sent the suggestion of using OS/9 for remote "relay boxes" to the
tcp-group mailing list. Response has been fairly light either way
(other than from Phil, who said GO FOR IT, but he probably needs a
holiday anyway!). My question is, has anyone considered this, or done
any work on it? I believe this is a good development environment for
designing remote relays, and would like to contact other OS/9 hacks
who have experience in writing drivers in this environment. I have
enough MushDos gear at the office to ignore ... it would be a nice
change to code in a different environment. If someone would like
to volunteer to write the code to deal with the transmitter interface,
I will start on the level 2/3 code.

Be forwarned that I am a firm believer in such things as RFC822,
TCP to SPEC, etc. (not that I agree with *all* of these specs,
I just HATE to see RS-232 revisited in 8^934 different implementations)
If anyone is interested in helping with software development, please
drop me a line. If it works, we will have a fairly high profile
beta-test environment to work with (watch for our response to Phil's
survey request).

Lyndon Nerenberg  (VE6BBM)
Nexus Computing Corporation

alberta!ncc!lyndon || pyramid!ncc!lyndon || winfree!ncc!lyndon


 1-May-87 13:20:05-EDT,1173;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 1 May 87 13:20-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7 id <[e-mail]>; Fri, 1 May 87 12:12:08 EDT
Received: by EDDIE.MIT.EDU with UUCP with smail2.3 with sendmail-5.31/4.7 id <[e-mail]>; Fri, 1 May 87 12:11:42 EDT
Received: from mcvax.UUCP by seismo.CSS.GOV (5.54/1.14) with UUCP
    id AA02641; Fri, 1 May 87 11:50:35 EDT
Received: by mcvax.cwi.nl; Fri, 1 May 87 17:37:36 +0200 (MET)
Received: from idec.stc.co.uk by kestrel.Ukc.AC.UK   via PSS (UKC CAMEL FTP)
       id aa15346; 1 May 87 16:10 BST
From: Gareth Howell <[e-mail]>
Date: Fri, 1 May 87 16:13:06 GMT
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: Packet Addressing Schemes

Re: K4NGC's reference to grid square addressing
I would prefer name@address ala USENET
73s Gareth

Gareth Howell  <[e-mail]>  G6KVK @ IO91VX
ICL Network Systems, Private Networks Business Centre
London Road, Stevenage, Herts, England, SG1 1YB    Tel:[phone]
[e-mail], idec![e-mail]
 1-May-87 15:39:29-EDT,917;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 1 May 87 15:39-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7 id <[e-mail]>; Fri, 1 May 87 14:13:31 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7 id <[e-mail]>; Fri, 1 May 87 14:13:10 EDT
Received: by june.cs.washington.edu (5.52.1/6.2)
    id AA04597; Fri, 1 May 87 11:10:30 PDT
Return-Path: <spar![e-mail]>
Message-Id: <[e-mail]>
Date: 30 Apr 87 21:33:58 GMT
From: spar![e-mail] (Doug Faunt)
To: [e-mail]
Subject: Re: Packet on CB

Does any other service allow packet?  I'd not thought of it, but if
you could run high-speed (9600 bps, or even 56kbps) packet on some
other radio service where commercial use is allowed, then someone
could perhaps set up a packet station at work and have high speed
connections.


 2-May-87 12:41:24-EDT,1416;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 2 May 87 12:41-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7 id <[e-mail]>; Sat, 2 May 87 12:00:04 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7 id <[e-mail]>; Sat, 2 May 87 11:59:46 EDT
Received: by june.cs.washington.edu (5.52.1/6.2)
    id AA14721; Sat, 2 May 87 09:00:14 PDT
From: sun!imagen!atari!portal!cup.portal.com![e-mail]
Return-Path: <sun!imagen!atari!portal!cup.portal.com![e-mail]>
Message-Id: <[e-mail]>
Date: 1 May 87 20:29:00 GMT
To: [e-mail]
Subject: Re: Packet on CB
References: <[e-mail]>

This is a very interesting idea.  I am not exactly sure what the rules
regarding this would be, but technically, it has been done already.
in fact, I know first hand that the Kantronics KPCII will perform just
fine when connected to a cb radio.

I think the main rub you will find with kids using this is that
they may not have the RF knowledge to make it work really well.  Any of
this kind of stuff takes a lot of tweaking and ad hoc knowledge about
radios -- which most computer kids don't initially have.

Perhaps if packet on cb comes to be, we will have found a reasonable use
for that slice of the band.  (I have a cb and find it of very questionable
value right now.)


 3-May-87 05:56:40-EDT,18617;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 3 May 87 05:56-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7 id <[e-mail]>; Sun, 3 May 87 04:50:24 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7 id <[e-mail]>; Sun, 3 May 87 04:49:28 EDT
Received: from taurus by wiscvm.wisc.edu ; Sun, 03 May 87 03:49:11 CDT
Received: by taurus (5.51/ta.1.3.R)
    id AA24472; Sun, 3 May 87 11:43:24 +0300
Return-Path: <[e-mail]>
Date: Sun, 3 May 87 11:43:24 +0300
From: Yossi Eilati <[e-mail]>
Message-Id: <8705030843.AA24472@taurus>
To: [e-mail]
Subject: Re:  Yes, a Z-80 TCP is possible
Cc: ofer


.\" Copyright (c) 1980 Regents of the University of California.
.\" All rights reserved.  The Berkeley software License Agreement
.\" specifies the terms and conditions for redistribution.
.\"
.\"    @(#)adb.1       6.1 (Berkeley) 4/29/85
.\"
.TH ADB 1 "April 29, 1985"
.UC 4
.SH NAME
adb \- debugger
.SH SYNOPSIS
.B adb
[\fB\-w\fR] [ \fB\-k\fR ] [ \fB-I\fRdir ] [ objfil [ corfil ] ]
.ds TW \v'.25m'\s+2~\s-2\v'-.25m'
.ds ST *
.ds IM \v'.1m'=\v'-.1m'\s-2\h'-.1m'>\h'.1m'\s+2
.ds LE \(<=
.ds LT \s-2<\s+2
.ds GT \s-2>\s+2
.SH DESCRIPTION
.I Adb
is a general purpose debugging program.
It may be used to examine files and to provide
a controlled environment for the execution of UNIX programs.
.PP
.I Objfil
is normally an executable program file, preferably
containing a symbol table; if not then the symbolic features of
.I  adb
cannot be used although the file can still be examined.
The default for
.I objfil
is
.B  a.out.
.I Corfil
is assumed to be a core image file produced after executing
.IR objfil ;
the default for
.I corfil
is
.B  core.
.PP
Requests to
.I  adb
are read from the standard input and responses are to the standard output.
If the
.B  \-w
flag is present then both
.I  objfil
and
.I corfil
are created if necessary and opened for reading and writing
so that files can be modified using
.IR adb .
.PP
The \fB\-k\fP option makes \fIadb\fP do UNIX kernel memory
mapping; it should be used when \fIcore\fP is a UNIX crash dump
or \fI/dev/mem\fP.
.PP
The \fB\-I\fP option specifies a directory where files to be read
with $< or $<< (see below) will be sought; the default is
.IR /usr/lib/adb .
.PP
.I Adb
ignores QUIT; INTERRUPT causes return to the next
.I adb
command.
.PP
In general requests to
.I  adb
are of the form
.PP
.if n .ti 16
.if t .ti 1.6i
[\|\fIaddress\fR\|]  [\|,
.IR count \|]
[\|\fIcommand\fR\|] [\|;\|]
.PP
If
.I address
is present then
.I  dot
is set to
.IR address .
Initially
.I dot
is set to 0.  For most commands
.I count
specifies how many times the command will be executed.  The default
.I count
is 1.
.I Address
and
.I count
are expressions.
.PP
The interpretation of an address depends on the context it is used in.
If a subprocess is being debugged then addresses are interpreted
in the usual way in the address space of the subprocess.
If the operating system is being debugged either post-mortem or using
the special file
.I /dev/mem
to interactive examine and/or modify memory the maps are set to map
the kernel virtual addresses which start at 0x80000000 (on the VAX).
.SM ADDRESSES.
.SH EXPRESSIONS
.TP 7.2n
.B .
The value of
.IR dot .
.TP 7.2n
+
The value of
.I dot
incremented by the current increment.
.TP 7.2n
^
The value of
.I dot
decremented by the current increment.
.TP 7.2n
"
The last
.I address
typed.
.TP 7.2n
.I integer
A number.  The prefixes 0o and 0O (\*(lqzero oh\*(rq) force interpretation
in octal radix; the prefixes 0t and 0T force interpretation in
decimal radix; the prefixes 0x and 0X force interpretation in
hexadecimal radix.  Thus 0o20 = 0t16 = 0x10 = sixteen.
If no prefix appears, then the
.I default\ radix
is used; see the $d command.  The default radix is initially hexadecimal.
The hexadecimal digits are 0123456789abcdefABCDEF with the obvious
values.  Note that a hexadecimal number whose most significant
digit would otherwise be an alphabetic character must have a 0x
(or 0X) prefix (or a leading zero if the default radix is hexadecimal).
.TP 7.2n
.IB integer . fraction
A 32 bit floating point number.
.TP 7.2n
.I \'cccc\|\'
The ASCII value of up to 4 characters.
\e may be used to escape a \'.
.TP 7.2n
.I \*(LT name
The value of
.IR name ,
which is either a variable name or a register name.
.I Adb
maintains a number of variables (see
.SM VARIABLES\*S)
named by single letters or digits.
If
.I name
is a register name then the value of the register is obtained from
the system header in
.IR corfil .
The register names are those printed by the $r command.
.TP 7.2n
.I symbol
A
.I symbol
is a sequence of upper or lower case letters, underscores or
digits, not starting with a digit.  The backslash character
.B \e
may be used to escape other characters.  The value of the
.I symbol
is taken from the symbol table in
.IR objfil .
An initial \_ will be prepended to
.I symbol
if needed.
.TP
.I _ symbol
In C, the `true name' of an external symbol begins with _.
It may be necessary to utter this name to distinguish it
from internal or hidden variables of a program.
.TP 7.2n
.IB routine . name
The address of the variable
.I name
in the specified C routine.  Both
.I routine
and
.I name
are
.IR symbols .
If
.I name
is omitted the value is the address of the most recently activated C stack frame
corresponding to
.IR routine .
(This form is currently broken on the VAX; local variables can be examined
only with
.IR dbx (1).)
.TP 7.2n
.RI ( exp \|)
The value of the expression
.IR exp .
.LP
.SM
.B  "Monadic\ operators"
.TP 7.2n
.RI \*(ST exp
The contents of the location addressed by
.I exp
in
.IR corfil .
.TP 7.2n
.RI @ exp
The contents of the location addressed by
.I exp
in
.IR objfil .
.TP 7.2n
.RI \- exp
Integer negation.
.TP 7.2n
.RI \*(TW exp
Bitwise complement.
.TP 7.2n
.RI # exp
Logical negation.
.LP
.tr ''
.B  "Dyadic\ operators"
are left associative and are less binding than monadic operators.
.TP 7.2n
.IR e1 + e2
Integer addition.
.TP 7.2n
.IR e1 \- e2
Integer subtraction.
.TP 7.2n
.IR e1 \*(ST e2
Integer multiplication.
.TP 7.2n
.IR e1 % e2
Integer division.
.TP 7.2n
.IR e1 & e2
Bitwise conjunction.
.TP 7.2n
.IR e1 \(bv e2
Bitwise disjunction.
.TP 7.2n
.IR e1 # e2
.I E1
rounded up to the next multiple of
.IR e2 .
.DT
.SH COMMANDS
Most commands consist of a verb followed by a modifier or list of modifiers.
The following verbs are available.
(The commands `?' and `/' may be followed by `\*(ST'; see
.SM ADDRESSES
for further details.)
.TP .5i
.RI ? f
Locations starting at
.I address
in
.I  objfil
are printed according to the format
.IR f .
.I dot
is incremented by the sum of the increments for each format letter (q.v.).
.TP
.RI / f
Locations starting at
.I address
in
.I  corfil
are printed according to the format
.I f
and
.I dot
is incremented as for `?'.
.TP
.RI  = f
The value of
.I address
itself is printed in the styles indicated by the format
.IR f .
(For
.B i
format `?' is printed for the parts of the instruction that reference
subsequent words.)
.PP
A
.I format
consists of one or more characters that specify a style of printing.
Each format character may be preceded by a decimal integer
that is a repeat count for the format character.
While stepping through a format
.I dot
is incremented by the amount given for each format letter.
If no format is given then the last format is used.
The format letters available are as follows.
.ta 2.5n .5i
.RS
.TP
.BR o "        2"
Print 2 bytes in octal.  All octal numbers output by
.I adb
are preceded by 0.
.br
.ns
.TP
.BR O "        4"
Print 4 bytes in octal.
.br
.ns
.TP
.BR q "        2"
Print in signed octal.
.br
.ns
.TP
.BR Q "        4"
Print long signed octal.
.br
.ns
.TP
.BR d "        2"
Print in decimal.
.br
.ns
.TP
.BR D "        4"
Print long decimal.
.br
.ns
.TP
.BR x "        2"
Print 2 bytes in hexadecimal.
.br
.ns
.TP
.BR X "        4"
Print 4 bytes in hexadecimal.
.br
.ns
.TP
.BR u "        2"
Print as an unsigned decimal number.
.br
.ns
.TP
.BR U "        4"
Print long unsigned decimal.
.br
.ns
.TP
.BR f "        4"
Print the 32 bit value as a floating point number.
.br
.ns
.TP
.BR F "        8"
Print double floating point.
.br
.ns
.TP
.BR b "        1"
Print the addressed byte in octal.
.br
.ns
.TP
.BR c "        1"
Print the addressed character.
.br
.ns
.TP
.BR C "        1"
Print the addressed character using
the standard escape convention where control characters
are printed as ^X and the delete character is printed as ^?.
.br
.ns
.TP
.BI s "        n"
Print the addressed characters until a zero character is reached.
.br
.ns
.TP
.BI S "        n"
Print a string using the ^\fIX\fR escape convention (see \fBC\fR above).
.I n
is the length of the string including its zero terminator.
.br
.ns
.TP
.BR Y "        4"
Print 4 bytes in date format (see
.IR ctime (3)).
.br
.ns
.TP
.BR i "        n"
Print as machine instructions.
.I n
is the number of bytes occupied by the instruction.
This style of printing causes variables 1 and 2 to be set
to the offset parts of the source and destination respectively.
.br
.ns
.TP
.BR a "        0"
Print the value of
.I dot
in symbolic form.
Symbols are checked to ensure that they have an appropriate
type as indicated below.
.LP
    /       local or global data symbol
.br
    ?       local or global text symbol
.br
    =       local or global absolute symbol
.TP
.BR p "        4"
Print the addressed value in symbolic form using
the same rules for symbol lookup as
.BR a .
.br
.tr ''
.ns
.TP
.BR t "        0"
When preceded by an integer tabs to the next appropriate tab stop.
For example,
.B 8t
moves to the next 8-space tab stop.
.br
.ns
.TP
.BR r "        0"
Print a space.
.br
.ns
.TP
.BR n "        0"
Print a newline.
.br
.ns
.tr '"
.TP
.BR '...' " 0"
Print the enclosed string.
.br
.tr ''
.br
.ns
.TP
.B ^
.I Dot
is decremented by the current increment.  Nothing is printed.
.br
.ns
.TP
+
.I Dot
is incremented by 1.  Nothing is printed.
.br
.ns
.TP
\-
.I Dot
is decremented by 1.  Nothing is printed.
.RE
.TP
newline
Repeat the previous command with a
.I count
of 1.
.TP
.RB [ ?/ ] l "\fI value mask\fR"
Words starting at
.I  dot
are masked with
.I mask
and compared with
.I value
until a match is found.
If
.B L
is used then the match is for 4 bytes at a time instead of 2.
If no match is found then
.I dot
is unchanged; otherwise
.I dot
is set to the matched location.
If
.I mask
is omitted then \-1 is used.
.TP
.RB [ ?/ ] w "\fI value ...\fR"
Write the 2-byte
.I value
into the addressed location.  If the command is
.BR W ,
write 4 bytes.
Odd addresses are not allowed when writing to the subprocess address space.
.TP
[\fB?/\fR]\fBm\fI b1 e1 f1\fR[\fB?/\fR]
.br
New values for
.RI ( b1,\ e1,\ f1 )
are recorded.  If less than three expressions are given then
the remaining map parameters are left unchanged.
If the `?' or `/' is followed by `\*(ST' then
the second segment (\fIb2\fR\|,\|\fIe2\fR\|,\|\fIf2\fR)
of the mapping is changed.
If the list is terminated by `?' or `/' then the file (\fIobjfil\fR or
.I corfil
respectively) is used for subsequent requests.
(So that, for example, `/m?' will cause `/' to refer to
.IR objfil .)
.TP
.BI \*(GT name
.I Dot
is assigned to the variable or register named.
.TP
.B !
A shell (/bin/sh) is called to read the rest of the line following `!'.
.TP
.RI $ modifier
Miscellaneous commands.  The available
.I modifiers
are:
.RS
.TP
.BI < f
Read commands from the file
.IR f .
If this command is executed in a file, further commands
in the file are not seen.
If
.I f
is omitted, the current input stream is terminated.  If a
.I count
is given, and is zero, the command will be ignored.
The value of the count will be placed in variable
.I 9
before the first command in
.I f
is executed.
.br
.ns
.TP
.BI << f
Similar to
.B <
except it can be used in a file of commands without
causing the file to be closed.  Variable
.I 9
is saved during the execution of this command, and restored when it completes.
There is a (small) finite limit to the number of
.B <<
files that can be open at once.
.br
.ns
.TP
.BI > f
Append output to the file
.IR f ,
which is created if it does not exist.  If
.I f
is omitted, output is returned to the terminal.
.br
.ns
.TP
.B ?
Print process id, the signal which caused stoppage or termination,
as well as the registers as \fB$r\fR.  This is the default if
\fImodifier\fR is omitted.
.br
.ns
.TP
.B r
Print the general registers and the instruction addressed by
.BR pc .
.I Dot
is set to \fBpc\fR.
.br
.ns
.TP
.B b
Print all breakpoints and their associated counts and commands.
.br
.ns
.TP
.B c
C stack backtrace.  If
.I address
is given then it is taken as the address of the current frame
instead of the contents of the frame\-pointer register.  If
.B C
is used then the names and (32 bit) values of all automatic
and static variables are printed for each active function. (broken
on the VAX).  If
.I count
is given then only the first
.I count
frames are printed.
.br
.ns
.TP
.B d
Set the default radix to
.I address
and report the new value.  Note that
.I address
is interpreted in the (old) current radix.
Thus \*(lq10$d\*(rq never changes the default radix.
To make decimal the default radix, use \*(lq0t10$d\*(rq.
.br
.ns
.TP
.B e
The names and values of external variables are printed.
.br
.ns
.TP
.B w
Set the page width for output to
.I address
(default 80).
.br
.ns
.TP
.B s
Set the limit for symbol matches to
.I address
(default 255).
.br
.ns
.TP
.B o
All integers input are regarded as octal.
.br
.ns
.TP
.B q
Exit from
.IR adb .
.br
.ns
.TP
.B v
Print all non zero variables in octal.
.br
.ns
.TP
.B m
Print the address map.
.br
.ns
.TP
.B p
.RI ( "Kernel debugging" )
Change the current kernel memory mapping to map the designated
.B "user structure"
to the address given by the symbol
.I "_u."
The
.I address
argument is the address of the user's user page table entries (on
the VAX).
.RE
.TP
.BI : modifier
Manage a subprocess.  Available modifiers are:
.RS
.TP
.BI b c
Set breakpoint at
.IR address .
The breakpoint is executed
.IR count \-1
times before causing a stop.
Each time the breakpoint is encountered the command
.I c
is executed.  If this command is omitted or sets
.I dot
to zero then the breakpoint causes a stop.
.TP
.B d
Delete breakpoint at
.IR address .
.TP
.B r
Run
.I objfil
as a subprocess.  If
.I address
is given explicitly then the program is entered at this point; otherwise
the program is entered at its standard entry point.
.I count
specifies how many breakpoints are to be ignored before stopping.
Arguments to the subprocess may be supplied on the same line as the command.
An argument starting with < or > causes the standard
input or output to be established for the command.
.TP
.BI c s
The subprocess is continued with signal
.I s,
see
.IR sigvec (2).
If
.I address
is given then the subprocess is continued at this address.
If no signal is specified then the signal
that caused the subprocess to stop is sent.
Breakpoint skipping is the same as for
.BR r .
.TP
.BI s s
As for
.B c
except that the subprocess is single stepped
.I count
times.  If there is no current subprocess then
.I objfil
is run as a subprocess as for
.BR r .
In this case no signal can be sent; the remainder of the line
is treated as arguments to the subprocess.
.TP
.B k
The current subprocess, if any, is terminated.
.RE
.SH VARIABLES
.I Adb
provides a number of variables.
Named variables are set initially by
.I  adb
but are not used subsequently.
Numbered variables are reserved for communication as follows.
.TP
0
The last value printed.
.br
.ns
.TP
1
The last offset part of an instruction source.
.br
.ns
.TP
2
The previous value of variable 1.
.br
.ns
.TP
9
The count on the last $< or $<< command.
.PP
On entry the following are set from the system header in the
.IR corfil .
If
.I corfil
does not appear to be a
.B core
file then these values are set from
.IR objfil .
.TP
b
The base address of the data segment.
.br
.ns
.TP
d
The data segment size.
.br
.ns
.TP
e
The entry point.
.br
.ns
.TP
m
The `magic' number (0407, 0410 or 0413).
.br
.ns
.TP
s
The stack segment size.
.br
.ns
.TP
t
The text segment size.
.SH ADDRESSES
The address in a file associated with
a written address is determined by a mapping associated with that file.
Each mapping is represented by two triples
.RI ( "b1, e1, f1" )
and
.RI ( "b2, e2, f2" )
and the
.I file address
corresponding to a written
.I address
is calculated as follows.
.PP
.if t .ti 1.5i
.if n .ti 8
.IR b1 \*(LE address < e1
\*(IM
.IR "file address" = address + f1\-b1,
otherwise,
.PP
.if t .ti 1.5i
.if n .ti 8
.IR b2 \*(LE address < e2
\*(IM
.IR "file address" = address + f2\-b2,
.PP
otherwise, the requested
.I address
is not legal.  In some cases (e.g. for programs with separated I and D
space) the two segments for a file may overlap.  If a
.B ?
or
.B /
is followed by an
.B \*(ST
then only the second triple is used.
.PP
The initial setting of both mappings is suitable for normal
.B a.out
and
.B core
files.  If either file is not of the kind expected then, for that file,
.I b1
is set to 0,
.I e1
is set to the maximum file size and
.I f1
is set to 0; in this way the whole
file can be examined with no address translation.
.PP
.SH FILES
a.out
.br
core
.SH SEE\ ALSO
cc(1),
dbx(1),
ptrace(2),
a.out(5),
core(5)
.SH DIAGNOSTICS
`Adb' when there is no current command or format.
Comments about inaccessible files, syntax errors,
abnormal termination of commands, etc.
Exit status is 0, unless last command failed or returned nonzero status.
.SH BUGS
Since no shell is invoked to interpret the arguments of the
.B :r
command, the customary wild-card and variable expansions cannot occur.
 3-May-87 23:57:16-EDT,3108;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 3 May 87 23:57-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7 id <[e-mail]>; Sun, 3 May 87 19:59:30 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7 id <[e-mail]>; Sun, 3 May 87 19:58:42 EDT
Date: Fri, 1 May 1987 12:40-EDT
From: [e-mail]
To: [e-mail]
Subject: Re: Cheap IP relays?
Message-Id: <546885656/[e-mail]>
In-Reply-To: <[e-mail]>

>To make TCP/IP work well, we need a low cost hardware implementation.
>To build a "TNC" to handle TCP, we need something capable of dealing
>with many "real time" events.

>These boxes are 6809 or 68000 single boards running OS/9. I have seen
>some nice advantages to the architecture... All the code is (or should be)
>ROMable. The CPU, ROM, serial ports, etc. can fit on a *small* board, and
>can be implemented in CMOS for use in remote locations. Development can
>be done on inexpensive machines (Radio Shaft Co-Co [gawd what an ugly name]
>computers).

I don't know about building a TNC specifically for TCP/IP, although I think
we will need more horsepower and memory for future growth.

I suggested OS/9 based packet radio a while back, especially since the TNC-1
was 6809-based, OS/9 is ROMmable, etc.  Would have made a nifty combination.
The only thing that discourages me is that OS/9 is the fact that it is a
proprietary OS, I don't think amateurs will much want to develop on it unless
MicroWare does something special, like real cheap (or free) licensing for
developers for non-commercial (amateur) use.  Otherwise people will go on
and use the PC clones running Minix, etc.

Anyway, the 68000 is a much nicer platform to work from, how much would it
take to build a 60008-based TNC capable of running OS/9-68000 (or Minix) in
ROM?  I'd rather use an Amiga 500, Atari ST, or Mac to develop on.

I always thought it would be useful to build a box with the processor, memory,
serial and TTL I/O ports, and have the modem external, so it would more easily
support experimentation with higher speed or different modulation.  (I think a
Z80 will be hard-pressed to keep up at 56kbps.)  In a pinch you could add some
sort of disk drive and a terminal, and build a general purpose computer system
out of it.  But if you're going with an external modem anyway, why not just
add it to your exising computer and let it do the work?   The external modem
would consist of (NRZ<->NRZI chip + modem).  It helps to have Zilog 8530 SCC
serial ports to handle HDLC automagically.

The tradeoffs get complicated very quickly.

The old Macintosh digital boards would be almost perfect for something like
this, since they have 8530 SCC chips (~4 serial ports) and a disk drive port.
Sort of like a next generation Xerox 820.--
                    - Ralph W. Hyre, Jr.

Copyright (c) 1987 by Ralph W. Hyre, Jr.
Internet: [e-mail]    Phone:(412)268-{2847,3275} CMU-{BUGS,DARK}
Amateur Packet Radio: N3FGW@W2XO, or c/o W3VC, CMU Radio Club, Pittsburgh, PA
 4-May-87 03:40:21-EDT,853;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 4 May 87 03:40-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7 id <[e-mail]>; Mon, 4 May 87 01:02:29 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7 id <[e-mail]>; Mon, 4 May 87 01:02:14 EDT
Date:     Mon, 4 May 87 0:59:06 EDT
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Subject:  Re:  Cheap IP relays?
Message-Id:  <[e-mail]>

Ralph,

If you really mean your copyright notice at the end of your message, be advised
I cannot agree to copyright provisions via this medium. Messages from this list
are assumed freely distributable, via mail forwarding, relay and archiving. If
this is unacceptable to you, please advise soonest with specific instructions.

Dave, W3HCF
 4-May-87 12:00:44-EDT,1789;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 4 May 87 12:00-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7 id <[e-mail]>; Mon, 4 May 87 10:58:40 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7 id <[e-mail]>; Mon, 4 May 87 10:58:18 EDT
Received: by LANL.GOV (5.54/5.17)
    id AA19815; Mon, 4 May 87 08:11:23 MDT
Date: Mon, 4 May 87 08:11:23 MDT
From: [e-mail] (David Wade)
Message-Id: <[e-mail]>
To: cmcl2!ius2.cs.cmu.edu!ll-xn![e-mail],
    [e-mail]
Subject: Re: Cheap IP relays?

Now you've finally gone and done it...  Your suggestion that a Macintosh
take out board would suffice is really interesting.  They are available
from many different dealers for about $100.00 since that's about the value
the apple dealer gets for them from apple.  (That was when the 512K apples
were new, I suspect you can't spend near that much for a 128K board now).

And getting a 128K Mac or even a 512K Macintosh up and running given that you
have a 128K Mother-Board is trivial.  Back then there were only two boards in
the Mac, and one was a board which contained the electronics for the monitor,
and the other board contained the computer.  With about four resistors and a
gate, you can replace the second board with a plug-in monitor and you even get
a larger screen, free.  You need a disk drive and keyboard and you're on the
air with Mac.  I bought two takeout motherboards and then I bought a Mac+
because there wasn't that much difference back then,  Maybe I'll pull out
my junk box and see what I can do with them now that the disk drive is under
$100.00 and the keyboard is cheap.

Thanks for reminding me about these jewels...
Dave Wade
WB5PFS
 6-May-87 14:24:03-EDT,2088;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 6 May 87 14:23-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7 id <[e-mail]>; Wed, 6 May 87 12:23:45 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7 id <[e-mail]>; Wed, 6 May 87 12:23:28 EDT
Received: by june.cs.washington.edu (5.52.1/6.2)
    id AA15214; Wed, 6 May 87 07:52:02 PDT
Return-Path: <rochester!rocksvax!rocksanne!sunybcs![e-mail]>
From: rochester!rocksvax!rocksanne!sunybcs![e-mail] (Devon Bowen)
To: [e-mail]
Subject: Re: Packet on CB
Message-Id: <[e-mail]>
Date: 3 May 87 13:07:32 GMT
References: <[e-mail]> <[e-mail]>
Distribution: usa
Organization: SUNY/Buffalo Computer Science

[Administrative note: I think most of this conversation has been going on
              in INFO-HAMS, as opposed to PACKET-RADIO -N1DMM    ]

In article <[e-mail]> [e-mail] writes:
>
>they may not have the RF knowledge to make it work really well.  Any of
>this kind of stuff takes a lot of tweaking and ad hoc knowledge about
>radios -- which most computer kids don't initially have.

The key word here is INITIALLY. You have to remember that these are kids,
and hackers at that. Most of them figured out computers without any help
and RF is just another challenge to them. I think it would be a big
success and, like the original article said, it might bring more younger
people (lower income as well) into HAMming. Anything I can do to help,
let me know.

                   Devon Bowen (KA2NRC)
                   University of Buffalo

********************************************************
csnet:   [e-mail]
uucp:    ..!{allegra,decvax,watmath,rocksanne}!sunybcs!ugbowen
BITNET:  [e-mail]
BBS:     [phone] (On-line: Computer Access Center)
Voice:   [phone]
USnail:  67 Lisbon Ave; Buffalo, NY; 14214
********************************************************


 7-May-87 20:25:11-EDT,2656;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 7 May 87 20:25-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7 id <[e-mail]>; Thu, 7 May 87 18:49:21 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7 id <[e-mail]>; Thu, 7 May 87 18:49:00 EDT
Received: by june.cs.washington.edu (5.52.1/6.2)
    id AA17236; Thu, 7 May 87 12:35:09 PDT
Return-Path: <gatech!mcnc!ece-csc!ncrcae![e-mail]>
Date: 7 May 87 12:19:16 GMT
From: gatech!mcnc!ece-csc!ncrcae![e-mail] (Joe Flake)
To: [e-mail]
Subject: Re: Packet on CB
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Reply-To: ncrcae![e-mail] (Joe Flake)
Organization: NCR Corp., Engineering & Manufacturing - Columbia, SC
Lines: 35

>>
>> That would be a lovely idea if and only if the CB packet users are kept
>> at a fairly low power so that distant stations are less likely to
>> collide.  Say 1 watt.
>>
There have been several followups to the idea of limiting power if packet
were to be used on CB.  Why the SPECIFIC concern over power on the CB
bands (other than the FFC "regulated" limits)?  Amateurs certainly have
been known to run excess power from time to time using packet.  I've
heard people mention using high power on 2M so they can get into the digi
better (ie over the other fellow running lower power).  What power levels
are used on HF packet?  I suspect it's mostly barefoot operation (~100W),
but I also suspect there's high power operation as well (~1KW and UP).

>From a technical point of view, CB packet should be pretty straightforward.
CBs have a mike input and external speaker connect, so a TNC should plug
right in.  It may even be easier than amateur HF packet due to the channel
frequency select (the few times I've listened to HF packet, tuning the
VFO to get on frequency has been a pain).

Can anyone address the FCC regulations regarding packet mode on 11M?  What
group would stand up and petition the FCC for any changes?  From what I
understand, the FCC has pretty much abandoned 11M.  Since CB has gone
down the drain, perhaps they could allocate portions of it to the hungry
ground mobile services, and open up the rest of it for modes other
than AM and SSB.

What a dream -- I'll wake up soon!
I know that no other service would want to try to take away spectrum
>from thousands and thousands of "good-buddies"; they'd rather take it
>from a group of relatively orderly amateurs.

Joe Flake, N4BGQ
NCR Corp, W. Columbia, SC
...ncrcae!flake


 7-May-87 20:35:01-EDT,713;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 7 May 87 20:35-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7 id <[e-mail]>; Thu, 7 May 87 17:56:26 EDT
Received: from xx.lcs.mit.edu by EDDIE.MIT.EDU via Chaosnet with SMTP with sendmail-5.31/4.7 id <[e-mail]>; Thu, 7 May 87 17:56:00 EDT
Received: from STL-HOST1.ARPA by XX.LCS.MIT.EDU with TCP/SMTP; Thu 7 May 87 17:54:14-EDT
Date: Thu, 7 May 87 16:55:20 CDT
From: Kevin Black <[e-mail]>
Subject: addition
To: packet-radio@MIT-EDDIE
Message-Id: <[e-mail]>

*
Please add me to your mailing list.
Thank you in advance

Regards,

Kevin Black
-------
 8-May-87 01:16:21-EDT,1101;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 8 May 87 01:16-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7 id <[e-mail]>; Fri, 8 May 87 00:11:31 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7 id <[e-mail]>; Fri, 8 May 87 00:10:43 EDT
Received: by june.cs.washington.edu (5.52.1/6.2)
    id AA15135; Thu, 7 May 87 21:05:49 PDT
Return-Path: <ll-xn!ames!ptsfa!hoptoad!academ!killer![e-mail]>
Message-Id: <[e-mail]>
Date: 2 May 87 16:12:03 GMT
From: ll-xn!ames!ptsfa!hoptoad!academ!killer![e-mail] (Chris Wiener)
To: [e-mail]
Subject: PC-100 Availability
Keywords: PC-100,KA9Q,TCP/IP,IBM-PC

I have recently obtained the KA9Q TCP/IP package for IBM-PC's and noticed that
the next version will have support for the PC-100 dual HDLC/modem plug-in card.
Can anyone point me to a source of PC boards and technical docs for this board.
Thanks and 73,
                    -../.
                  Chris Wiener N2CR

                UUCP: {ihnp4,cuae2}!killer!cwiener
                FIDO: Via 107/528


 8-May-87 12:59:55-EDT,879;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 8 May 87 12:59-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7 id <[e-mail]>; Fri, 8 May 87 10:44:43 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7 id <[e-mail]>; Fri, 8 May 87 10:44:26 EDT
Message-Id: <[e-mail]>
Received: from DBSTU1.BITNET by wiscvm.wisc.edu ; Fri, 08 May 87 02:47:04 CDT
Date: Fri, 08 May 87 09:46:18 MEZ
To: [e-mail]
From: [e-mail]
Subject: cosireq

Date: 8 May 1987, 09:39:39 MEZ
From: C0033003 at DBSTU1
To:   PACKET-RADIO at EDDIE.MIT

Dear Sirs
Please send me the File COSI10.DOC of the Packet-radio directory or let
me know how I cat obtain this file from a BITNET node.
(originator DBENNETT @ xmm-plexus01.mit.edu)
Thank you in advance
Detlef J. Schmidt
 9-May-87 11:26:43-EDT,2784;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 9 May 87 11:26-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7 id <[e-mail]>; Sat, 9 May 87 10:46:14 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7 id <[e-mail]>; Sat, 9 May 87 10:46:03 EDT
Received: by june.cs.washington.edu (5.52.1/6.2)
    id AA10132; Sat, 9 May 87 07:43:59 PDT
From: ulysses!faline![e-mail]
Return-Path: <ulysses!faline![e-mail]>
Date: 9 May 87 00:26:00 GMT
To: [e-mail]
Subject: Re: PC-100 Availability
Summary: pc100 doesn't work yet
Keywords: PC-100,KA9Q,TCP/IP,IBM-PC
Message-Id: <[e-mail]>
References: <[e-mail]>
Distribution: usa
Organization: Bell Communications Research, Inc
Lines: 35
Posted: Fri May  8 20:26:00 1987

> I have recently obtained the KA9Q TCP/IP package for IBM-PC's and
> noticed that the next version will have support for the PC-100 dual
> HDLC/modem plug-in card. Can anyone point me to a source of PC boards
> and technical docs for this board.

The PC-100 is an interface card for the IBM PC containing a Zilog 8530
Serial Communications Controller and two AMD 7910 World Chip modems. It
was originally designed by Terry Fox, WB4JFI. Terry has sold his design
to Paccomm in Florida, owned by Gwyn, W1BEL.

I received two PC-100s several months ago and proceeded to write an
interrupt-mode driver for my TCP/IP package.  Unfortunately, I was never
able to get the board to work properly; I would never get more than one
interrupt from the board.  I have experience in writing drivers for
other devices under MS-DOS as well as for the 8530 on the Xerox 820, but
I haven't been able to make this one work.  The 8530 was designed to
work with the Z-80, and I noticed that Terry left the INTA (interrupt
acknowledge) pin on the 8530 disconnected; it is normally connected to
the Z-80 bus. I've not been able to figure out from Zilog's
documentation whether this is supposed to work or not.  Other 8530 cards
for the PC provide special circuitry for driving the INTA pin, so it may
be the lack of this on the PC-100 that's causing the problem.

There are other HDLC boards for the IBM PC. Jon Bloom, KE3Z, of the ARRL
technical department wrote a driver for my package that uses the
Hamilton Area Packet Network (HAPN) card. The HAPN board uses the old
Intel 8273 chip of Vancouver fame.  I don't have one of those cards, but
Jon reports that the driver works fine.  Another possibility is a source
of surplus Eagle Computer cards with the 8530 chip. I have two but
haven't worked on getting them going yet. Brian Lloyd, WB6RQN
(bellcore!wb6rqn!brian) has investigated this source; contact him for
details.

73,
Phil


 9-May-87 11:30:52-EDT,1059;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 9 May 87 11:30-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7 id <[e-mail]>; Sat, 9 May 87 10:45:39 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7 id <[e-mail]>; Sat, 9 May 87 10:45:31 EDT
Received: by june.cs.washington.edu (5.52.1/6.2)
    id AA10121; Sat, 9 May 87 07:43:24 PDT
From: ulysses!faline![e-mail]
Return-Path: <ulysses!faline![e-mail]>
Message-Id: <[e-mail]>
Date: 9 May 87 00:28:42 GMT
To: [e-mail]
Subject: Re: Packet Addressing Schemes
Summary: names and addresses are separate issues
References: <[e-mail]>
Posted: Fri May  8 20:28:42 1987

> Re: K4NGC's reference to grid square addressing
> I would prefer name@address ala USENET
> 73s Gareth

Names, addresses and routes are (or should be) entirely separate issues.
See ARPA RFC 814. Also see my paper in the Fourth ARRL Computer Networking
Conference (Orlando, 1986).

Phil


10-May-87 15:12:01-EDT,1732;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 10 May 87 15:11-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7 id <[e-mail]>; Sun, 10 May 87 14:17:18 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7 id <[e-mail]>; Sun, 10 May 87 14:17:09 EDT
Received: by june.cs.washington.edu (5.52.1/6.2)
    id AA15796; Sun, 10 May 87 11:18:00 PDT
Return-Path: <tektronix!orca!tekecs!stalker![e-mail]>
Date: 8 May 87 18:16:50 GMT
From: tektronix!orca!tekecs!stalker![e-mail] (Jan Steinman)
To: [e-mail]
Subject: Re: Packet on CB
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Organization: Tektronix, Inc., Wilsonville, OR

In article <[e-mail]> [e-mail] (Joe Flake) writes:
>I've heard people mention using high power on 2M so they can get into the digi
>better (ie over the other fellow running lower power)...
>
>From a technical point of view, CB packet should be pretty straightforward.

How good are packet modems at rejecting QRM?  It seems that the "capture
effect" of FM is a great boon -- it serves as built-in collision arbitration,
as long as one station is somewhat stronger than the other.

However, using packet on AM CB rigs under crowded conditions would result in
not much more than a howling mess of heterodynes, which would certainly play
havoc with modems!

:::::: Software  Productivity  Technologies   ---   Smalltalk   Project ::::::
:::::: Jan Steinman N7JDB       Box 1000, MS 60-405     (w)503/685-2956 ::::::
:::::: tektronix!tekecs!jans    Wilsonville, OR 97070   (h)503/657-7703 ::::::


11-May-87 02:57:40-EDT,1364;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 11 May 87 02:57-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7 id <[e-mail]>; Mon, 11 May 87 02:09:33 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7 id <[e-mail]>; Mon, 11 May 87 02:09:25 EDT
Received: from mcvax.UUCP by seismo.CSS.GOV (5.54/1.14) with UUCP
    id AA05950; Mon, 11 May 87 02:10:01 EDT
Received: by mcvax.cwi.nl; Mon, 11 May 87 06:19:00 +0200 (MET)
Received: by inria.inria.fr; Mon, 11 May 87 05:55:46 +0200 (MET)
Message-Id: <[e-mail]>
Received: by axis; Sun May 10 23:23:27 1987
To: [e-mail]
Date: Sun, 10 May 87 23:23:26 MET
From: Philip Peake <mcvax!axis.fr![e-mail]>
Subject: Addition to the Packet Radio mailing list

As you may know, the Ham Radio and Packet Radio NEWS groups are not
currently received in Europe.

A small group here are trying to stir up enough interest to enable us
to take these groups. In the meantime, we intend to work with a
mailing list. There is a mailing list for Europe at:

    [e-mail]

And we would like to create something similar for packet radio.
Could you add

    [e-mail]

to your packet radio mailing list please ?
It will be distributed throughout Europe from here.

Philip  (G8FVM - FC1JAS)

11-May-87 15:39:43-EDT,1336;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 11 May 87 15:39-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7 id <[e-mail]>; Mon, 11 May 87 14:28:34 EDT
Received: by EDDIE.MIT.EDU with UUCP with smail2.3 with sendmail-5.31/4.7 id <[e-mail]>; Mon, 11 May 87 14:27:43 EDT
Received: from mcvax.UUCP by seismo.CSS.GOV (5.54/1.14) with UUCP
    id AA06810; Mon, 11 May 87 14:23:22 EDT
Received: by mcvax.cwi.nl; Mon, 11 May 87 19:45:23 +0200 (MET)
Received: from idec.stc.co.uk by kestrel.Ukc.AC.UK   via PSS (UKC CAMEL FTP)
       id aa08408; 11 May 87 16:55 BST
From: Gareth Howell <[e-mail]>
Date: Mon, 11 May 87 16:49:15 GMT
Message-Id: <[e-mail]>
To: [e-mail]
Subject: axis.fr

Sorry to put this in here but axis.fr doesn't appear in ukc's routing lists.

To: [e-mail]
Hi there,
If your initiative regarding mailing lists for ham radio and packet
news groups gets off the ground, could you please add my name to the lists.
73s Gareth
----
Gareth Howell  <[e-mail]>  G6KVK @ IO91VX
ICL Network Systems, Private Networks Business Centre
London Road, Stevenage, Herts, England, SG1 1YB    Tel:[phone]
  [e-mail], idec![e-mail]


11-May-87 15:54:49-EDT,1336;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 11 May 87 15:54-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7 id <[e-mail]>; Mon, 11 May 87 14:28:34 EDT
Received: by EDDIE.MIT.EDU with UUCP with smail2.3 with sendmail-5.31/4.7 id <[e-mail]>; Mon, 11 May 87 14:27:43 EDT
Received: from mcvax.UUCP by seismo.CSS.GOV (5.54/1.14) with UUCP
    id AA06810; Mon, 11 May 87 14:23:22 EDT
Received: by mcvax.cwi.nl; Mon, 11 May 87 19:45:23 +0200 (MET)
Received: from idec.stc.co.uk by kestrel.Ukc.AC.UK   via PSS (UKC CAMEL FTP)
       id aa08408; 11 May 87 16:55 BST
From: Gareth Howell <[e-mail]>
Date: Mon, 11 May 87 16:49:15 GMT
Message-Id: <[e-mail]>
To: [e-mail]
Subject: axis.fr

Sorry to put this in here but axis.fr doesn't appear in ukc's routing lists.

To: [e-mail]
Hi there,
If your initiative regarding mailing lists for ham radio and packet
news groups gets off the ground, could you please add my name to the lists.
73s Gareth
----
Gareth Howell  <[e-mail]>  G6KVK @ IO91VX
ICL Network Systems, Private Networks Business Centre
London Road, Stevenage, Herts, England, SG1 1YB    Tel:[phone]
  [e-mail], idec![e-mail]


11-May-87 18:34:43-EDT,1045;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 11 May 87 18:34-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7 id <[e-mail]>; Mon, 11 May 87 17:02:47 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7 id <[e-mail]>; Mon, 11 May 87 17:01:53 EDT
Received: by june.cs.washington.edu (5.52.1/6.2)
    id AA23270; Mon, 11 May 87 14:02:31 PDT
Return-Path: <koning.dec.com![e-mail]>
Message-Id: <[e-mail]>
Date: 11 May 87 17:19:21 GMT
From: koning.dec.com![e-mail] (NI1D @ FN42eq)
To: [e-mail]
Subject: Re: Packet Addressing Schemes

Re. Phil's comment "names, addresses and routes are entirely separate
issues" -- that's how I meant my proposal.  Perhaps an example will
make it clearer...

    name:   G. Paul Koning
another name:   NI1D
     address:   NI1D@FN42eq
  (or maybe):   [e-mail]
       route:   beats me.  Not my problem, that's up to the switching
        network to figure out!

  paul


11-May-87 20:31:01-EDT,2360;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 11 May 87 20:30-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7 id <[e-mail]>; Mon, 11 May 87 19:12:17 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7 id <[e-mail]>; Mon, 11 May 87 19:11:37 EDT
Received: by june.cs.washington.edu (5.52.1/6.2)
    id AA08874; Mon, 11 May 87 16:12:26 PDT
Return-Path: <mnetor![e-mail]>
Message-Id: <[e-mail]>
Date: 11 May 87 17:39:07 GMT
From: mnetor![e-mail] (Jim Stewart)
To: [e-mail]
Subject: Re: PC-100 Availability
Keywords: PC-100,KA9Q,TCP/IP,IBM-PC
References: <[e-mail]> <[e-mail]>

In article <[e-mail]> [e-mail] writes:

>The PC-100 is an interface card for the IBM PC containing a Zilog 8530
>Serial Communications Controller and two AMD 7910 World Chip modems.
>was originally designed by Terry Fox, WB4JFI. Terry has sold his design
>to Paccomm in Florida, owned by Gwyn, W1BEL.
...
>documentation whether this is supposed to work or not.  Other 8530 cards
>for the PC provide special circuitry for driving the INTA pin, so it may
>be the lack of this on the PC-100 that's causing the problem.

I would not trust an 8530 interface without circuitry for driving the
INTA pin.  I once spent 4 weeks chasing a problem of losing interrupts.
That card was also for a PC and lacked a connection to the 8530 INTA pin.
The hardware designer had a test program that worked ok, and so refused
to believe there was a problem.  Unfortunately my code had to run a lot
faster than his (250 kbps using the DMA, SDLC-framing).

When I modified the board so I could poke the INTA line, via software,
my problem went away.  I never did get a good answer from the local
Zilog people, but as a result of several experiments, I believe the
internal daisy chain gets confused if while one interrupt is pending,
a second occurs.  (Kind-a makes it tough to do full-dux).  The NEC
7201 (in a way it is a distant-aunt of the 8530 :-) has a method of
poking the chip to simulate the INTA signal, if the signal is not
available.

Jim Stewart, VE3SRJ
UUCP:  {decvax|allegra|ihnp4|linus|utcsri}!utzoo!mnetor!jim
ARPA:  mnetor![e-mail]
BELL:  [phone]  ext. 303


12-May-87 00:40:23-EDT,1573;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 12 May 87 00:40-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7 id <[e-mail]>; Mon, 11 May 87 23:47:08 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7 id <[e-mail]>; Mon, 11 May 87 23:46:50 EDT
Date: Mon, 11 May 1987  21:47 MDT
Message-Id: <[e-mail]>
Sender: [e-mail]
From: Keith Petersen <[e-mail]>
To: [e-mail]
Subject: New Packet Radio files available from SIMTEL20

Thanks to Steve Ward, we now have three new files available on
SIMTEL20...

Filename                        Type     Bytes   CRC

Directory PD:<MSDOS.PACKET>
BSQ.ARC.1                       BINARY   58532  761AH
FWD.ARC.1                       BINARY   45390  82BAH
ROUTE.ARC.1                     BINARY   40170  4FFCH

(BSQ is a program which allows sending compresed binary files via
packet).

--Keith W8SDZ

--forwarded message---
Date: Monday, 11 May 1987  20:02-MDT
From: Steve Ward <[e-mail]>
To:   [e-mail]
Re:   New BSQ.ARC, etc.

Thanks, Keith, for the info.  I've uploaded:
  1) revised BSQ.ARC; adds source to what you've got.
  2) FWD.ARC: program to generate BBS forwarding file from a collection
     of source files, each containing user list for some BBS.
  3) ROUTE.ARC: program to compute best routes thru a network represented
     as an ASCII file of nodes, links, and costs.

I've got mountains of other stuff which I'll upload at some point, if you're
interested.  73 & keep up the good work!  -Steve W1GOH
12-May-87 16:45:02-EDT,2774;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 12 May 87 16:44-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7 id <[e-mail]>; Tue, 12 May 87 12:20:26 EDT
Received: by EDDIE.MIT.EDU with UUCP with smail2.3 with sendmail-5.31/4.7 id <[e-mail]>; Tue, 12 May 87 12:19:00 EDT
Received: from mcvax.UUCP by seismo.CSS.GOV (5.54/1.14) with UUCP
    id AA03807; Tue, 12 May 87 12:00:00 EDT
Received: by mcvax.cwi.nl; Tue, 12 May 87 17:39:04 +0200 (MET)
Received: from idec.stc.co.uk by kestrel.Ukc.AC.UK   via PSS (UKC CAMEL FTP)
       id aa27804; 12 May 87 14:49 BST
From: Gareth Howell <[e-mail]>
Date: Tue, 12 May 87 14:49:45 GMT
Message-Id: <[e-mail]>
To: [e-mail]
In-Reply-To: "NI1D's message of 11 May 87 17:19:21 GMT
Subject: Packet Addressing Schemes

-----
...  Perhaps an example will
   make it clearer...

       name:        G. Paul Koning
   another name:        NI1D
    address:        NI1D@FN42eq
     (or maybe):        [e-mail]
      route:        beats me.  Not my problem, that's up to the switching
           network to figure out!

     paul
------
While agreeing that your example is correct it needs to be made clear
what is meant by address. The address part of your example is correct
but could also be G6KVK@IO91vx and still be the address of NI1D.

The content of the address part depends on the level or layer that you
are addressing: network,transport, session etc. In OSI if it is a
Presentation address, which locates an application entity, then the
address is generally taken to be the Network address plus some set of
selectors to extend the address for the upper layers.  The network
address can be anything you like but is often equivalent to the DTE
address (which for OSI is usually constructed in accordance with CCITT
X.121).

The question is: what is the DTE address in a packet network?  given
that the DTE address needs to be unique within the domain covered by
that addressing scheme, I guess it is the callsign of the location
wherein the TNC sits.  I'm not sure what happens with mobile units but
this would work for alternate sites.  Possibly we need a convention
regarding the usage of SSIDs to qualify addresses. e.g. (not proposed
just for illustration!) -0 == home station, -1 == mobile, -2
==alternate.  This would ease problems with dirtectory lookup to check
if an indicated address was reachable from a particular digipeater.

wot say 73s Gareth
----
Gareth Howell  <[e-mail]>  G6KVK @ IO91VX
ICL Network Systems, Private Networks Business Centre
London Road, Stevenage, Herts, England, SG1 1YB    Tel:[phone]
[e-mail], idec![e-mail]
13-May-87 01:37:12-EDT,1639;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 13 May 87 01:37-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7 id <[e-mail]>; Tue, 12 May 87 22:39:21 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7 id <[e-mail]>; Tue, 12 May 87 22:38:59 EDT
Received: by june.cs.washington.edu (5.52.1/6.2)
    id AA00181; Tue, 12 May 87 19:39:50 PDT
Return-Path: <ihnp4!aicchi![e-mail]>
Message-Id: <[e-mail]>
Date: 12 May 87 12:02:55 GMT
From: ihnp4!aicchi![e-mail] (Burch)
To: [e-mail]
Subject: Re: Packet on CB
Summary: Low power because so many potential users.
Keywords: CB Packet QRP
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>


Well, the original reason that I suggested a 1 watt limit is because I
fully expect every teenage hacker to use the service!  Deregulation of
Ma Bell has killed the Call-Pak services that these kids often used to
call within their areas for a fixed monthly cost.  I think that it is
possible that they will be able to set up small local fido-type nets
with the short hops possible at one watt.  I would relax the power limit
for rural locations and emergency communications, of course.  I think
that at five watts the band would be so crowded that only aggressive
methods like ECC and trellis codes could punch a signal through.


--
-David B. (Ben) Burch
 Analysts International Corp.
 Chicago Branch (ihnp4!aicchi!dbb)

"Argue for your limitations, and they are yours." - R. Bach


13-May-87 16:09:02-EDT,2701;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 13 May 87 16:09-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7 id <[e-mail]>; Wed, 13 May 87 14:14:03 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7 id <[e-mail]>; Wed, 13 May 87 14:13:10 EDT
Received: by june.cs.washington.edu (5.52.1/6.2)
    id AA21546; Wed, 13 May 87 11:13:17 PDT
Return-Path: <husc6!uwvax!astroatc!prairie![e-mail]>
Message-Id: <[e-mail]>
Date: 13 May 87 13:51:02 GMT
From: husc6!uwvax!astroatc!prairie![e-mail] (Daniel M. Frank)
To: [e-mail]
Subject: Re: passwd security
References: <[e-mail]>

In article <[e-mail]> [e-mail] (Randy Suess) writes:
>... how do I implement secured logins when any
>site can monitor the reply to the password prompt?

   There is a fair amount of stuff in the comp sci literature about
authentication in unsecured networks (translate:  ALL networks).
Your problem is actually simpler than the ones discussed, believe it
or not - you only have to authenticate one end, the person logging in.

   Unfortunately, most solutions require computer assistance.  The most
common involves an encryption scheme where there is one key per user.
The public access system knows all the keys; each user knows only his
or her key.  At login time, the system sends the user a string of
garbage characters, randomly generated, and the user sends back that
string, encrypted with the user's key.  The system decrypts the response
and compares it to the original.

   The problem with this (besides the need for a computer) is that
anyone monitoring the channel has both the plain text and the
encrypted form, which makes it much easier to break the code.  Various
tricks can help with this.  For example, the public access system can
encrypt the garbage string.  Or, it can generate a random key (the
time of day, for example), encrypted with the user's key, then send
the garbage string as plain text or encrypted.  The user decodes
the random key, encodes the garbage string with it, and sends it
to the host.  The last scheme is particularly nice, since no one
ever gets plain text to compare to the encrypted strings.  The
only constant is the user's key, and the data sent under that key
changes every time.

   Maybe someone else has an idea how to make a decent scheme work
with nothing but humans on one end.

--
      Dan Frank (w9nk)
    ARPA: [e-mail]                   ATT: [phone] (home)
    UUCP: ... uwvax!prairie!dan                  [phone] (office)
    SNAILMAIL: 1802 Keyes Ave. Madison, WI 53711-2006


13-May-87 16:37:43-EDT,1070;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 13 May 87 16:37-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7 id <[e-mail]>; Wed, 13 May 87 13:22:23 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7 id <[e-mail]>; Wed, 13 May 87 13:21:26 EDT
Received: by june.cs.washington.edu (5.52.1/6.2)
    id AA10325; Wed, 13 May 87 08:27:16 PDT
Return-Path: <ihnp4!chinet!randy>
Message-Id: <[e-mail]>
Date: 12 May 87 22:22:45 GMT
From: ihnp4!chinet![e-mail] (Randy Suess)
To: [e-mail]
Subject: passwd security


    I run a public access unix system on a 3b2 and have had
a TNC connected at various times for local hams.  It was mainly
for a local conferencing system (PicoSpan), but I would now like
to arrange regular logins so they have access to this group (via rn)
and some others.  But how do I implement secured logins when any
site can monitor the reply to the password prompt?

Thanks for any suggestions..

-randy WB9GPM

13-May-87 19:04:07-EDT,572;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 13 May 87 19:04-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7 id <[e-mail]>; Wed, 13 May 87 15:25:59 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7 id <[e-mail]>; Wed, 13 May 87 15:25:27 EDT
Date:     Wed, 13 May 87 15:24:23 EDT
From: [e-mail]
To: Randy Suess <ihnp4!chinet![e-mail]>
Cc: [e-mail]
Subject:  Re:  passwd security
Message-Id:  <[e-mail]>

Randy,

See RFC-1004.

Dave
14-May-87 01:40:51-EDT,2177;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 14 May 87 01:40-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7 id <[e-mail]>; Thu, 14 May 87 00:54:00 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7 id <[e-mail]>; Thu, 14 May 87 00:53:45 EDT
Received: by june.cs.washington.edu (5.52.1/6.2)
    id AA15842; Wed, 13 May 87 21:54:19 PDT
Return-Path: <decwrl!labrea!Umunhum![e-mail]>
Message-Id: <[e-mail]>
Date: 13 May 87 18:39:03 GMT
From: decwrl!labrea!Umunhum![e-mail] (Paul A. Flaherty, N9FZX)
To: [e-mail]
Subject: Re: passwd security
References: <[e-mail]>

In article <[e-mail]> [e-mail] (Randy Suess) writes:
>
>       I run a public access unix system on a 3b2 and have had
>a TNC connected at various times for local hams.  It was mainly
>for a local conferencing system (PicoSpan), but I would now like
>to arrange regular logins so they have access to this group (via rn)
>and some others.  But how do I implement secured logins when any
>site can monitor the reply to the password prompt?
>
>Thanks for any suggestions..
>-randy WB9GPM


1) Time - Varying passwords.  The password is set to be a complex function
    of date and time.  Has a small window of vulerability.

2) Pseudo - Public Key system.  The system prints a random number, and the
    user computes a function of the number as the password.  The
    function should be as nonlinear as possible.  Function should also be
    changed weekly or so.  Both of these prevent analysis of the function
    with linear function fitting programs.

3) Use EBCDIC.

4) Design a piplined serial encryptor / decriptor pair using LFSR's.
    This is probably stretching part 97 a bit.

A STA for LFSR encryptors would be nice for those who want closed systems;
    the situation is similar to PL - type access on a closed repeater.

--
Paul Flaherty, N9FZX                                    >->-_->->
Computer Systems Lab -- Stanford University                 |           Project
ARPAnet: [e-mail]                        =====          OSCAR
AMnet: N9FZX @ N6IIU                                      =====


14-May-87 12:23:15-EDT,1203;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 14 May 87 12:23-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7 id <[e-mail]>; Thu, 14 May 87 10:52:57 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7 id <[e-mail]>; Thu, 14 May 87 10:52:36 EDT
Received: by june.cs.washington.edu (5.52.1/6.2)
    id AA07427; Thu, 14 May 87 07:53:28 PDT
Return-Path: <ihnp4!aicchi![e-mail]>
Message-Id: <[e-mail]>
Date: 14 May 87 00:30:51 GMT
From: ihnp4!aicchi![e-mail] (Burch)
To: [e-mail]
Subject: Re: passwd security
Summary: When password entry is public, only a crypto-password will do.
References: <[e-mail]>


I would suggest that you write a BASIC program that takes a user's password,
and a unique key, and the time of day, and which then transforms his password
into a string which he transmits to your system.  Your system must then
perform the inverse operation before comparing the password.


--
-David B. (Ben) Burch
 Analysts International Corp.
 Chicago Branch (ihnp4!aicchi!dbb)

"Argue for your limitations, and they are yours." - R. Bach


14-May-87 14:30:53-EDT,1894;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 14 May 87 14:30-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7 id <[e-mail]>; Thu, 14 May 87 12:31:27 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7 id <[e-mail]>; Thu, 14 May 87 12:30:55 EDT
Message-Id: <[e-mail]>
Posted-From: The MITRE Corp., Bedford, MA
To: ihnp4!chinet![e-mail] (Randy Suess)
Cc: [e-mail], [e-mail]
Subject: Re: passwd security
In-Reply-To: Your message of 12 May 87 22:22:45 +0000.
         <[e-mail]>
Date: Thu, 14 May 87 09:57:34 EDT
From: [e-mail]

One thing that you can do if your machine is not accessible over
Arpanet, Ethernet, etc. is to kluge "login" or set up a very special
.cshrc file to run a program that does one of the following two
things:

    If there is a problem, do a kill -9 0, which kills the whole
    login process.

    Transmits a bunch of numbers out over the air.  The user must
    know how to manipulate those numbers, and transmits another
    number back to the computer that is some wierd function of the
    numbers coming back to him.  The achine then compares these
    two, and lets him in if they match.


This will NOT WORK if you are a part of many other nets, since they
allow access to files (like even the .cshrc) based on password access,
which you have nulled (or brodcasted), over things like "ftp",
"telnet", "rlogin", etc..

If you get one of these running, I would be interested in the details.

If you want an example of a program to do the function generating,
please let me know, and I can send you a program that will do that.  I
can not send you a modified "/bin/login" due to license restrictions.


                    Peter Baldwin, WA1SNH
                    (ptb@mitre-bedford)
14-May-87 15:29:47-EDT,1260;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 14 May 87 15:29-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7 id <[e-mail]>; Thu, 14 May 87 13:44:38 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7 id <[e-mail]>; Thu, 14 May 87 13:44:27 EDT
Message-Id: <[e-mail]>
Received: from USU(BOBW) by MITVMA (Mailer X1.23) id 2299;
      Thu, 14 May 87 13:41:44 EDT
Date:     Thu, 14 May 87 11:41 MST
From: <[e-mail]> (BOB WOOD WA7MXZ)
Subject:  Passwords/Packet remote access
To: [e-mail]
X-Original-To:  [e-mail]

      The other things to consider are the problems generated by the FCC rules
regarding coded transmissions and the possibility that the TNC and hence the
transmiiter attached to it could be access by unlicensed parties whether that
is the computer itself or an unlicensed user. The NET/ROM design has a pass-
word system used in it and I do not know if the writers of that code have
submitted their encoding system to the FCC or not. The FCC gets nasty when
it sees a string of data that makes no sense and is not part of a computer
generated picture. Packet control operators beware!
Bob Wood WA7MXZ
14-May-87 15:44:57-EDT,2342;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 14 May 87 15:44-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7 id <[e-mail]>; Thu, 14 May 87 13:22:03 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7 id <[e-mail]>; Thu, 14 May 87 13:20:28 EDT
Received: by june.cs.washington.edu (5.52.1/6.2)
    id AA13766; Thu, 14 May 87 10:18:15 PDT
From: delni.dec.com![e-mail]
Return-Path: <delni.dec.com![e-mail]>
Message-Id: <[e-mail]>
Date: 14 May 87 15:14:17 GMT
To: [e-mail]
Subject: re: Packet Addressing Schemes

    I'd like to clarify something that Garety Howell commented on.

    In a properly designed network, only the NETWORK LAYER (3) and below
    have significance to the routers.  Whether or not there's a P-SAP,
    T-SAP, S-SAP or anything else above Layer 3 is priveleged information
    belonging only to the end-users! (This should be beated mercilessly
    into the heads of European telecom administrations and the CCITT.)

    Therefore, what Paul ni1d and I are referring to is a Network layer
    address for Packet.  Within the packet, we suggest the concatenation of
    geographical (gridsquare) and personal (callsign or service
    designation) addresses; i.e., FN42EQ_NI1D or the like.  (Exact format
    to be determined.)  In OSI, this is NOT necessarily X.121; it MAY BE
    X.121 OR it may be something else, depending upon the AFI (Authority
    and Format Identifier) which is the first byte of the address.  We are,
    of course, suggesting a new AFI (format) for ham packet.

    The higher layers may do as they wish.  So the "TELNET" equivalent
    program (or TELNET itself, if you wish) may allow you to say, "NI1D at
    FN42EQ" or "Paul Koning" or "NI1D" or whatever, and it is up to your
    computer to give it to the network according to the rules of the AFI.
    WITHIN this Network Layer envelope which is passed around by the
    network, you will have higher layer entities with addresses which
    identify the application.  It's also okay to use SSIDs in the Network
    Header (FN42EQ_NI1D-1) if you need to, but that refers to a different
    station, not a different application.
        fred k1io


15-May-87 06:59:49-EDT,4126;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 15 May 87 06:59-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7 id <[e-mail]>; Fri, 15 May 87 06:14:43 EDT
Received: by EDDIE.MIT.EDU with UUCP with smail2.3 with sendmail-5.31/4.7 id <[e-mail]>; Fri, 15 May 87 06:14:25 EDT
Received: from mcvax.UUCP by seismo.CSS.GOV (5.54/1.14) with UUCP
    id AA11293; Fri, 15 May 87 06:07:20 EDT
Received: by mcvax.cwi.nl; Fri, 15 May 87 11:56:03 +0200 (MET)
Received: from idec.stc.co.uk by kestrel.Ukc.AC.UK   via PSS (UKC CAMEL FTP)
       id aa00517; 15 May 87 10:20 BST
From: Gareth Howell <[e-mail]>
Date: Fri, 15 May 87 10:04:29 GMT
Message-Id: <[e-mail]>
To: [e-mail]
In-Reply-To: [e-mail]'s message of 14 May 87 15:14:17 GMT
Subject: re: Packet Addressing Schemes

   From: [e-mail]
...
       In a properly designed network, only the NETWORK LAYER (3) and below
       have significance to the routers.  Whether or not there's a P-SAP,
       T-SAP, S-SAP or anything else above Layer 3 is priveleged information
       belonging only to the end-users! (This should be beated mercilessly
       into the heads of European telecom administrations and the CCITT.)

I agree with your statement regarding the significance of NSAP and
lower layer SAPs but I'm not sure what you mean by privileged
information.  If you mean that the structure of the SAP address above
the network layer is the business of the end system then I agree.  If
however you mean that the *value* of the SAP address is private to the
end system then I dis-agree.

A directory function at layer (N) will translate a (N)-title to a
(N-1)-SAP. This is true regardless of the layer.  If you are implying
by your reference to CCITT that public directory functions should not
exist above Network I would like to know why not.

       Therefore, what Paul ni1d and I are referring to is a Network layer
       address for Packet.  Within the packet, we suggest the concatenation of
       geographical (gridsquare) and personal (callsign or service
       designation) addresses; i.e., FN42EQ_NI1D or the like.  (Exact format
       to be determined.)  In OSI, this is NOT necessarily X.121; it MAY BE
       X.121 OR it may be something else, depending upon the AFI (Authority
       and Format Identifier) which is the first byte of the address.  We are,
       of course, suggesting a new AFI (format) for ham packet.

Be sure that you draw a clear distinction between the NSAP and the DTE
address or SNPA; they may not be the same.
The objective of  the current work on addressing is to permit the
allocation of an NSAP to an end-system that is independent of the
network used to access that end-system.  Thus: the NSAP is the same
whether the end-system is accessed via packet, PSTN, PSDN etc. Each of
these networks will however have a different SNPA (Sub-Network Point
of Attachment) and thus DTE address. The SNPA doesn't have AFIs and
DSPs; it's the NSAP that has these.

What I was talking about was the DTE address, which is usually X.121
based for public networks.  The NSAP can use a variety of formats
depending on the circumstances of the network.  What I  hope you are
advocating would be to use the Local AFI (rather than a new AFI which
would non-conformant).
This is OK except that it would cause problems if packet were later to
be integrated with other Public networks.

Basically we need to decide how much of the OSI (etc) work we really
want to take on and how conformant we wish a resulting packet network
to be.  This can only be answered once we have some long term goals
for the packet network (I am using the term network in it's logical
not physical sense).

73s Gareth
----
Gareth Howell  <[e-mail]>  G6KVK @ IO91VX
ICL Network Systems, Private Networks Business Centre
London Road, Stevenage, Herts, England, SG1 1YB    Tel:[phone]
[e-mail], idec![e-mail]
16-May-87 06:02:25-EDT,1500;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 16 May 87 06:02-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Sat, 16 May 87 04:53:28 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Sat, 16 May 87 04:53:09 EDT
Received: by bass.nosc.mil (5.31/4.7)
    id AA05216; Sat, 16 May 87 01:53:05 PDT
Received: by crash.CTS.COM (5.54/UUCP-Project/rel-1.0/09-14-86)
    id AA21135; Sat, 16 May 87 00:36:09 PDT
Reply-To: pnet01!marct
Message-Id: <[e-mail]>
Date: Sat, 16 May 87 00:27:47 PDT
From: [e-mail] (Marc Tamsky)
To: crash![e-mail]@nosc.mil
Subject: User Verification

One of the best ones that I have seen, is using a formula

Say you login:

Symetrix 4.2 BSD  (crash)         (my system)

Username:
18 12
Password:

those #'s before are fed into the password equasion that the user has.
Then he enters the result for it

For more security, add more variables to the equasion, or add more equasions
like a separate equasion for each # to make it harder to crack...?

I read this in a book a while ago, but I never thought it could be useful?

Hope this helps.
     - Marc Tamsky                      Where there's life
                    there's hope.
ARPA: crash!marct@nosc
INET: [e-mail]
UUCP: {akgua, hplabs!hp-sdd, sdcsvax, nosc}!crash!marct
GEnie: MAXTAMSKY
BellNet: [phone]
16-May-87 06:57:14-EDT,1500;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 16 May 87 06:57-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Sat, 16 May 87 04:53:28 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Sat, 16 May 87 04:53:09 EDT
Received: by bass.nosc.mil (5.31/4.7)
    id AA05216; Sat, 16 May 87 01:53:05 PDT
Received: by crash.CTS.COM (5.54/UUCP-Project/rel-1.0/09-14-86)
    id AA21135; Sat, 16 May 87 00:36:09 PDT
Reply-To: pnet01!marct
Message-Id: <[e-mail]>
Date: Sat, 16 May 87 00:27:47 PDT
From: [e-mail] (Marc Tamsky)
To: crash![e-mail]@nosc.mil
Subject: User Verification

One of the best ones that I have seen, is using a formula

Say you login:

Symetrix 4.2 BSD  (crash)         (my system)

Username:
18 12
Password:

those #'s before are fed into the password equasion that the user has.
Then he enters the result for it

For more security, add more variables to the equasion, or add more equasions
like a separate equasion for each # to make it harder to crack...?

I read this in a book a while ago, but I never thought it could be useful?

Hope this helps.
     - Marc Tamsky                      Where there's life
                    there's hope.
ARPA: crash!marct@nosc
INET: [e-mail]
UUCP: {akgua, hplabs!hp-sdd, sdcsvax, nosc}!crash!marct
GEnie: MAXTAMSKY
BellNet: [phone]
16-May-87 12:50:24-EDT,3231;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 16 May 87 12:50-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Sat, 16 May 87 11:46:17 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Sat, 16 May 87 11:46:01 EDT
Received: by june.cs.washington.edu (5.52.1/6.2)
    id AA27464; Sat, 16 May 87 08:47:02 PDT
From: ulysses!faline![e-mail]
Return-Path: <ulysses!faline![e-mail]>
Message-Id: <[e-mail]>
Date: 14 May 87 22:28:23 GMT
To: [e-mail]
Subject: Re: passwd security
Summary: LFSRs are NOT encryption systems
References: <[e-mail]> <[e-mail]>

In article <[e-mail]>, [e-mail] writes:
> 4) Design a piplined serial encryptor / decriptor pair using LFSR's.
>       This is probably stretching part 97 a bit.
>
> A STA for LFSR encryptors would be nice for those who want closed systems;
>       the situation is similar to PL - type access on a closed repeater.

I wish you hadn't brought this up. Linear Feedback Shift Registers
(LFSRs) are already in use in the K9NG and WA4DSY amateur packet radio
modems as data randomizers. They're called "scramblers" in the
commercial world, but this word has bad connotations in the amateur
world. The purpose of a scrambler or randomizer is NOT to hide the data
being sent, but rather to change its statistics to improve the modem's
performance and to reduce co-channel interference.  In particular,
scrambling gets rid of the DC component in a long flag stream, and it
guarantees plenty of data transitions for clock recovery in the event
you're not running HDLC and you're sending long strings of 1's or 0's.
In part 97 wording, the purpose here is to facilitate communications,
not hide the meaning.

You need to know the polynomial (the taps on the shift register) being
used in order to decode a randomized data stream. Steve and Dale have
published their polynomials, so as far as I'm concerned they aren't
encrypting. However, this wouldn't be much of an encryption system even
if they tried to keep their polynomial secret. All you need is 2N bits
of the pseudo-random sequence generated by the LFSR (where N is the
number of stages in the shift register) and you can obtain the
polynomial by solving a simple linear system of equations.

Shift register feedback systems intended for encryption must use NON-linear
feedback.  The effect of this is to simulate a LFSR with an extremely long
register, so long that the attack just mentioned isn't practical.

Based on the available public information about the secret NSA
algorithms now being recommended for the replacement of DES I think it's a
good bet that they're based on nonlinear feedback shift registers. I say
this because they're stream ciphers and they run much faster than DES in
hardware. NSA also claims that you have to get your keys from them in
order to guarantee security (!) because constructing a "good" key
requires special knowledge of the algorithm. All this is consistent with
the nature of non-linear feedback shift register algorithms.

Phil


16-May-87 12:50:38-EDT,2528;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 16 May 87 12:50-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Sat, 16 May 87 11:44:13 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Sat, 16 May 87 11:43:59 EDT
Received: by june.cs.washington.edu (5.52.1/6.2)
    id AA27433; Sat, 16 May 87 08:44:34 PDT
From: ulysses!faline![e-mail]
Return-Path: <ulysses!faline![e-mail]>
Message-Id: <[e-mail]>
Date: 14 May 87 22:38:58 GMT
To: [e-mail]
Subject: Re: Packet on CB
Summary: How about spread spectrum packet on 27 mhz?
Keywords: CB Packet QRP
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>

One very real possibility is to use direct sequence spread spectrum
(DSSS) on 27 mhz.  Several years ago Mitre Corporation did an excellent
study for the FCC entitled "Civilian Uses of Spread Spectrum". (I
obtained my copy through NTIS). They concluded that existing means of
carving up spectrum (frequency division multiple access, FDMA, and time
division multiple access, TDMA) were much more efficient than code
division multiple access (spread spectrum), so that spread spectrum
didn't make any sense except where its special properties (jam
resistance, low probability of intercept, multipath resistance, etc)
were needed. However, there were two cases where the civilian use of
spread spectrum DID make sense.

The first is narrowband data at microwave frequencies where the overhead
due to guard bands would otherwise be very high.  The second, which is
relevant to this discussion, is the use of "garbage" spectrum otherwise
useless for communications because of interference. In particular they
mentioned the "ISM" (Industrial, Medical and Scientific) bands used for
such things as diathermy machines, microwave ovens and CITIZENS BAND.
(Yes, 27 Mhz is an ISM band. So is our new 902-928 Mhz amateur band.)

With enough coding gain one can use spread spectrum without detection
(which is why the military likes it so much). If the FCC can't tell that
a transmitter is there, how can it enforce its licensing requirements? I
think it will be VERY interesting to watch what happens as as spread
spectrum equipment becomes more widely available. Who knows, there could
be bootleggers running it now on communications satellites without their
owners even knowing it is there.

Phil


16-May-87 12:55:19-EDT,1621;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 16 May 87 12:55-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Sat, 16 May 87 11:54:16 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Sat, 16 May 87 11:54:02 EDT
Resent-Message-Id: <[e-mail]>
Date: Thu, 14 May 87 18:50:15 +0300
Message-Id: <[e-mail]>
Sender: Ofer Lapid 4X6OJ <[e-mail]>
From: Ofer Lapid 4X6OJ <[e-mail]>
To: [e-mail]
Subject:   Wanted: COSI software.
Resent-From: [e-mail]
Resent-To: [e-mail]
Resent-Date: Sat 16 May 1987 09:54-MDT

I am very sorry to interfere with you're week-end ham-chat but
I don't have a way to directly address Howie N2WX.

Here in 4X land we are trying to evaluate several packet-radio
network implementations.

We got the  TCP/IP package but haven't heard yet from the ham
whos incharge of assigning address blocks - and we do not intend
to use pirate addresses.

In the meanwhile we would like very much to receive the COSI
implementation ( sources will be appreciated too ) as we have
many Apple , Commodore and Mac users who will be left out of the
TCP experiment.

So, Howie, if you read this, or anyone who can forward this message
to him or to the person who can help us Please Do.

73 and thank you very much.
DE 4X6OJ, from the 4XNET PAcket Radio Group.

Bitnet:   <[e-mail]>
Internet: <[e-mail]>
16-May-87 13:20:49-EDT,3626;000000000001
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 16 May 87 13:20-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Sat, 16 May 87 12:19:50 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Sat, 16 May 87 12:19:39 EDT
Received: by june.cs.washington.edu (5.52.1/6.2)
    id AA27890; Sat, 16 May 87 09:20:42 PDT
From: ulysses!faline![e-mail]
Return-Path: <ulysses!faline![e-mail]>
Message-Id: <[e-mail]>
Date: 13 May 87 06:42:46 GMT
To: [e-mail]
Subject: Password security on packet radio

Randy,

You're absolutely right about passwords being useless on the air. Much the
same is true in our present Ethernet environments at work.  Things hold
together only because the two environments are (at least at present)
relatively benign.  But problems are inevitable, so I've been thinking about
ways to be ready.  I have a paper in preparation for the ARRL Computer
Networking Conference in August on the subject of on-air authentication.

I've been experimenting with a few schemes based on the NBS data encryption
standard, DES. I have one in operation now on my Sun workstation that I
have on the air.

It works like this.  You give your user name. The system generates a 64-bit
"challenge" consisting of the time of day in hexadecimal.  You are expected
to encrypt this value using DES and send the result back. The system does
the same and compares answers. If they match, you're in.  The DES key is
known by only you and the system; it is never sent over the air.  Someone
overhearing this exchange would not be able to make use of your response
since the challenge (and the correct response) is always different. This is
the reason for using the time of day as the challenge; it never repeats.

The security of these scheme is based on the resistance of DES to a "known
plaintext" attack. That is, given a 64-bit plaintext word (i.e., the
challenge) and its corresponding encrypted value (the response), there is no
known way to determine the key that was used (and hence to be able to
generate correct responses to future challenges) short of trying every
possible key until you find the one that works.

Just in case anybody's wondering, as far as I'm concerned this scheme does
not violate the prohibition on codes and ciphers. Its purpose is to
authenticate a user, not to hide information.  The "information" in the
encrypted response (the time of day) has already gone out over the air in
plaintext.  Authentication is something the FCC certainly appreciates, given
the weight they've given in the past on repeater control link security and
the like.

This scheme is still vulnerable in that someone could "take over" the channel
once you've logged in.  I have a more secure (but more elaborate) scheme
that authenticates each and every packet sent over the air by computing
a "cipher checksum" (again using DES). This would work nicely in TCP/IP,
but probably not with "vanilla" AX.25 for reasons I discuss in the paper.

I've posted source code for the secure login command to mod.sources.  It is
still quite experimental and clumsy to use, since the user is expected to do
the DES calculation himself (with a MS-DOS program included for the purpose)
and type the result back. Eventually I would like to build this into my
net.exe program so it all happens automagically.

The stuff on mod.sources also includes some general purpose DES stuff which
of course you can't use on the air.

Phil


17-May-87 12:55:40-EDT,1683;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 17 May 87 12:55-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Sun, 17 May 87 11:50:09 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Sun, 17 May 87 11:49:56 EDT
Received: by june.cs.washington.edu (5.52.1/6.2)
    id AA17225; Sun, 17 May 87 08:50:48 PDT
From: ihnp4!inuxc!iuvax!wa8ejh![e-mail]
Return-Path: <ihnp4!inuxc!iuvax!wa8ejh![e-mail]>
Message-Id: <[e-mail]>
Date: 17 May 87 01:23:05 GMT
To: [e-mail]
Subject: 10 meter packet

I've been on 2 meter packet for a couple of years now and would like to operate
on 10 meters too.  As I understand the FCC rules, the standard 1200 baud TNC
using Bell 202 tones is allowed on 10 meters (into an SSB rig to produce FSK).
If I am wrong about this, I hope someone will say so.  I haven't heard anything
that sounds like 1200 baud packet on 10 meters yet so I thought I'd better ask.
Maybe I haven't listened at the right time or on the right frequencies.  If
1200 baud packet is already alive on 10 meters, to what frequencies should I
tune to join in?  I'd like to put my UNIX system on the air on 10 meters as
well as on 2 meters.  Do I have to restrict access to usenet below 30 MHz or
do I just have to manually screen all the news before letting it be read over
the air (what a pain!)?  Thanks for any advice.

                Larry Meehan (WA8EJH)

                packet: lwm @ wa8ejh
                uucp:   {ihnp4,seismo,cbosgd}!iuvax!wa8ejh!lwm
                ARPA:   [e-mail]
                csnet:  lwm%wa8ejh@indiana


17-May-87 12:56:20-EDT,2517;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 17 May 87 12:56-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Sun, 17 May 87 11:52:22 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Sun, 17 May 87 11:52:10 EDT
Received: by june.cs.washington.edu (5.52.1/6.2)
    id AA17238; Sun, 17 May 87 08:53:16 PDT
Return-Path: <tektronix!tekcrl!tekfdi![e-mail]>
Message-Id: <[e-mail]>
Date: 17 May 87 04:13:55 GMT
From: tektronix!tekcrl!tekfdi![e-mail] (Mike Horne)
To: [e-mail]
Subject: Re: User Verification
References: <[e-mail]>

In a recent article, Marc Tamsky writes:
>One of the best ones that I have seen, is using a formula
>
>Say you login:
>
>Symetrix 4.2 BSD  (crash)         (my system)
>
>Username:
>18 12
>Password:
>
>those #'s before are fed into the password equasion that the user has.
>Then he enters the result for it...

I had a packet bbs on my SUN II back at WSU, and in order to let selected
users obtain a shell, I had a mini-verification scheme along these lines.
Essentially the bbs program would generate a number based upon the current
time (ala gettimeofday(2)) fed through a big-n-ugly equation.  The user
on the other end would take this number and pump it through another big-n-ugly
equation (nice to have a calculator/computer handy!) to get the `password.'
Fairly easy to implement, but not fool-proof.  It worked great where I was,
but I had a limited number of users (oh, 20 or so locals, of which only
4 had shell access).

One other possibility:  Assuming you have root access on the UNIX beast you
are allowing packet users on, there is nothing keeping you from setting up
a special `account' where a chroot(2) is performed to some directory where
a user could do minimal damage.  Also, there are pseudo-terminals you can
use to control what the user does (you get to check everything s/he types).
In other words, there are lots of ways around your dilemma.

Good luck, and more importantly, have fun!

                             -mth

--
____________________________________________________________________________
Michael Horne - KA7AXD                  UUCP:  tektronix!tekfdi!honda!mhorne
FDI group, Tektronix, Incorporated      ARPA:  [e-mail]
Day: [phone]                     AMNET: ka7axd@k7ifg


18-May-87 23:40:26-EDT,2116;000000000001
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 18 May 87 23:40-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Mon, 18 May 87 22:41:25 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Mon, 18 May 87 22:40:17 EDT
Received: by june.cs.washington.edu (5.52.1/6.2)
    id AA02582; Mon, 18 May 87 19:39:45 PDT
Return-Path: <rutgers!princeton!idacrd![e-mail]>
Message-Id: <[e-mail]>
Date: 18 May 87 17:01:13 GMT
From: rutgers!princeton!idacrd![e-mail] (Bob McGwier)
To: [e-mail]
Subject: Re: Password security on packet radio
References: <[e-mail]>

> You're absolutely right about passwords being useless on the air. Much the
> same is true in our present Ethernet environments at work.  Things hold
> together only because the two environments are (at least at present)
> relatively benign.  But problems are inevitable, so I've been thinking about
> ways to be ready.  I have a paper in preparation for the ARRL Computer
> Networking Conference in August on the subject of on-air authentication.
>
> I've been experimenting with a few schemes based on the NBS data encryption
> standard, DES. I have one in operation now on my Sun workstation that I
> have on the air.

This is also in reply to the message that Phil posted addressing the
questions concerning LSR's as encryption devices.  The present rules in
part 97 only allow a handful of Linear shift register polynomials.  If
you desire to encrypt "information" with some other polynomial you will
need an STA from the FCC.  However I strongly discourage your use of a
Linear shift register even in places where it is legal like the
telephone.  You may safely equate the word linear with EASY !!!

that is easy factorial factorial factorial.

Given 2N ungarbled bits where the register is N long is enough to do you
in.  Nonlinear feedback shift registers are more secure and you can bet
your "booty" will never be legal on the ham bands.

Bob N4HY
18-May-87 23:42:27-EDT,1177;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 18 May 87 23:42-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Mon, 18 May 87 22:37:23 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Mon, 18 May 87 22:37:08 EDT
Received: by june.cs.washington.edu (5.52.1/6.2)
    id AA02539; Mon, 18 May 87 19:38:09 PDT
Return-Path: <rutgers!princeton!idacrd![e-mail]>
Message-Id: <[e-mail]>
Date: 18 May 87 16:51:05 GMT
From: rutgers!princeton!idacrd![e-mail] (Bob McGwier)
To: [e-mail]
Subject: TCP/IP addresses

To those hams needing IP addresses.  (In particular the gentlemen from
Israel) Your messages posted here will  be forwarded by me to Wally
Myabe the delay is my fault.  I kinda jumped on them for presuming to
assign IP addresses to hams in Europe, the middle East, etc without
first consulting with you.  Until that time, I don't think GOOD records
were kept of just who had the code.  I will do my best to help you get
that IP address since I might be the cause of the delay.  Sorry :-)

Bob


19-May-87 21:07:28-EDT,923;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 19 May 87 21:07-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Tue, 19 May 87 19:28:23 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Tue, 19 May 87 19:28:10 EDT
Date: 19 May 87 13:04 EDT
From: (David HM Spector) <[e-mail]>
To: <[e-mail]>
Subject: please remove...
Message-Id: <[e-mail]>
Organization: New York University/Academic Computing Facility Systems Group
Office:         Rm 329, Warren Weaver Hall, Courant Institute of Mathematical Sciences
Address: 251 Mercer Street, NY, NY 10012
Work-Phone: [phone]
Network-Address(Es): Spector@NYU, or ...!{siesmo,allegra}!cmcl2!cmcl1!spector
Mcimail-Address: DSpector (ID: 234-3606)


Please remove this addresss from the list.

Thanks.

-------
20-May-87 06:14:14-EDT,1705;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 20 May 87 06:14-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Wed, 20 May 87 05:38:14 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Wed, 20 May 87 05:37:46 EDT
Received: by june.cs.washington.edu (5.52.1/6.2)
    id AA01039; Wed, 20 May 87 02:38:33 PDT
Return-Path: <cbosgd!osu-eddie![e-mail]>
Message-Id: <[e-mail]>
Date: 19 May 87 19:07:42 GMT
From: cbosgd!osu-eddie![e-mail] (Mark A. Verber)
To: [e-mail]
Subject: Re: passwd security
References: <[e-mail]> <[e-mail]> <[e-mail]>


It would seem to me that a public key crypto-system would be perfect
for this kind of application.  You could query the machine for its
public key, encrypt your password using that key and then transmit
your encrypted password.  The machine which you are trying to access
then decodes your password with it's private key and verifies login.

The primary problem with using a public key system is selecting which
method to use.  The best method is RSA, but RSA is patented and cost
mega bucks.  Knapsack could be used, but it has been broken.  This
might not be too much of a problem though since super secure
communications is not needed, it would be on packet radio if security
was important.

Cheers,
-----------------------------------------------------------------------
Computer Science Department                              Mark A. Verber
The Ohio State University                        [e-mail]
[phone]                               cbosgd!osu-eddie!verber


20-May-87 21:45:24-EDT,1507;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 20 May 87 21:45-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Wed, 20 May 87 19:40:36 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Wed, 20 May 87 19:39:39 EDT
Received: by june.cs.washington.edu (5.52.1/6.2)
    id AA20775; Wed, 20 May 87 16:08:26 PDT
Return-Path: <koning.dec.com![e-mail]>
Message-Id: <[e-mail]>
From: koning.dec.com![e-mail] (NI1D @ FN42eq)
To: [e-mail]
Subject: Re: Password security on packet radio
Date: 20 May 87 18:11:08 GMT

Re. Bob N4HY's comment about "present rules in part 97 only allow a
handful of LSRs" -- I think that's a misinterpretation.  The LSRs
mentioned in part 97 occur in a set of rules about Spread
Spectrum, and constrain the kind of pseudo-random sequences you
can use in generating such signals.  As far as I can tell, part 97
says nothing at all about ANY authentication mechanism, whether
it's passwords, DES, or sequences of Touchtone signals.

I'd go along with Phil's comment that use of encryption for authentication
cannot be "encrypting information to hide it" because you're not
hiding anything.  Then again, reading some of the hoopla recently
about an FCC monitoring office not even being able to deal with a
simple UUCPENCODE makes you wonder how to get this sort of point
across.

    paul  ni1d


21-May-87 10:21:42-EDT,5195;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 21 May 87 10:21-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Thu, 21 May 87 07:44:20 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Thu, 21 May 87 07:43:53 EDT
Message-Id: <[e-mail]>
Received: by AMC-HQ via xmm1;  21 May 87 7:36 EDT
Date:     21 May 87 7:33:36-EDT (Thu)
From: Dbennett@xmm-plexus01
To: [e-mail]
Subject:  Current NETROM Listing

Subject: NetRom Node List as of 5/17/87
     by  WA6YBT Harrisburg, PA

Here's a list of the 112 NET/ROMs sent out so far.  In most cases, we don't
know the actual node site, so the locations listed are mostly the QTHs
of the owners and/or control operators.

Owner or Control Operator      Location          Node Callsign(s)
=========================  ====================  ==================
ARRL Headquarters  W1AW    Newington         CT  W1AW    -5,-6,-7
Andrew Demartini   KC2FF   Clearwater        FL  KC2FF   -6,-7
Mt Beacon ARC      WB2KMY  Wappingers Falls  NY  WB2KMY  -1,-11,-12
Joseph Maunino     W2NV    Palisades Park    NJ  W2NV    -6,-7
Mark Herson        N2MH    College Point     NY  WB2QBP  -6,-7
Tom Clark          W3IWI   College Park      MD  W3IWI   -5,-10
Thomas Teel        KB3UD   East Bangor       PA  KB3UD   -1,-8
Rich Zwirko        K1HTV   Glenn Dale        MD  WA3YMH  -1
Bob McGwier        N4HY    Warren            NJ  N4HY    -1
Sarasota ARC       W4IE    Venice            FL  W4IE    -0,-1
Richard Kronick    WD4JEJ  Charleston        SC  WD4JEJ  -3,-8
Hadron, Inc.       N4JFS   Chantilly         VA  N4JFS   -1,-2
Alex Evonosky      KB4LBX  Tampa             FL  KB4LBX  -1,-2
Gerald Gruenbaum   K4GFW   Sunrise           FL  WA4LZR  -1,-2
Hadron, Inc.       K4UW    Chantilly         VA  K4UW    -2,-3,-4,-5
Ed Webb            W4FQM   Hollywood         FL  WA4WHD  -2,-3
Edmond Falkowski   KC5DD   Albuquerque       NM  KC5DD   -1
Shelton McAnelly   KD5SL   Baton Rouge       LA  KD5SL   -1
Vernon Reinke      N6AFT   Fortuna           CA  N6AFT   -1
Greg Campbell      WB6ASR  San Francisco     CA  W6AMT   -0,-10
Greg Campbell      WB6ASR  Paso Robles       CA  W6AMT   -1,-11
Pete Bickerdike    WB6DAO  Santa Barbara     CA  W6AMT   -2
Mike Pettus        WD6E    Palos Verdes      CA  W6AMT   -3
Mike Pettus        WD6E    San Diego         CA  W6AMT   -4
Mike Pettus        WD6E    Santiago Peak     CA  W6AMT   -5
Greg Campbell      WB6ASR  Red Bluff         CA  W6AMT   -7,-8
Roy Wysling        KA6EYH  Pacifica          CA  KA6EYH  -1
Brian Westfall     K6OJM   Mountain View     CA  WB6FFC  -1
Bob Buaas          K6KGS   San Diego         CA  K6KGS   -1
Robert Buzzard     W6LOH   Palo Alto         CA  W6LOH   -7,-8
Dennis Humphrey    WA6RDH  Mt. Vaca          CA  WA6RDH  -1
William Martin     WA6SBV  Canoga Park       CA  WA6SBV  -1,-11
Tom King           KA6SOX  Santa Barbara     CA  KA6SOX  -1
Terry Neal         AA6TN   Big Bear          CA  AA6TN   -1
Sulphur Mtn RA     WA6ZSN  Ventura           CA  WA6ZSN  -3,-13
N.W. Am Pkt RA     WB7FHC  Gig Harbor        WA  WN7ANK  -7,-8
Joe Oliver         WB7BNI  Phoenix           AZ  WB7BNI  -1,-6,-11,-15
AEA, Inc.          N7BTI   Lynnwood          WA  N7BTI   -3,-4
Joe Oliver         WB7BNI  Phoenix           AZ  KE7CZ   -1
N.W. Am Pkt RA     WB7FHC  Gig Harbor        WA  KB7DZ   -7,-8
Scott Cronk        N7FSP   San Jose          CA  N7FSP   -1,-10
Joe Oliver         WB7BNI  Phoenix           AZ  W7GNP   -1,-6
Dan Ransom         K7MM    Riverton          WY  K7MM    -5
Tom Cain           WB8OUE  Morrisville       NC  WB8OUE  -6,-7,-8,-9
Jeffrey White      WD8OXK  Athens            OH  WD8OXK  -1
Emmett Earley Jr   WA8USO  Ravenswood        WV  WA8USO  -1,-2
A.C.V. Elston      WA9FIO  La Crosse         WI  WA9FIO  -1
Phil Karn          KA9Q    Warren            NJ  KA9Q    -1
John Russell       WB9RNW  Mt. Rasno         CA  WB9RNW  -2
John Russell       WB9RNW  Mt. Wilson        CA  WB9RNW  -3
C. R. Bergstedt    K9VXW   Naperville        IL  K9VXW   -1,-2
Doug Halbert       K0BOY   Omaha             NE  K0BOY   -1,-5
Stephen Carter     K0GUZ   Rifle             CO  K0GUZ   -1,-2
Sam Selders        W0HJX   Greely            CO  W0HJX   -1
Robert Dubke       K0SIR   Rochester         MN  W0MXW   -1
Mike Nickolaus     NF0N    S. Sioux City     NE  NF0N    -1,-5
Dave Moore         KZ0S    Edina             MN  WA0NLP  -1
William LeBaron    W0MTK   Fruita            CO  W0RRZ   -1
Rick Whiting       W0TN    Minnetonka        MN  W0TN    -1,-2
Alvin Groff        K0VM    Cedar Rapids      IA  K0VM    -1
J. H. Kambayashi   JH3XCU  Tokyo          JAPAN  JH3XCU  -4,-5
Kjell Karlberg     LA5PR  Skien          NORWAY  LA5PR   -0
Kjell Karlberg     LA5PR  Skien          NORWAY  LA9PR   -0
Kneisner&Doering   DB0FC  Braunschweig WGERMANY  DB0FC   -0,-7
Kneisner&Doering   DB0FC  Braunschweig WGERMANY  DB0FD   -0,-7
Kneisner&Doering   DB0FC  Braunschweig WGERMANY  DB0FE   -0,-7
Kneisner&Doering   DB0FC  Braunschweig WGERMANY  DD6CV   -0

21-May-87 14:15:28-EDT,1733;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 21 May 87 14:15-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Thu, 21 May 87 12:22:35 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Thu, 21 May 87 12:22:16 EDT
Message-Id: <[e-mail]>
Received: from relay2.cs.net by RELAY.CS.NET id aa10130; 21 May 87 10:54 EDT
Received: from pitt by RELAY.CS.NET id aa01225; 21 May 87 10:47 EDT
Received: by pitt (5.51/4.7)
    id AA00891; Thu, 21 May 87 09:03:47 EDT
From: Bob Hoffman <[e-mail]>
To: [e-mail]
Date: Thu, 21 May 87 9:03:45 EDT
Subject: Re: Password security on packet radio
X-Mailer: ELM [version 1.2a]

> I'd go along with Phil's comment that use of encryption for authentication
> cannot be "encrypting information to hide it" because you're not
> hiding anything.  Then again, reading some of the hoopla recently
> about an FCC monitoring office not even being able to deal with a
> simple UUCPENCODE makes you wonder how to get this sort of point
> across.
>
>       paul  ni1d

I believe there's little that can be done to keep non-textual data from
being mis-interpreted by an FCC monitor.  A common-sense policy should
be followed.  If you are sending non-textual data, be prepared to prove
that the contents of the message are whatever you claim them to be.  If
they are a program, be able to demonstrate it.  If they are a bit-mapped
picture, be able to display it.  After all, one man's binary file is
another man's encrypted data.  It's just your word against theirs, so
you had better be able to prove your point.

    ---Bob.


21-May-87 19:36:19-EDT,714;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 21 May 87 19:36-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Thu, 21 May 87 17:17:28 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Thu, 21 May 87 17:17:07 EDT
Message-Id: <[e-mail]>
Received: from ISUMVS(F1.GLS) by MITVMA (Mailer X1.23) id 8081;
      Thu, 21 May 87 17:10:11 EDT
Date:      Thu, 21 May 87 16:09:11 CDT
To: <[e-mail]>
From: "George Skank" <F1.GLS@ISUMVS>

     Please remove my name from the Packet Radio Mailing List.
            Thank you
            George Skank at ISU


21-May-87 21:13:58-EDT,739;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 21 May 87 21:13-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Thu, 21 May 87 17:53:13 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Thu, 21 May 87 17:52:55 EDT
Message-Id: <[e-mail]>
Received: from ISUMVS(F1.GLS) by MITVMA (Mailer X1.23) id 8170;
      Thu, 21 May 87 17:43:15 EDT
Date:      Thu, 21 May 87 16:31:59 CDT
To: <[e-mail]>
From: "George Skank" <F1.GLS@ISUMVS>

     Please remove my name from the Packet-Radio mailing list.
          Thanks,
               George Skank
         f1.gls at ISUMVS

22-May-87 13:50:39-EDT,1133;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 22 May 87 13:50-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Fri, 22 May 87 11:56:52 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Fri, 22 May 87 11:56:35 EDT
Message-Id: <[e-mail]>
Received: from TRIUMFCL(BENNETT) by MITVMA (Mailer X1.23) id 0784;
      Fri, 22 May 87 11:50:31 EDT
Date:     Fri, 22 May 87 08:51 PST
From: <[e-mail]>
Subject:  All- mode TNCs
To: [e-mail]
X-Original-To:  "[e-mail]", BENNETT


I am considering buying a Kantronics KAM or AEA PK232 all_mode TNC,
and would be interested in hearing any comments or user reports on these
units, either pro or con.

With the discussions of new protocols here, I wonder if using one of these
may cause problems in the future?  I would like an all-mode unit so I can
do RTTY (and even Morse) without too much of a cabling and switching tangle.


Peter Bennett  VE7CEI
4577 West 5th Ave.
Vancouver, B.C., Canada
V6R 1S6

23-May-87 00:47:37-EDT,1475;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 23 May 87 00:47-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Sat, 23 May 87 00:07:22 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Sat, 23 May 87 00:06:48 EDT
Received: by june.cs.washington.edu (5.52.1/6.2)
    id AA09767; Fri, 22 May 87 20:41:33 PDT
Return-Path: <koning.dec.com![e-mail]>
Message-Id: <[e-mail]>
Date: 22 May 87 19:14:54 GMT
From: koning.dec.com![e-mail] (NI1D @ FN42eq)
To: [e-mail]
Subject: Re: Password security on packet radio

I agree that if you transmit "strange looking" data you'd better be
able to demonstrate what it is.  Something else worth considering would
be to insert a brief statement of what it is and how it's encoded for
transmission at start and finish.

What I was getting at, though, was the rumor that the person in question
did exactly that, and then was told by the FCC that his unencoded file
couldn't be the same as the encoded one since they were DIFFERENT LENGTH!
(Never mind that that's the natural outcome and in fact part of the
purpose of UUCPENCODE and friends.)  Now it's possible that the story
was overblown, if so please ignore this.  But if it's true, then it
will take a fair amount of educating people who currently don't quite
understand the subject...

    paul


23-May-87 12:41:41-EDT,3034;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 23 May 87 12:41-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Sat, 23 May 87 12:00:21 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Sat, 23 May 87 12:00:08 EDT
Received: by june.cs.washington.edu (5.52.1/6.2)
    id AA15312; Sat, 23 May 87 09:01:47 PDT
Return-Path: <rutgers!ames!hc!beta!cmcl2!philabs!westpt![e-mail]>
Message-Id: <[e-mail]>
Date: 22 May 87 11:18:49 GMT
From: rutgers!ames!hc!beta!cmcl2!philabs!westpt![e-mail] (Bill Gunshannon)
To: [e-mail]
Subject: Re: Password security on packet radio
Summary: something rotten in Denmark
References: <[e-mail]>

In article <[e-mail]>, [e-mail] (Bob Hoffman) writes:
> I believe there's little that can be done to keep non-textual data from
> being mis-interpreted by an FCC monitor.  A common-sense policy should
> be followed.  If you are sending non-textual data, be prepared to prove
> that the contents of the message are whatever you claim them to be.  If
> they are a program, be able to demonstrate it.  If they are a bit-mapped
> picture, be able to display it.  After all, one man's binary file is
> another man's encrypted data.  It's just your word against theirs, so
> you had better be able to prove your point.

I don't see how you can be prepared to demonstrate every program
stored on every BBS just to prove a point.  Most of the BBS's are
on XEROX-820's and of course PC's.  I have seen a number of programs
for APPLE ][ computers on the BBS's around here.  Now, according to
what you are saying we must either see to it that all BBS SYSOP's
have an APPLE ][ to demonstrate that the programs are what they say
they are or we will have to take of all the software that runs on
machines other than what the SYSOP happens to own.  Who looses in
this case.  What happened to innocent until proven guilty.

Now if you are wondering why I decided to rant and rave about this
particular incident it's because I'm wondering if this isn't the same
BBS that the Belfast, ME monitoring station tried to cite for having
commercial messages when they put on a message saying they were looking
for repeater parts like a duplexer?  Maybe the investigation needs to be
the Belfast, ME monitoring station and not the packet BBS system.

If anybody still has a copy of the old message about the commercial
message complaint I would appreciate e-mail.  I'm just trying to
satisfy my curiosity.  I doubt that any action would be taken against
the monitoring station even if they are trying something funny.

73's

bill gunshannon


UUCP:      {philabs,phri}!westpt!bill        PHONE:     [phone]
US SNAIL:  Martin Marietta Data Systems      RADIO:     KB3YV
       USMA, Bldg 600, Room 26           AX.25      KB3YV @ WA2RKN
       West Point, NY  10996


25-May-87 16:39:11-EDT,873;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 25 May 87 16:39-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Mon, 25 May 87 15:43:52 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Mon, 25 May 87 15:43:39 EDT
Message-Id: <[e-mail]>
Received: from NJECNVM(H156004) by MITVMA (Mailer X1.23) id 5934;
      Mon, 25 May 87 14:08:00 EDT
Date: 25 May 87   13:45 EDT
From: [e-mail]
To: [e-mail]
Subject: BITNET mail follows

I HAVE A FRIEND WHO WANTS TO USE AN H/Z100 ON PACKET RADIO. HE'S
BEEN UNABLE TO FIND A PACKET TERMINAL PROGRAM (LIKE YAPP) FOR IT.
IF ANYONE KNOWS OF ONE FROM ANY SOURCE, PLEASE REPLY.

KEN TOMPKINS -- WB2PUW @ WB2DRD-2
STOCKTON STATE COLLEGE (NEAR ATLANTIC CITY)

THANKS AND 73.
26-May-87 07:58:25-EDT,2768;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 26 May 87 07:58-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Tue, 26 May 87 07:25:43 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Tue, 26 May 87 07:25:30 EDT
Return-Path: <[e-mail]>
Received: by gateway.mitre.org (5.54/SMI-2.2)
    id AA03539; Tue, 26 May 87 07:29:35 EDT
Received: by jupiter.mitre.org (1.1/SMI-3.0DEV3)
    id AA24975; Tue, 26 May 87 07:29:07 EDT
Date: Tue, 26 May 87 07:29:07 EDT
From: [e-mail]
Message-Id: <[e-mail]>
To: [e-mail], delni.dec.com![e-mail]
Subject: re: Packet Addressing Schemes

>  .........    In OSI, this is NOT necessarily X.121; it MAY BE
>  X.121 OR it may be something else, depending upon the AFI (Authority
>  and Format Identifier) which is the first byte of the address.  We are,
>  of course, suggesting a new AFI (format) for ham packet.

You do not necessarily need to get a new AFI.  You can get address space
from a number of places and do what you want with it.  I imagine that
getting a new AFI would be a difficult thing to do anyway.

All you need to do is get some chunk of address
space from an existing AFI/IDI (Initial Domain Identifier).  For instance,
the USA has a chunk of the AFI meaning Data Country Codes.  The IDI for
that is 840.  It is being discussed now how to further hand out addresses
to users in the USA, but the current idea is to assign an additional three
bytes to groups (or individuals, I suppose) in the USA.  If ham-radio got
some of this address space, then the first part of every ham address would
be <39,840,XXX,whatever the ham people decide>.  If you are quick, you might
be able to spell out HAM in ascii for those first three bytes.

Anyway, what you do with the remaining bytes is entirely your business.
The initial 39 indicates that the rest of the address should be read as
bits, as opposed to BCD (38 means BCD, if I remember correctly), but that
should cause no problem.  If you want to actually encode your addresses
as ascii, and have your machines read them that way, you may do so.  All
you are really obligated to do is make sure all of your addresses are
unique.



As an aside, I am the editor of a routing architecture in the ANSI
network layer standards group, X3S3.3.  I will have that available
on the net fairly soon.  It contains lots of different things, including
principles of addressing for routing purposes.
If anyone in the ham world would like a
copy, let me know.


    Paul Tsuchiya           [e-mail]
    The MITRE Corp.         [e-mail]

26-May-87 13:24:58-EDT,8814;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 26 May 87 13:24-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Tue, 26 May 87 11:10:20 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Tue, 26 May 87 11:09:14 EDT
Received: by june.cs.washington.edu (5.52.1/6.2)
    id AA18443; Tue, 26 May 87 08:10:05 PDT
Return-Path: <crash!winfree![e-mail]>
Message-Id: <[e-mail]>
Date: 26 May 87 07:49:35 GMT
From: crash!winfree![e-mail] (Bdale Garbee)
To: [e-mail]
Subject: new release of KA9Q TCP/IP package


Announcing an update to the KA9Q TCP/IP software package release of 870412.0,
bringing the current release date up to 870526.0.  This update adds many new
features, and fixes bugs.

The changes:
    - a fix to the TNC-1 KISS from Marc Kaufman.

    - a romable version of KISS for the TNC-1 from Marc Kaufman.

    - a new piece of documentation called HOWTO.DOC from Brian Lloyd,
      that takes you from receipt of some floppies to a working
      NET.EXE setup.  The remainder of the documentation is under
      rewrite at several locations.  If you have any changes or additions,
      please forward them back to me and I'll get them included in
      "the next release".

    - major enhancements to BM from Gerard PA0GRI in Gouda, Holland.
      Minor tweaks also from Bdale, along with updated documentation.

    - addition of uuencode and uudecode programs written by PA0GRI to the
      bm sources, on the off chance that you find a need to send binary
      data via BM.... FTP being strongly recommended where available!

    - '=' replaced with '==' several places in smtpcli.c [red face], thanks
      to WB6RQN for bringing this to my attention.

    - hardwired 1024 in smtpcli.c's open_tcp() replaced with tcp_window as
      set by the user.

    - code added to smtpserv.c to strip ctrl/z in message body.  This was
      a problem for sites using grody editors to enter mail.  It caused
      mailbox files to have embedded ctrl/z's, beyond which DOS didn't
      want to read... I have no way to test the fix right now, but I think
      it will be ok.  This change #ifdef MSDOS.

    - NET.EXE now understands symbolic hostnames ala the hosts.net file,
      which has moved to the root directory.

    - the session command now shows more information about the command
      that was issued to create the session.

    - the close command now has an optional argument, which allows you to
      close a specified session without needing to make it the current
      session first.

    - ftp now has access control!  The file \ftpusers should be created
      with entries of the form:
        username password \path permissions
      where
        username is the user's login name for ftp
        password is the password they are now required to use.  Note
            that for the moment this is in plaintext, and therefore
            not very secure.  A password of '*' allows anything
            typed to be accepted.
        \path is the allowable prefix on accessible files.  Think of
            this as the root of the directory subtree this user
            is allowed to access.
        permissions is a decimal number graning permission for read,
            create, and write operations.  bit 0x1 is read, bit
            0x2 is create if not overwriting, bit 0x4 allows
            overwriting an existing file, and deleting files.
            All permissions of course only apply to files in the
            subtree rooted at \path.

      examples:
        karn foobar \ 7         # user karn can do anything

        guest rot \bogus 3      # guests may read and create as long
                    # as they do not try to overwrite an
                    # existing file

    - open_tcp now has three modes: TCP_ACTIVE, TCP_PASSIVE, and
      TCP_SERVER.  ACTIVE is as before.  PASSIVE creates a TCP control
      block which will accept only one incoming connection request.  The
      new SERVER mode is what PASSIVE used to be.

    - the FTP client now accepts a data connection request from any foreign
      socket.  This fixes a problem that occured when talking to a host
      with multiple IP addresses assigned to it.  The security risk of this
      fix should be minimal.

    - documentation has been updated somewhat.

Things I hope will be in the next release (in a month or so):

    - code for the Amiga, Macintosh, and relatively generic Unix
    - further improvement of BM and the SMTP client
    - completely rewritten and restructured documentation for the entire
      package.  This is underway, but not ready to release yet.

What to do once you have software, aka "getting an IP address":

    Users of this software package become part of the "global IP
    internet", and as such need to obtain unique IP address assignments
    for each host they plan to put on the air, or "on the wire".  Major
    metropolitan areas in the US, and countries with active TCP-using
    groups probably already have blocks of addresses in amateur radio
    44.X.X.X block assigned to them.  Ask around locally before you go
    any further.

    If there is no local address block in your area, and/or noone is
    coordinating address assignments for your local net, contact Wally
    Linstruth WA6JPR.  Wally is the global top-level address administrator
    for the ham radio 44.X.X.X subnet.  Wally may be reached by email at

        [e-mail]
    or      [e-mail]
    or      ...!sdcsvax!net1!wally

    or via the new forwarding mechanism I have set up for those sites who
    know how to reply via mail to this message, but can't reach Wally's
    machine directly:

        winfree!wally   -or-   [e-mail]
    or      [e-mail]

How to obtain the KA9Q Internet software:

-       Via uucp, the files are on winfree in tar archives as:

      /usr/spool/uucppublic/pub/ka9q_all.tar.Z      16 bit Compress 4.0
      /usr/spool/uucppublic/pub/ka9q_all.t12.Z      12 bit Compress 4.0

    Direct UUCP connection to winfree is available to those who request
    it for polling to get new versions.  Inquire via mail to one of the
    addresses below.  Anonymous uucp is NOT currently allowed.

    A reasonable command to issue to pick up the 12-bit distribution
    would be

        uucp winfree!~/pub/ka9q_all.t12.Z /usr/spool/uucppublic


-       Via Opus, log in to my BBS and download from the appropriate files
    area.  There are several .ARC files for the full distribution, one
    for each of the directories.  SeaDog file requests are ok.

    I have configured my BBS to allow first time users ample resources to
    download the full distribtuion at 1200 baud.  The phone number is
    303/593-0766.

    If you have any trouble downloading from the BBS, please let me know.
    Speeds that are supported include 300, 1200, and 2400.

-       Via US Snail, Brian Lloyd WB6RQN has agreed to make floppy copies.
    To get a copy from him, send $5 to:

        Brian Lloyd, WB6RQN
        19200 Tilford Way
        Germantown, MD  20874

    I update Brian directly via UUCP, so he should have relatively
    current code.  I also understand that Brian can provide ROM's for
    KISS TNC1 or TNC2, for $10/each.  Contact him for more details.

    In Canada, contact:

        Michael A. Shiels
        426 Hazel St. #9
        Waterloo Ontario, Canada
        N2L 3P8

    Send him $5 Canadian for a copy of the current distribution on
    disk.  I will be updaing Michael via a uucp/mail hack, so he should
    stay very up to date.

-       Within a day or two of a new release, the code should also be available
    from the following additional secondary distribution points:

        from Dan Taylor, WB6FIU
            ARC files available on BBS @ 805/947-4357, 2400 baud
        from Doug KD4NC in Atlanta, GA
            uucp: winfree!kd4nc!dug
        from Bob Hoffman N3CVL in Pittsburgh, PA
            arpa: [e-mail]
            uucp: pitt!hoffman
        from Wally Linstrugh WA6JPR in Santa Barbara, CA
            arpa: [e-mail]
        from Brian Kantor at UCSD.  (via anonymous FTP?)
            arpa: [e-mail]
            uucp: sdcsvax!tcp-group-request

    Unreleased (read: under development) versions are often available
    on louie.udel.edu, caveat emptor...

If anyone has any trouble getting hold of a copy of the code, please let me
know!

How to contact me:

    Bdale Garbee, N3EUA
    1433 Territory Trail
    Colorado Springs, CO  80919
    303/590-2868w, 303/593-9828h

uucp: {bellcore,crash,hp-lsd,nnc,pitt,vixie}!winfree!bdale
arpa: [e-mail]
      pitt!winfree![e-mail]
fido: Bdale Garbee at 128/19, 303/593-0766, 300/1200/2400 baud, 24hrs
packet: n3eua @ k0hoa
--

Bdale Garbee, N3EUA             phone: [phone] h, 303/590-2868 w
uucp: {bellcore,crash,hp-lsd,hpcsma,ncc,pitt,usafa,vixie}!winfree!bdale
fido: sysop of 128/19           packet: n3eua @ k0hoa, Colorado Springs


26-May-87 16:48:17-EDT,885;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 26 May 87 16:48-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Tue, 26 May 87 14:59:57 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Tue, 26 May 87 14:59:41 EDT
Message-Id: <[e-mail]>
Received: from SERVAX.BITNET by wiscvm.wisc.edu ; Tue, 26 May 87 13:58:33 CDT
Date:       05/26/87    14:58:08 EST
From: [e-mail]   (DAVID=HALL)
To: <[e-mail]>
Subject:    delete from list

Please delete me from the packet radio distribution list. I have tried
the standard "SIGNOFF" requests to be removed, but they do not seem to
work. I get messages that the list I want to be removed from does not
exist.

   Thank you
    David Hall
    DAVID@SERVAX
     KA4MNX

26-May-87 23:31:01-EDT,833;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 26 May 87 23:31-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Tue, 26 May 87 22:01:20 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Tue, 26 May 87 22:00:49 EDT
Message-Id: <[e-mail]>
Received: from USU(BOBW) by MITVMA (Mailer X1.23) id 0689;
      Tue, 26 May 87 18:38:33 EDT
Date:     Tue, 26 May 87 16:35 MST
From: <[e-mail]> (BOB WOOD WA7MXZ)
Subject:  870526.0 TCP/IP to SIMTEL
To: [e-mail]
X-Original-To:  [e-mail]

When will the latest TCP/IP get into SIMTEL20? That is the only method that
we BITNETTERS can get the release since we have no FTP,ARPA, or UUCP access.
Thanks, 73, Bob Wood WA7MXZ
27-May-87 03:07:56-EDT,1729;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 27 May 87 03:07-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Wed, 27 May 87 01:47:13 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Wed, 27 May 87 01:44:48 EDT
Received: by june.cs.washington.edu (5.52.1/6.2)
    id AA15384; Tue, 26 May 87 22:44:47 PDT
Return-Path: <rutgers!princeton!idacrd![e-mail]>
Message-Id: <[e-mail]>
Date: 26 May 87 17:00:39 GMT
From: rutgers!princeton!idacrd![e-mail] (Bob McGwier)
To: [e-mail]
Subject: Re: All- mode TNCs
References: <[e-mail]>

in article <[e-mail]>, [e-mail] says:
>
> I am considering buying a Kantronics KAM or AEA PK232 all_mode TNC,
> and would be interested in hearing any comments or user reports on these
> units, either pro or con.

Hi Peter,

The AEA PK232 comes with the "Kiss TNC" mode built in so that Phil's
TCPIP code runs just fine with.  Phil had discussions with Phil Anderson
of Kantronics at the digital committee meeting this weekend and Phil
took the Kiss code back with him and said it would be on his boxes as
fast as they could put it on board.  Most of the other systems will have
the code on a host somewhere else and you will do an AX25 connection to
it and then get the services.  Both of these boxes are very nice pieces
of equipment for packet radio and even for the upcoming stuff on packet
radio.  I would also consider the other features versus price etc and
maybe ask Anderson at Kantronics how soon he thinks Kiss will be on
board to support TCP/IP.

73 Bob N4HY


27-May-87 03:07:59-EDT,920;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 27 May 87 03:07-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Wed, 27 May 87 01:48:06 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Wed, 27 May 87 01:47:01 EDT
Received: by june.cs.washington.edu (5.52.1/6.2)
    id AA15480; Tue, 26 May 87 22:48:23 PDT
Return-Path: <pyramid!batcomputer![e-mail]>
Message-Id: <[e-mail]>
Date: 26 May 87 12:54:07 GMT
From: pyramid!batcomputer![e-mail] (Mitch Collinsworth)
To: [e-mail]
Subject: Re: 10 meter packet
References: <[e-mail]>

I'd say that's not quite true.  ON 10m you also have to be concerned about
international 3rd party traffic.  Something which isn't a problem for MOST
2m stations in the U.S.

-Mitch Collinsworth, K2VD


27-May-87 03:08:52-EDT,1418;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 27 May 87 03:08-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Wed, 27 May 87 01:47:21 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Wed, 27 May 87 01:45:48 EDT
Received: by june.cs.washington.edu (5.52.1/6.2)
    id AA15421; Tue, 26 May 87 22:46:31 PDT
Return-Path: <mnetor!genat![e-mail]>
Message-Id: <[e-mail]>
Date: 26 May 87 16:35:14 GMT
From: mnetor!genat![e-mail] (George Gorsline)
To: [e-mail]
Subject: Packet programs

With alot us new on packet, we're using a variety of terminal programs on
IBM work-alike systems: Procomm, Smartcom, Open Access, etc.  Does anyone have
a list of programs (by machine) and their features?  For example, the C64
has a nice program with split screen but no bells.

If I get any number of replies, I'll summarize to the net.  Individual replies
will come if I can get your return path to work - lots of one-way propagation
[is it D-layer absorbtion?]

Thanks.  73,
--
    George Gorsline, Jr.  VE3FIU / K8HI
    One of the VE3YDX gang... Y DX?  Because it's there(~Y)!
            __... ...__  . ...  _.. _.._
    Genamation, 351 Steelcase Rd. West, Markham Ontario L3R 3W1
    {allegra|linus|ihnp4|...}!utzoo!mnetor!genat!george
    [phone]


27-May-87 03:25:53-EDT,1305;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 27 May 87 03:25-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Wed, 27 May 87 02:04:39 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Wed, 27 May 87 02:04:18 EDT
Received: by june.cs.washington.edu (5.52.1/6.2)
    id AA15358; Tue, 26 May 87 22:42:33 PDT
Return-Path: <apollo![e-mail]>
Message-Id: <[e-mail]>
Date: 26 May 87 13:57:00 GMT
From: apollo![e-mail] (John Hays)
To: [e-mail]
Subject: Re: 10 meter packet
References: <[e-mail]>

In article <[e-mail]> [e-mail] (News) writes:
>WA8EJH asked about what precautions are needed if you put a Unix system
...
>world to avoid sending commercial stuff and other no-no's.  The fact
>that it's 10 rather than 2 has nothing to do with it.
>

Except that you MUST have a control operator (NO AUTOMATIC).

73 de KD7UW, John

--
John D. Hays, Consultant             UUCP: ...!decvax!wanginst!apollo!hays
Corporate Systems Engineering              ...!uw-beaver!apollo!hays
Apollo Computer Inc.                 CIS: 72725,424  {weekly}
           !MY OPINIONS, not Apollo's!


27-May-87 09:57:26-EDT,764;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 27 May 87 09:57-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Wed, 27 May 87 08:43:53 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Wed, 27 May 87 08:43:31 EDT
Message-Id: <[e-mail]>
Received: from DHHDESY3.BITNET by wiscvm.wisc.edu ; Wed, 27 May 87 07:43:40 CDT
Received: from TSO by DESY IBM-3084Q BB with NEWLIB-Clist AMAIL
Date:     27 MAY 87  13:57:27 MEZ
From: [e-mail]
To: [e-mail]
Subject:  COSI software?

Has anybody got the COSI software on this net? I cannot get it via the
other sources...

Karl-Heinz, DK8HI @ DB0HB

27-May-87 10:02:49-EDT,1803;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 27 May 87 10:02-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Wed, 27 May 87 08:44:18 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Wed, 27 May 87 08:43:56 EDT
Message-Id: <[e-mail]>
Received: from CSUOHIO.BITNET by wiscvm.wisc.edu ; Wed, 27 May 87 07:44:30 CDT
Date: 27 May 86 08:20 EST
From: [e-mail]
To: [e-mail]
Subject: An Interested Spectator Asks for Help


   I've been reading packet-radio for quite awhile now, trying to understand
concepts and such as they are being tossed about. I'm very curious about the
subject, and would like to find out more about it at an "introductory" level.
Does anyone out there have any documentation (hardcopy or e-mail) that
represents a "Beginners' Guide to Packet Radio?" I'm not in much of a position
to afford some of the equipment that's being discussed here, but I would very
much like to be in a position where I have a better understanding of the
exciting things that are happening here.

   Thanks in advance for any help you can provide.    - Dave

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
   From the North Coast      Dave Chatfield, Dept. of Computer Services
   _____   of America...._-! Cleveland State University
  !     --___       ___--  !
  !          ------(*)     ! BITNET: C0144@CSUOHIO
  !          Cleveland     ! ARPA: [e-mail]
  !                        ! USENET: davec!ncoast.UUCP
  !       O  H  I  O      !  BBS: Assistant Sysop, PC-OHIO 216-381-3320
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
27-May-87 14:34:05-EDT,873;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 27 May 87 14:34-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Wed, 27 May 87 12:07:56 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Wed, 27 May 87 12:07:47 EDT
Message-Id: <[e-mail]>
Received: from NJECNVM(H156004) by MITVMA (Mailer X1.23) id 3010;
      Wed, 27 May 87 12:01:52 EDT
Date: 27 May 87   12:00 EDT
From: [e-mail]
To: [e-mail]
Subject: BITNET mail follows

I HAVE A FRIEND WHO WANTS TO USE AN H/Z100 ON PACKET RADIO. HE'S
BEEN UNABLE TO FIND A PACKET TERMINAL PROGRAM (LIKE YAPP) FOR IT.
IF ANYONE KNOWS OF ONE FROM ANY SOURCE, PLEASE REPLY.

KEN TOMPKINS -- WB2PUW @ WB2DRD-2
STOCKTON STATE COLLEGE (NEAR ATLANTIC CITY)

THANKS AND 73.
27-May-87 15:55:42-EDT,1663;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 27 May 87 15:55-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Wed, 27 May 87 11:18:57 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Wed, 27 May 87 11:18:25 EDT
Received: by june.cs.washington.edu (5.52.1/6.2)
    id AA21183; Wed, 27 May 87 08:20:05 PDT
Return-Path: <rutgers!mtune!codas!ge-dab![e-mail]>
Message-Id: <[e-mail]>
Date: 26 May 87 19:27:42 GMT
From: rutgers!mtune!codas!ge-dab![e-mail] (Arthur J. Byrnes)
To: [e-mail]
Subject: Packet Radio TNC
Keywords: Heath Kit got my money......

Does anyone have any information about level 2 software for the
Heathkit tnc?

I already have the V1.2 DED software and find it unaceptable because
of its incompatability with the standard TAPAR commands.  I also feel
that it is not complete.

I feel like TAPAR and Heath have left us out in the cold with our
dinosaur tnc's. I purchased mine from heath, because I thought they
would support it as well as they do their other projects, but I guess
I was wrong.

It sure leaves a bad taste in you mouth to spend $300 for something
and find it isn't compatable, with the upgrades.  It also seems that
heath is not totally to blame, since TAPAR no longer seems to be
providing up dates.

I sure hope some on can prove me wrong, but I
think I got fleeced.........
73's KA4WDK

Disclaimer
These views are purely those of a man who has a $300 piece of silicon
which can now be bought for $149......................


28-May-87 13:47:02-EDT,2593;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 28 May 87 13:47-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Thu, 28 May 87 11:02:21 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Thu, 28 May 87 11:02:05 EDT
Message-Id: <[e-mail]>
Received: from USU(BOBW) by MITVMA (Mailer X1.23) id 6739;
      Thu, 28 May 87 10:57:09 EDT
Date:     Thu, 28 May 87 08:49 MST
From: <[e-mail]> (BOB WOOD WA7MXZ)
Subject:  TNC-1 lack of updates
To: [e-mail]
X-Original-To:  [e-mail]

RE: KA4WDK Packet Radio TNC
    So far the best software out for the TNC-1 is the DED V1.2. If you want to
yell at someone jump on Harold Price NK6K. He wrote the original 3.3 code for
the TNC-1 and for over a year told everyone that 4.0 was coming out and would
have compatibility with the TNC-2. With that announcement those of us in 6809
code development laid back and waited since Harold like Howie Goldstein didn't
release too much of the source. Harold's excise for delay's were time to work
on it and trying to fit the code (PASCAL) into 4 tiny little proms. Meanwhile
after everyone waited a year or more for 4.0, WA8DED released 1.0 which allowed
multiconnects and level 2. Now that 2.5 years have passed there is no 4.0 and
Harold has totally dropped the 4.0 project, WA8DED is busy manufacturing NET/
ROM's for TNC-2's and everyone with a TNC-1 is waiting in the wings. With the
changes in protocols (TCP/IP etc) and Networking it is difficult to start
designing the software to update the TNC-1 and set up its command structure to
match the Howie code only to see a change in the protocol and be obsolete over-
night. Plus all of the development now is absolute volunteer labor and there
is a lot of work in developing the new code. There is a RAW HLDC type loader
for the TNC-1 that allows use if alternate protocols like TCP/IP. It seems
like one of the best mods (and easiest to implement) would be a host mode
only and allow the PC or computer talking to the TNC-1 to do all the work.
This ties up the PC all the time for packet but allows many times more prog-
rammers to develop code. I am still looking for a solution myself to the TNC-1
hassle, even if it's to put COSI (still not released?) or NET/ROM code into
it and put it on a hill as a digipeater network device. As far as TAPR's part
in development, WHERE IS THE NNC (Network Node Controller) that was to be
released soon??????
Bob Wood WA7MXZ
28-May-87 19:41:32-EDT,1345;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 28 May 87 19:41-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Thu, 28 May 87 15:30:50 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Thu, 28 May 87 15:27:41 EDT
Received: by june.cs.washington.edu (5.52.1/6.2)
    id AA10422; Thu, 28 May 87 12:29:09 PDT
Return-Path: <rutgers!princeton!idacrd![e-mail]>
Message-Id: <[e-mail]>
Date: 28 May 87 16:52:25 GMT
From: rutgers!princeton!idacrd![e-mail] (Bob McGwier)
To: [e-mail]
Subject: Re: An Interested Spectator Asks for Help
References: <[e-mail]>

The American Radio Relay League publishes a book for beginners called
"Getting *** connected to Packet Radio".  While this book has a few
drawbacks it is for beginners and I think a valuable introduction.

You didn't post a call sign so I will assume that you are not a ham (yet
;-)  )

A.R.R.L
225 Main St.
Newington, Conn. 06111


The ***Connected  business is "an inside joke" in that all of the TAPR
tnc's (packet board's) and the clones send the message
*** CONNECTED to N4HY

when you get connected to (for example) my packet radio board on AX.25
mode.

Bob N4HY



28-May-87 20:01:06-EDT,1571;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 28 May 87 20:01-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Thu, 28 May 87 17:57:09 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Thu, 28 May 87 17:56:00 EDT
Date: Thu, 28 May 1987  15:56 MDT
Message-Id: <[e-mail]>
Sender: [e-mail]
From: Keith Petersen <[e-mail]>
To: [e-mail]
Subject: New release of KA9Q TCP/IP package available from SIMTEL20

>Date: Tuesday, 26 May 1987  01:49-MDT
>From: crash!winfree!bdale at EDDIE.MIT.EDU (Bdale Garbee)
>To:   PACKET-RADIO at EDDIE.MIT.EDU
>Re:   new release of KA9Q TCP/IP package
>
>Announcing an update to the KA9Q TCP/IP software package release of
>870412.0, bringing the current release date up to 870526.0.  This
>update adds many new features, and fixes bugs.

This new release is now available from SIMTEL20...

Filename                        Type     Bytes   CRC

Directory PD:<MSDOS.PACKET>
870526.ANN.1                    ASCII     7932  BDB5H
KA9QREAD.ME.3                   ASCII     4271  BAB6H
KA9Q_BM.ARC.3                   BINARY   15426  E530H
KA9Q_DOC.ARC.3                  BINARY   56613  F876H
KA9Q_EXE.ARC.3                  BINARY   79399  1F77H
KA9Q_SRC.ARC.3                  BINARY  181249  0397H
KA9Q_TNC.ARC.3                  BINARY  135500  E0A4H

These files are accessable via Internet anonymous FTP or from our
archive server via netmail.

--Keith Petersen
Arpa: [e-mail]
Uucp: {bellcore,decwrl,harvard,lll-crg,ucbvax,uw-beaver}!simtel20.arpa!w8sdz
GEnie: W8SDZ
30-May-87 13:22:26-EDT,1122;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 30 May 87 13:22-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Sat, 30 May 87 12:39:13 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Sat, 30 May 87 12:39:04 EDT
Received: by june.cs.washington.edu (5.52.1/6.2)
    id AA12023; Sat, 30 May 87 09:39:20 PDT
Return-Path: <rutgers!clyde!sdl![e-mail]>
Message-Id: <[e-mail]>
Date: 29 May 87 14:47:07 GMT
From: rutgers!clyde!sdl![e-mail] (Stu Brown)
To: [e-mail]
Subject: info on packet radio wanted

Like a previous article, I have also been reading this group
for a while but don't completely understand packet radio.
Perhaps someone could post an introduction.

I have used RTTY with my HF gear, IBM-PC running VENIX, and
Heath FSK TU. Can a RTTY TU be used on packet radio if the
appropriate software is run? Or must I purchase a TNC?
Is packet on HF or VHF?

Thanks in advance.
--
                    Stuart Brown
                    {ihnp4,allegra}!clyde!sdl!stu


30-May-87 13:40:30-EDT,1122;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 30 May 87 13:40-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Sat, 30 May 87 12:39:13 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7
    id <[e-mail]>; Sat, 30 May 87 12:39:04 EDT
Received: by june.cs.washington.edu (5.52.1/6.2)
    id AA12023; Sat, 30 May 87 09:39:20 PDT
Return-Path: <rutgers!clyde!sdl![e-mail]>
Message-Id: <[e-mail]>
Date: 29 May 87 14:47:07 GMT
From: rutgers!clyde!sdl![e-mail] (Stu Brown)
To: [e-mail]
Subject: info on packet radio wanted

Like a previous article, I have also been reading this group
for a while but don't completely understand packet radio.
Perhaps someone could post an introduction.

I have used RTTY with my HF gear, IBM-PC running VENIX, and
Heath FSK TU. Can a RTTY TU be used on packet radio if the
appropriate software is run? Or must I purchase a TNC?
Is packet on HF or VHF?

Thanks in advance.
--
                    Stuart Brown
                    {ihnp4,allegra}!clyde!sdl!stu