brian@sdcsvax.UUCP (Brian Kantor) (05/31/85)
From ihnp4!cbnap!gws@mit-eddie.ARPA Sun May 19 12:26:58 1985
Subject: lsi -11 programs
Does anyone have any sort of programs for packet radio or
amateur radio in general that will run on a pdp 11/03 11/23
or 11/23+ under RT-11 ??
many thanks and 73
Gary W. Sanders (N8EMR)
AT&T Bell Labs (Columbus)
ihnp4!cbnap!gws
From bcn@mit-eddie.ARPA Sun May 19 19:22:08 1985
Subject: Routing and Addressing
I am interested in routing and addressing issues associated with amateur
packet radio, and am wondering what people have done so far. I read
Phil Karn's paper in the proceedings of the 4th Networking Conference.
The emphasis of that paper was mainly on the way things are done on the
ARPA Internet.
I agree with his recommendations, and would like to get started on
solving (or attempting to solve) the problem. Here are my present ideas
on the subject.
Naturally, a full address should specify a host. The first three fields
of the internet address (one of which is fixed) should specify a
physical subnet. What I mean by a physical subnet is a collection of
machines which can talk to one another directly (i.e. not using a
digipeater). With this limitation, 8 bits may seem like a lot to
allocate for hosts within a subnet. It isn't though, since repeaters
may be used to extend the coverage of a subnet.
One (or more) machine(s) on each subnet should be on another subnet and
should act as a gateway between the two. As with the ARPA internet,
subnets can be tied together by a subnet one level up in the hierarchy
which has at least one host per lower level subnet, each of these hosts
acting as a gateway.
I think that the current emphasis should be on getting local subnets set
up. As I mentioned, regular repeaters (as opposed to digipeaters)
should be used to extend the range of the local subnets. Use of regular
repeaters should cut some of the latency since the repeater would
transmit as it is receiving the packet instead of storing it, and only
retransmitting it after receiving the whole packet. We are about to set
up a repeater at MIT for packet work.
Clifford Neuman
N1DMM
From rgt@LANL.ARPA Mon May 20 06:24:06 1985
Subject: Packet Radio field sizes
I read the article to this mailing list by Clifford Neuman
<bcn@mit-eddie.ARPA> about routing ideas. I am interested in packet
radio, but have done nothing about it for lack of money. I have not read
the papers to which he refers, but do have one suggestion.
Here at Los Alamos, we have an Integrated Computer Network of
many computers. A friend of mine was working at a site, and they chose
an 8-bit field. He suggested 16 bits. They said that 8 was enough,
and would never be exceeded. Fortunately, he persuaded them to go with
16 bits. Now, about 5 years later, they have about 250 machines and
adding more.
Please use 16 bits, at least! I know, you will never have more
than 256 machines in one subnet. But if it does happen and packet radio
catches on (as it is already doing), there might be such a concentration
in one area in the near future. Better to have a large, unused field in
the protocol than have to redo the protocol at a later date because the
sizes were exceeded. Build in plenty of room for expansion!
Richard Thomsen
rgt@lanl
From michel@bbncct Mon May 20 07:49:53 1985
Subject: Routing and addressing
Clifford Neuman raises the issue of routing. Let me carry over some
lessons from the Internet. Again, these are personal lessons with which
other Internetters might not agree.
The original Arpanet was designed to be a small network. Quite early
on the address field was expanded from 8 bits to 24 bits. But the mentality
remained, that all network users would know or be easily able to figure
out the physical address of a correspondent. One result of this seems
to be that now that the INternet is grown to very large, world-wide
proportions, addressing and routing are quite out of hand. The problem is
that given a 32 bit Internet address, you can't figure out from the
address what to do. The reason is that the network numbers (the first
three fields of an address) don't have any topological significance.
Network 194.1.1 might be in Japan while 194.1.2 could be in England.
What this seems to mean is that each switching node must keep a table
listing all networks, and the best strategy to get to each possible
destination. Even now this is pretty unwieldy, and is a principle
limit on the number of network numbers which can actually be assigned
(or at least supported).
The Internet is evolving various clever, ad hoc schemes to cope, but
none is really ideal for the ham radio packet environment.
A different approach has been taken by the CCITT in their design of
an internetwork. Recommendation X.121 divides the world into 10
major regions, and further subdivides these into smaller regions,
mostly according to political boundaries. Given nothing but the address,
you can get fairly close to your destination. Any remaining ambiguity
is presumed to be small enough to be handled by a local nameserver
or table lookup in the switch, or something simple.
THere are some troubles with X.121, mostly due to its Telephone company
orientation. It presumes there will be few networks in any one
country, ideally only 1. But it allows for variable length addressing,
so that "area codes" with few networks can assign short numbers within
the area.
At this early stage of ham packet, the choice could still be made either
way. I'd recommend the CCITT way. It might be that the X.121 choices
are suitable as they stand. Perhaps the amateur fraternity should re-allocate
the numbers. Perhaps the world-wide telephone numbering system could
be used. Perhaps some derivative of the world-wide radio call sign
prefix allocation would work. Any of these is superior to no system
at all.
I personally favor the telco approach. Addresses are allocated to geographic
areas, and coded by expected frequency of use. Actually the European
telcos did it better than AT&T by adopting variable length numbers.
Addresses in the big city begin...1-some number of digits. Address in
a rarely addressed location in the provinces might have a long prefix.
Once inside an area, there is a similar coding. Popular addresses are
given short codes. SInce this might seem to "discriminate" against
the residents of the provinces, an escape is available for dialing
local numbers. If you want a local number, you do not attach the "long
distance" prefix. More or less like our telephone system.
How long is the maximum address? In the telephone system 10 or 15 digits
is a LONG nnumber, outside the USA. Coded as BCD, that is very
manageable. In the protocol research community some advocate much
different schemes. One scheme calls for addresses to be ASCII (actually
"international alphabet #5") strings of up to 255 characters. Such
an address could be read directly on a datascope, presumably, as it
went whizzing by.
Who allocates the area codes? Hmmm.... This is the hardest problem, by
far. Sounds like diplomacy.
Who maintains the "directory?" The white pages? (Sorted by name)
The yellow pages? (sorted by some other consideration)
Once the address assignment mechanism is chosen we can grapple with
routing. SHould the user be allowed to specify a route (explicit
routing)? If the address assignment is not systematic/topological, you
need this capability. Telephone systems once had this, and phased
it out in most places because it's unwieldy. WHen the net diameter
gets big, you need a lot of overhead in the message just to carry the
route info.
I think it's worth considerable effort at the beginning to get this right.
Designs tend to get entrenched, and that which we do today as a hack
may last a long time.
AXM
From bcn@mit-eddie.ARPA Mon May 20 18:53:12 1985
Subject: Status report from Dave Mills
Here is a copy of a status report sent by Dave Mills (mills@dcn6) on the
ninth of this month:
You can report that initial tests using IP/TCP were carried out using an
LSI-11 and experimental software used on the ARPANET and DARPA Internet
systems. A Heath TAPR board was operated in transparent mode via the
WB4JFI-5 and W3VD-5 digipeaters on 145.01 MHz. The tests were carried
out using virtual-terminal, file-transfer and mail protocols with
traffic looped via a digipeater back to W3HCF. Additional tests using
special performance-measurement protocols revealed disturbingly high
packet-loss statistics of one in ten via the WB4JFI-5 digipeater and
one in four via the W3VD-5 digipeater, but confirmed the viability of the
IP/TCP protocols and implementation over typically raunchy Amateur
circuits.
Further tests using an IBM Personal Computer and an IP/TCP software
package from MIT over the same channel were inconclusive due to inadequate
timeouts in the MIT software. The authors of the software have been advised
of this and, hopefully, can be persuaded to fix the problem. The MIT software,
which is publicly available, provides virtual-terminal, file-transfer and
several utility functions using standard DoD protocols, including IP/TCP.
Dave
From bellcore!karn@Berkeley Mon May 20 23:23:51 1985
Subject: Routing issues
I agree with Tony Michel that the current Arpa Internet addressing and
routing schemes are not well suited to the amateur radio environment.
However, I think the real issue is hierarchical vs (relatively) flat
addressing, and we can solve the problem without tossing out IP.
The fundamental problem with the current Internet model is the implicit
assumption that all hosts within a "network" (whether class A, B or C) can
communicate directly, without IP's help. In other words, as far as IP is
concerned, the Internet is a hierarchy with two and only two levels,
"network" and "host".
About the only way under the current conventions that a collection of hosts
who are NOT fully interconnected can be made into an Internet is to assign
fully interconnected subsets to small Class-C nets, or to exchange routing
information at the host-specific instead of network level. Both of these
techniques tend to result in routing table explosion.
Clearly this restriction has already become a problem with current Internet,
even ignoring the extra problems of packet radio; hence the big flurry of
RFCs on subnet addressing schemes. The proposals had in common the addition
of at least one new level in the addressing hierarchy, but in my opinion
they are all too ad-hoc for amateur packet radio, and will probably
become obsolete eventually for general Internet use as it grows even more.
I believe that the most general scheme would be the best. It would allow an
arbitrary number of levels within the constraints of a 32-bit IP address,
with the bit field boundaries being completely variable. Routing table
entries would consist of variable-length bit strings representing prefixes
on IP addresses; an entry is used if the leading bits of the target address
match the corresponding bits in the routing table. The special cases of 0
and 32 bit long table entries would correspond to the current notions of
default and host-specific entries, respectively.
As I mentioned, a gateway need not concern itself with the actual "meaning"
of the bits in an address; it would simply try to "collapse" all routing
table entries with a common prefix and routing decision (i.e., the same next
hop) into a single table entry as a means of saving table space. There is no
need for a gateway to retain any more information than that necessary to
make a routing decision.
For this reason, I am not really concerned with the actual boundaries and
procedures that are established to assign IP addresses, so long as they are
done in a hierarchical manner. Only the meaning of a few leading bits need
be established on a worldwide basis to denote major regions (countries or
continents, etc). National entities would then establish the boundaries for
the next lower level in the hierarchy and "take" enough bits to encode them.
The task of assigning the remaining bits is likewise delegated recursively
until they're all gone (and hopefully you've reached the end host!) All
along the way, the boundary assignments should be made with an eye towards
the topology of the network in the specific area, so that as many routing
table entries as possible can be "collapsed" together. If the regions
at any level of the hierarchy differ in population then a Huffman-like
variable width subfield encoding scheme should be used to conserve bits.
There is no requirement that the number of levels be the same for all hosts,
nor that the number of bits needed to designate any one entity within
a hierarchical level be the same. This makes the scheme as flexible as
possible and highly adaptable to local needs.
ARPA has already assigned Class A network number 44 to amateur radio, so that
leaves us 24 bits to play these games with. This means we can address 16
million hams, so I think the job ought to be doable.
I presented this scheme in more detail in my ARRL Computer Networking
Conference paper "Addressing and Routing Issues in Amateur Packet Radio".
I'm very interested in comments and suggestions on this scheme. I certainly
doubt that this idea is completely original with me (I seem to recall a
mention of Danny Cohen at ISI proposing something similar) so if others have
tried this scheme and failed, I'd like to know why. About the only problem I
can see is the speed of the routing table lookup. However, I suspect that
caching would help greatly here since a gateway is probably handling packets
to only a few destinations over any short interval.
73,
Phil Karn, KA9Q
From bellcore!karn@Berkeley Mon May 20 23:41:12 1985
Subject: Re: IP over X.25 - the CSNET experience
Paul, thanks for your comments on CSNET. I am somewhat familiar with CSNET,
as another one of the developers is here in my group at work. So I am not
totally naive as to the many problems caused by X.25. In fact, I have often
used his experiences, which were essentially identical to yours, as potent
ammunition against those who blindly tout X.25 as the ultimate networking
solution. We have a Telenet connection, and as soon as we get the CSNET
software I'll be able to experience these joys first hand.
Perhaps the main difference between X.25 as seen by CSNET and AX.25 as seen
a ham user is that AX.25 consists ONLY of the link layer (LAPB) from X.25;
there is no packet layer as such. What this means is that there is no
concept of a "message" spaning more than one physical frame. If we wanted to
do "implicit" IP fragmentation, we would have to add an extra mechanism to
denote the beginning and end of the datagram. This could be done, for
example, by encapsulating the datagram with SLIP and sending it as serial
data (ignoring link frame boundaries altogether), or by defining a few more
AX.25 "level 3 protocol IDs" to indicate "head", "middle" or "tail" of a
datagram. Both approaches are kludgey, to say the least. Don't forget that
even the "reliable" (i.e., connected) mode of AX.25 can lose packets so
whatever encapsulating method you use still has to be able to resynchronize
after lost physical frames. [If you want the gory details on the flaws in
AX.25, (and LAPB, too, to be fair) let me know and I'll make it the subject
of a separate message.]
If on the other hand there is a one-to-one correspondence between IP
datagrams and AX.25 frames, then other things become much easier, e.g.,
mixing sequenced (I) frames with datagram-like unnumbered (UI) frames
depending on the setting of the IP "reliability" bit. The cost is, of
course, the extra overhead of the duplicated IP headers.
The problem with just getting rid of the connection-oriented link (AX.25)
layer and relying totally on TCP is that our links are currently so bad that
hop-by-hop acknowledgements are often essential just to get reasonable
performance over a long connection. I've worked out the formulas for the
expected number of transmissions across all nodes for three acknowledgment
strategies (end-to-end only, explicit hop-by-hop, and implicit (echo)
acknowledgments without duplicate filtering). If anyone is interested I can
post the gory details here.
If anyone can suggest a link-level acknowledgement scheme other than the two
I just mentioned, I'd certainly be interested, particularly if it's easier
to implement and more efficient when sending datagram traffic than the
go-back-N scheme in the connected mode of AX.25 (LAPB).
Phil Karn
From karn@umd5 Wed May 22 14:27:48 1985
Subject: Conference papers available on line
I have put up the two papers I wrote for the Fourth ARRL Computer Networking
Conference on machine "umd5". They can be retrieved with the "anonymous" ftp
convention as:
packet-radio/routing - Addressing and Routing Issues in Amateur Packet Radio
packet-radio/tcp_ip - TCP/IP: A Proposal for Amateur Packet Radio Levels 3 and 4
Thanks to Louie Mamakos (louie@umd5) for making the necessary arrangements.
Phil Karn
From bellcore!karn@umd5 Wed May 22 15:30:29 1985
Subject: Packet Radio paper in IEEE JSAC
I am proud to announce the publication of the paper "Packet Radio in the
Amateur Service" by Harold Price, NK6K, Bob Diersing, N5AHD and yours truly,
KA9Q, in the May issue of IEEE Journal on Selected Areas in Communications,
pp. 431-439.
I guess this means that amateur packet radio has "arrived"!
Phil
From CHEPPONIS@CMU-CS-C.ARPA Thu May 23 11:25:32 1985
Subject: link quality query; book recommendation
A few days ago, Dave Mills posted a message giving present amateur packet
link quality data for IP/ICMP using loopback through two digipeaters.
The packet loss rates varied from 1 out of 10 lost to 1 of 4 lost.
I'm wondering: would using Hamming coding on the link level reduce these rates?
And what sorts of interference, etc., caused the packet lossage in the first
place? (QRM, hardware failure, whatever).
Also, a truly delightful book by Michael A. Padlipsky titled "The Elements of
Networking Style" (Prenice-Hall 1985) gives insight into networking from an
"Old Network Boy's" point of view. Find out why he thinks the ARM (ARPANET
Reference Model, including TCP/UDP/IP) is the way to go, and why ISORM (The
ISO Reference Model, pronounced "Eye Sore mmmm") is a loser. And lots of other
networking stuff. Highly recommended! (Aside to Phil: Have you sent a copy to
Terry yet?)
-Mike, K3MC
-------
From CHEPPONIS@CMU-CS-C.ARPA Thu May 23 13:38:31 1985
Subject: Another advantage of datagrams
It just occurred to me how datagrams may be a very big win over Virtual
Circuits: high bandwidth point-to-point links with low bandwidth links
in between. Think of it as a sort of "frequency" division multiplexing.
If we assume the source produces datagrams at a high rate, these datagrams
can be carried by multiple (possibly slow) links and eventually be
reassembled at the (high bandwidth) destination.
Virtual Circuits, however, suffer from the "weakest link" principle: The
greatest bandwith through a VC is limited by the bandwidth of the slowest
link.
BTW, are there any VC proponents on this list? -Mike, k3mc
-------
From bellcore!karn@umd5 Thu May 23 15:45:18 1985
Subject: Re: link quality
My personal intuition, from operating on 2m packet radio for about 2 years,
is that the poor quality of present amateur links is due to two main reasons:
1) The modems themselves are rather inefficient. Bell 202 modem tones on
an FM main carrier make very poor use of bandwidth and S/N ratio. The slow
transmission speed means that the channel is easily congested, leading
to frequent collisions, and of course the poor S/N efficiency leads to higher
bit error rates. The 9600 bps direct FSK modem designed by Steve Goode,
K9NG, has achieved bit error rates 3 db better than the TAPR 202 modem at
1200 bps, despite the 8:1 speed improvement, given equal RF power levels
and bandwidths.
2) The networks are highly prone to "hidden terminal" problems. Although each
station waits for a clear channel before transmitting, the following happens
very frequently. Consider three stations, A, B and C. A can hear B; B can
hear C, but A cannot hear C. C is sending a packet to B. A wants to send
a packet. Hearing nothing on the channel, it barges in on C's transmission
and clobbers B's reception. This problem is aggravated by the lack of
proper backoff algorithms in the present packet radio controllers. The
channels fall easily into congestion collapse, and only when the controllers
begin to abort connections does the traffic fall back to a productive level.
Phil
From @DCN6.ARPA:mills@dcn6 Fri May 24 13:32:27 1985
Subject: Phill Karn papers
Folks,
Copies of Phill Karn's papers from UMD5 are now on DCN1. The one called
packet-radio/routing is in PROUTE.TXT and the other called packet-radio/tcp_ip
is in PTCPIP.TXT, both in the RFC login with RFC password. DCN1 is three gateways
closer to ARPANET than UMD5, but is a fuzzball (not Unix) system.
Dave
-------
From bellcore!karn@mit-eddie.ARPA Fri May 24 14:12:10 1985
Subject: Re: Another advantage of datagrams
Mike, this is called "load sharing". This is a special case of adaptive
routing, which can be one of the major advantages of a datagram subnet.
The VC advocates counter that this is too "difficult" a thing to do, and
therefore conclude that it isn't a real advantage. However, if you look
through the later revisions of X.25 and X.75, you'll see them working like
mad adding something called "multi-link procedures". This allows them to
gang together more than one physical link between two points, although this
is far more difficult and less powerful than true adaptive routing in a
datagram network because packets have to be resequenced at each link point.
This seems to be a favorite ploy of the VC types. While they loudly proclaim
that a certain innate advantage of datagram protocols isn't worth anything,
behind the scenes they're scurrying about like mad trying to kludge it into
their own protocols.
Phil
From bellcore!karn@umd5 Sat May 25 09:07:52 1985
Subject: Bugs in AX.25
The bug I alluded to in my earlier message has to do with the possible
loss of I-frames that can result from just ONE frame being lost on
the transmission link.
Consider the following scenario. (Knowledge of AX.25 state transitions
is assumed.)
TNC A, attached to a terminal, wants to initiate a connection to TNC B,
attached to a bulletin board system. A sends an SABM to B and goes into the
Connect Pending state. TNC B receives the SABM, responds with a UA, and
goes directly from the Disconnected state to the Connected state.
HOWEVER, the UA is lost in transmission. TNC B, since it is in the connected
state, is free to transmit I-frames and since its local client is a bulletin
board, does so with the BB's login banner.
TNC A is still in the connect pending state, since it never received the
expected UA response to its SABM. It therefore has to ignore B's I-frames
and, eventually, retransmits its SABM. However, this is interpreted at B as
a link reset: clear all state variables and flags, and go to the connected
state. The frames B transmitted earlier (the I-frames containing the BB's
signon messages) are lost.
A number of people have reported this phenomenon with bulletin board
systems, so it is not just a theoretical possibility. I suppose I could
coin Karn's corollary to Murphy's Law for communications protocols: if a
failure mode is POSSIBLE in the protocol, no matter how "unlikely" it seems,
then it is ABSOLUTELY GUARANTEED to occur (eventually).
This problem seems to be fundamental to LAPB and cannot be solved without
the use of a three-way handshake. Such a handshake is provided as standard
equipment in TCP, but not everybody is convinced...
Phil Karn
From @DCN6.ARPA:mills@dcn6.arpa Sat May 25 21:42:46 1985
Subject: TAPR considered unfriendly
Folks,
I tried valiantly today to twinkle unsequenced (datagram) packets using
the TAPR board, but got ambushed at every turn. I used raw Internet Protocol
(IP) packet formats sent by a fuzzball and looped in full-duplex mode back to
itself, a trick which works in transparent mode with sequenced (virtual
circuit) packets. Unfortunately, the TAPR board not work in transparent mode
with unsequenced packets; therefore, today's ambushes were in converse mode.
My first battle was simply to prefix all control characters (there are about
eleven in the TAPR converse mode) with the literal-next (PASS) code to insure
character transparency, but the Tuscon boys have laid their traps well.
Converse mode is intended for chit-chat between consenting, vanilla ASCII
terminals; therefore (?), only seven bits are significant, even if the UART
parameters are set for eight bits and no parity. The Principle of Least
Astonishment would suggest all eight bits as significant, even if
control-character interpretations were masked to seven bits. This makes it
easy to win transparency battles, and also allows parity to be checked on an
end-end basis.
I counterattacked with the time-honored trick of encoding three octets as four
septets encapsulated as vanilla, upper-case ASCII characters preceeded and
succeeded by a couple of non-TAPR control characters, so that the
miscellaneous TAPR gratuitous commentary could be suppressed. That hideosity
worked and the unsequenced IP datagrams did fly; however, the TAPR commandos
decided unsequenced packets longer that 128 octets were not polite, in spite
of the fact that sequenced (tranparent) packets up to 256 octets work fine.
For my next raid, I carefully broke packets longer than 128 octets into
fragments no longer than 128 octets, with each one terminated by the
send-packet TAPR control character. But this meant that the character
following a fragment terminated by the send-packet character could wander into
the TAPR board hard on the heels of the send-packet character itself, unless
some kind of timeout intervened. In spite of a generous amount of buffer
storage and in spite of this situation working fine with sequenced packets,
the TAPR folk simply amputated anything longer than 128 octets. One would
assume they feared a congestion-gas counterattack.
I conclude the braindamage has gone far enough and trying to trick the TAPR
board into unsequenced transparency is interpreted as indecent exposure. I
should have kept my clothes on, having warred this way with more operating
systems than I care to admit. Until I do something dramatic, like write an
AX.25 driver for the fuzzball, I will TAPR IP only in sequinned nudity.
Dave
-------
From Elias.PDO1@MIT-MULTICS.ARPA Mon May 27 18:05:03 1985
Subject: A network primer on networking?
My congratulations to Cliff for starting this net, and to everybody else
who has contributed interesting and sometimes hilarious entries on this
important subject; they made me realize that there is more to networking
than sending $164.95 plus postage and handling to GLB Electronics. They
also made me realize that my claims to electronic knowledge and computer
wizardry shrink to subparticle proportions when confronted with the
world of networking, a subject about which some people even write their
Senior Thesis.
So. I would like to propose that you wizards out there get together and
prepare a set of files explaining "Networking for Laypersons". In
particular, It would be nice to see something like a set of (three?)
files, each discussing the area in successive levels of detail
(layers?); the first one could be a tutorial version of pages 19-21 to
19-31 of the 1985 Amateur Radio Handbook; in particular, I think you
guys could do better than the Handbook in two ways:
1- You seems to know the stuff better, at least by comparing the
alphabet soup you use with the glossary on page 19-30.
2- You could pattern it to the "learning packeteer", instead of
attempting the double education-reference scope of the Handbook
(admirable, but confusing).
The next files could dwell on the relative merits of Virtual Circuits
versus unsequenced datagram packets, etc., not in the flaming mode
reserved for the actual mailing list transactions, but in a paused,
academic way (.... .. .... ..).
Now; if only these files could be created, placed, accessed, and edited
in a location where a large number of mailing list readers could access
them, I can see the following process happening:
1- Info-Hams aficionados, like myself, will be informed of the existence
of such files and how to read them.
2- After reading them, one would get a much better appreaciation of
what's going on on packet-radio (and the real world, for that matter).
3- The real wizards, meanwhile, keep these tutorial files updated while
flaming on packet-radio.
Who knows, we may get the first net-wide book... on the subject of
networking, which seems to be appropriate...
- Antonio/KA1LLM
From KPETERSEN@SIMTEL20.ARPA Wed May 29 09:31:15 1985
Sender: CLEMENTS@BBNG
Subject: W0RLI Packet Radio Mailbox/BBS/GateWay system Version 9.3
Now available from SIMTEL20:
Filename Type Bytes CRC
Directory MICRO:<CPM.PACKET>
PACKET93.LBR.1 BINARY 219648 0C0BH
PACKET93.LBR contains the files that make up version 9.3 of the W0RLI
Packet Radio MailBox/BBS/GateWay system.
This system runs on the following hardware:
Computer:
Xerox 820-1 computer (the ones that were available for $50,
and are still around for not much more),
one or more 8" single density, single or double sided disk drives,
parallel keyboard, CRT monitor.
Packet Radio gear:
One or Two TAPR (or AEA) TNCs with version 3.1 or later software.
(Two TNCs if you are going to run a crossband Gateway.)
Radio gear:
One or two transceivers.
The W0RLI software supports sending, receiving and forwarding mail,
uploading and downloading files, capturing typescripts, logging
channel activity and mailbox activity, and gateway operation between
two TNCs on two bands.
Read the file NOTES.TNC to start working your way through the
documentation.
Hank would appreciate knowing of users who are running this software.
A QSL to Hank or a net message to me would be appreciated.
Here is Hank's update from the February 1985 NEPRA PacketEar:
The MailBox/GateWay has now been sent to 25 states and 5 countries.
As far as I know for sure, it is on the air at least 20 places now. In
the Boston area, 4000 messages have passed through it. The local
forwarding network now includes 9 nodes: W0RLI, WB2OSZ, WB1DSW, K1BC,
WA2RRKN-2, K7PYK, WA4SZK, KA1T, W1AW-4. The last two run their own
software, but allow for forwarding from the W0RLI systems.
A message put into any one of these systems will find its way to
the system nearest the intended recipient.
There are several other areas of the country now using the
software: Georgia, Arizona, Iowa, Washington DC, Seattle, ENY/NYC/NNJ,
Dallas, Illinois, Southern New Jersey, Los Angeles have all been heard
from. All have the software in daily use.
Expect to see it on Oscar-10 at KL7GNG soon.
Look for it from Australia, New Zealand, Japan, Hungary.
Sacramento county RACES will be using it.
GateWays are running at W0RLI, K7PYK, WA4SZK and WB7DCH.
de Hank Oredson, W0RLI
The following is an extract from the file NOTES.TNC for version
9.3 of the W0RLI MailBox and GateWay software. This extract
contains the list of changes since the last distribution to the
SIMTEL20 repository, which was version 8.6.
W0RLI, Hank, does not have access to either ARPANET or USENET.
I will be glad to try to answer questions or to relay them to Hank.
I can be reached at:
ARPANET: CLEMENTS@BBN
USENET: {ihnp4, decvax, linus, ...}!bbncca!clements
73,
Bob Clements
K1BC
--- excerpt from NOTES.TNC follows ---
W0RLI MailBox and GateWay Version 9.3 - 5/16/85
Created and distibuted to the packet community by:
Hank Oredson, W0RLI
19 North Hill Road
Westford, MA 01886
These notes are rough, more release notes and tech notes than
anything else. A SYSOPS Manual (Very nice, 25 pages or so) is
available for 8-1/2 x 11 SASE ($1.24 postage) from:
Jon Pearce, WB2MNF
109 Pine Cone Trail
Medford, NJ 08055
A very nice log file analyzer was written by:
Tom Hogan, WB7DCH
26911 S E 456 St.
Enumclaw, WA 98022
I have included this on the release disk as LFA.COM.
Release notes, Version 9.3 :
In version 9.0, there was a change to the structure of the mail
file. When TNC is first run, it will update the mail file to
the new structure. This is done by doing an untangle. Don't panic
when this happens the first time you run version 9.3!
Changes and additions since version 9.2 are:
Added privelege A and B, excluded on A or B ports.
Removed LA and LN, was bad idea.
Support for S W0RLI @ K1BC installed...
Added H local command: short / long menu (=Help).
Added $X, $Y, $Z : Date, time, current msg # at last login.
Verify for files specified in config.tnc that the drive
is on line and write enabled.
L now lists new, LN same, LA lists all.
Faster forward - send "S XXX" and title then eat 2 lines.
Changes and additions since version 9.1 are:
Much faster untangle.
D, DP, DU for remote sysop.
CP ON/OFF and CR ON/OFF for remote sysop.
Changes and additions since version 9.0 are:
"Remote sysop" feature added.
Better handling of user record currency.
Excluded user disconnected with no "bye" message.
Fixed bug - long packets not get monitored properly.
Added ki4xo changes for 5" to boot, sbios, cbios.
Added GM, GU, OA, OB, C <call>.
Changes and additions since version 8.9 are:
Some changes to CBIOS thanks to ke1g give faster disk I/O
Added user privilege check. If E, then user is excluded from
use of the MailBox. N is used for normal user, and is default.
Fixed connect bug - now conok on is last sent, conok off is first.
Most searches go most recent first.
Added LL (List Last n), and LN (List New).
User file version 1, and DU - Display Users, EU - Edit Users.
Mail file structure version 2, back chaining of msg headers.
N menu item, rename file.
Changes and additions since version 8.8 are:
Fixed (again) the disconnect process.
Added DP - page mode.
G menu item replaces UNTANGLE, GR to renumber the messages.
L and private msg, show only to owner/sender/addressee.
Changes and additions since version 8.7 are:
Name of CONFIG.TNC file can be specified at execution time:
TNC OLDCFG.TNC or TNC NEWCFG.TNC for example. Defaults to CONFIG.TNC
if not specified.
The names for files CALLS.TNC, FWD.TNC, LOG.TNC specified in CONFIG.TNC
Installed ke1g improved cbios. Thank you Bill.
Y replaced by YC, YF, YL, switch calls, forward, or log files.
Fixed (I hope) the "Can't DISCONNECT, Link state is..." bug.
Added Z (delete file) to local menu.
X menu item forces forward regardless of hours given in FWD.TNC.
Was not passing "*** LINKED to" thru from next GateWay.
Not allow GateWay connect line with "tran" at end.
Changes and additions since version 8.6 are:
Fixed (again!) the lack of timeout when bombarded with con req.
Added UA (append) option to local menu.
Fixed dayclock month rollover.
Split EDMSG, FWD, MBFILE as separate routines.
--- End of extract ---