brian@sdcsvax.UUCP (Brian Kantor) (05/30/85)
From Clifford Neuman <bcn@mit-eddie.ARPA> Tue May 14 11:48:12 1985
Subject: Welcome to the packet-radio mailing list
Welcome to the packet radio mailing list. This list is intended to
provide a forum where people can exchange ideas about packet radio, and
describe projects they are working on. Mail for the list should be sent
to packet-radio@mit-eddie and administrative requests (addition and
deletion, etc) should be sent to packet-radio-request@mit-eddie.
MIT-EDDIE can be reached through the internet, MIT's chaosnet, and via
UUCP ({decvax!genrad,ihnp4}!mit-eddie). Old message will be archived on
eddie in /projects/packet/packet.archive obtainable through anonymous
FTP.
~ Cliff (N1DMM)
From Clifford Neuman <bcn@mit-eddie.ARPA> Tue May 14 11:48:12 1985
Subject: Reason for starting this mailing list
I would like to briefly outline my reasons for creating this mailing
list. In the past week I have come across several pieces of mail
dealing with packet radio experiments. These messages described work
that was in progress getting TCP/IP to run on top of packet radio.
Since the content of the messages was fairly technical, and since they
were fairly long, the senders probably decided not to bother the
info-hams list with them. Hopefully, with the creation of a mailing
list for packet radio, reports of these projects will get a wider
distribution. Of course, other traffic dealing with packet radio is
also welcome.
One person was concerned that moving packet discussion to another list
would make it less visible, and thus, less new amateurs would be
infected by it. This is a valid concern. As such, it may be
appropriate to continue sending messages of a general nature to
info-hams, and to use this list for development.
~ Cliff (N1DMM)
From bellcore!karn@umd5 Wed May 15 08:09:52 1985
Date: Tue, 14 May 85 17:26:35 edt
Subject: Proposed standard for IP on AX.25
I would like to solicit comments on the proposal I made at the San Francisco
packet conference for a standard for sending IP datagrams over AX.25 links.
The main issue is the question of implicit vs explicit fragmentation of
large IP datagrams. Fragmentation of some sort will be necessary here because
AX.25 packets are limited by convention to 256 bytes. My original proposal
calls for explicit (i.e., IP level) fragmentation only. However, if you are
going to go to all the trouble of implementing a full connection-oriented
link layer that maintains sequencing, it might be worthwhile to consider
implicit sequencing (i.e., sending one datagram as several numbered
I-frames). This would help reduce overhead somewhat.
On the other hand, as a believer in making "end-to-end" protocols truly
end-to-end (the words of Michael Padlipsky preaching the evils of protocol
conversion gateways still ringing in my ears) I have of late been looking
for ways to cram TCP into an existing TNC. To do this, I will likely have to
dump 95% of AX.25 Level 2, using only the "unnumbered information" (UI)
datagram hook to send IP. This may be enough to support IP if links are
fairly reliable and/or not too many hops are cascaded, and would allow
getting rid of a lot of excess baggage. (Backbone gateways may still use the
full AX.25 between themselves on long paths to improve performance. They
don't have to implement TCP, so they'll have the space.) This would, of
course, allow only for explicit fragmentation.
If anyone doesn't have access to a copy of the proceedings and is interested,
please let me know. If there is sufficient interest I can send the relevant
section to the list.
Phil Karn, KA9Q
From michel@bbncct Wed May 15 08:44:28 1985
Date: Wed, 15 May 85 9:42:42 EDT
Subject: IP over X.25
Some comments on the msg from Phil KA9Q...
I have been wrestling for some years now with the problems of getting
X.25 going on the MILNET, and then of getting IP going over X.25. What I
imagine that I have learned may stir up some controversy. Let's try.
1. X.25 was obviously promulgated by a committee. It has something for
everyone. It has incredible complexity and obscurity, most of which
is of little use, except to help some other part of the spec. Because
the spec is complex, implementations tend to be complex and large.
Because the X.25 spec is written in a strange sort of diplomatic/technical/
legalese and because it gives little guidance as to implementation,
there is little hope that one X.25 implementation will talk to another
without considerable work. At least it seems to work out that way.
I haven't seen the AX.25 spec. Has it been the case that AX.25
implementations are fairly compatible and inter-operable?
It seems to me that the design of X.25 was strongly influenced by the
need for a connection-oriented (because the thinking was very telephone
oriented at the European PTTs who are influential on the CCITT), reliable
(more-or-less guaranteed delivery), efficient (puts a lot of data bits
per overhead bit in a packet) "protocol." These are reasonable goals
in a land-line world. Probably they are reasonable as well in the 1200
bps technology at 145.01 Mhz (and they are still reasonable up to 9600bps).
2. TCP emerged from a rather different sort of committee which had several
experienced communications scientists in a dominant role. The TCP spec is
clear, concise, and would surely infuriate lawyers or diplomats. However,
TCP implementations also seem to be complex, and don't usually work on the
first try. The IP implementation also turns out to be harder than
it looks on a first pass through the spec.
Some of the goals of TCP are: end-to-end connections and reliable delivery.
Efficiency is explicitly and knowingly sacrificed for function. That is,
there are LOTS of "overhead bits" in every TCP segment. There are lots
more in the underlying IP datagrams.
3. So. Does this mean anything? I think it means that running TCP
connections over X.25 is not a good idea. Especially when you attempt
to use X.25 as an end-to-end discipline. Much more can be said
on this point.
4. Relevance to packet radio. It seems to me that the way to approach
amateur packet radio has two paths: one for high and one for low data
rates. For low rate (less than 10,000 bps) simple X.25 or some derivative,
is appropriate. This would be appropriate for local distribution, for
PC connection, and other things like the present amateur packet system
does. For higher (and higher, and higher) rates (64Kb, 1.5 Mb) then it
makes sense to use the IP family of protocols. And in this case, the
lower levels should not be X.25 or HDLC or any other complex discipline.
Fragmenting datagrams should be done judiciously (not entered into lightly,
etc). Once you got a datagram apart, you got trouble.
5. Note that this approach seems to imply that you must have protocol
translating gateways, which irritates some folks. There are some
interesting ideas emerging about how to do this, for example the
Thinwire Protocol (Farber et al. at U of Deleware).
6. ANother approach, if you want to carry the IP datagrams out to the
destination has been adopted in one of the interfaces for the IBM-PC
TCP developed at MIT (Saltzer et al.). They have defined a scandalously
simple discipline for carrying the IP datagram across an async start/stop
"TTY" link.
7. Yet another approach, for use when you want a minimal connection-oriented,
fairly reliable path could adopt RATP (Reliable Async Transfer Protocol)
proposed (Network Working Group RFC 916). RATP looks like the winner
to me, compared with any derivative of X.25.
Finally, let's all try to stamp out HDLC. It's silly. Much too hairy,
and what's the use? All that whirring and grinding of link up, link down,
link ready, not ready. If you're getting something, presume the link is up.
Always send when you want to.
AXM
From jim@rand-unix Wed May 15 13:48:41 1985
Date: 15 May 85 13:06:11 PDT (Wed)
Subject: Initialization advice requested
I haven't had a radio since my TS-520 was stolen several years ago, but
packet has inspired me to get back in. I'm tempted to charge off and get
the Heath TNC and dive in right away, but now that TAPR is coming out with
a new version I'm also tempted to wait. Since there's no particular rush,
could somebody in the know advise me:
(1) How much better is the TAPR-2 is likely to be? Worth waiting for?
(2) What's a good radio to use with packet - should I stick with 2M, or
get something with higher frequency to give better speed? Low price
isn't critical - I'd rather spend a bit more if it buys me a lot more.
On the other hand, the L.A.-S.D. area seems to be mostly (all?) 2M.
Thanks...
Jim Gillogly, WA6FAA
From clements@bbncd1 Wed May 15 14:24:42 1985
Date: Wed, 15 May 85 17:00:39 EDT
Subject: Westnet map
*** Subject: Map of installed 145.01 Digipeater paths
______________________________________________________________________________
| * |
| * April 16, 1985 |
| * WESTNET MAP - installed digipeaters |
| * 145.01 MHz |
| * Map shows southern 2/3 of California |
| * |
| * SCDCC and PPRS recommend that no new |
| * message systems be placed on 145.01 MHz. |
| * W6IXU provides network message service. |
| * |
| * AMT - W6AMT-n |
| * BXN - W6BXN |
| * HHV - WB6HHV-1 |
|* <SAC> * IXU - W6IXU |
| * QIF * NK6K - |
| * * QIF - K6QIF |
| ****** * RWN - WA6RWN |
| * * * SOX - KA6SOX-1 |
| * * <SF> * |
| * * * * |
| * ** * No beacons or CW ID please. |
| * <SJ> * |
| * AMT BXN * |
| * * |
| * * * |
| * * |
| * <FR> * |
| * * |
| * * |
| * AMT-1 RWN * |
| * * |
| * * |
| * * |
| * * |
| * * |
| * * |
| * IXU * |
| * * |
| * * |
| * * |
| ******SOX-1 AMT-2 * |
| ****<SB> * |
| * *|
| *** <LA> *|
| <SAC> - Sacramento *** *|
| <SF> - San Francisco **NK6K-1 AMT-3 * |
| <SJ> - San Jose * * |
| <FR> - Fresno * * |
| <SB> - Santa Barbara * |
| <LA> - Los Angeles * * |
| <SD> - San Diego * * |
| * HHV-1 * |
| Straight line distance SAC to SD 480 miles. * <SD> * |
| Shortest RF path 627 miles. ************************* |
| Map by NK6K with W6IXU and NI6A. |
-------------------------------------------------------------------------------
*** End of message from NK6K VIA KA6SOX-1,NK6K-1
From clements@bbncd1 Wed May 15 14:35:07 1985
Date: Wed, 15 May 85 16:59:44 EDT
Subject: Eastnet map
EASTNET8.MAP
(revised)
April 10,1985
by K1HTV
The following is a graphic representation of Packet Radio links
which are believed to exist on 145.010 MHz on the East coast of
North America, from the U.S./Canadian border to Miami, Florida.
Included are digipeaters, PBBSs, and home stations usually left
on for digipeating. The primary routes used for mail forwarding
in EASTNET are marked with asterisks (*). Those links in which
Are marked with a question mark (?) indicate a link of unknown
reliability. If you have any information which would confirm
that they are reliable are if you see any indicated links which
are known to be either unreliable or non-existent please drop
the keeper of the maps (K1HTV) a note by EASTNET mail (PBBS),
U.S. mail, or a phone call.
===============================================================
(Ottawa, Canada-----> VE3PAK - -VE3FXI (pbbs)
\
(??, NY -----> W2UXC-1
\
(Plattsburg, NY -----> KD2AJ
\
(Mt Ascutney,VT -----> WA1TLN-1
* * :\
(Peru,MA ------------> KY1H * : \
(Lowell,MA -----> * * KD2S-1 |
* |* * | |
* | * * | |(pbbs)
(Haverhill,MA ------> * | * * | KA1CB
(Mt.Graylock,MA -----> * K1FFK-1 * *|/
(Westford,MA -----> * /| \ * W0RLI (pbbs)
* / | ? *
(So.Windsor,CT -----> * ? | W1AW-5
* / ? /* |
(Newington,CT-----> * / | ? * W1AW-4(pbbs)
* / | / *
(Highland,NY-pbbs-> WA2RKN-2 */ | / WA1IXU <--Wolcott,CT)
* * |/ *
(Mt.Beacon,NY -----> WB2KMY-1 ** KG1O-9 <---- Mt. Ninham)
/ | * * (Carmel,NY)
(nr Greenstown,PA->WB3EIJ | * *
| | * *
(Oakland,NJ -----> | | WA2SNA-2 -- AI2Q <Freeport,LI,NY)
| | | *
| N2DSY-2 * <--- Little Falls,NJ)
| \ *
(Wilkes Barre,PA --> K3RLI \ *
| \ *
| \ *
| \ *
| \ *
(Reading,PA---> WB3FYL | *
/ | | *
WA3KXG | | *
(H'burg,PA---< * * \ | | *
(pbbs) AK3P * K3DSM-5 | * <----- Malvern,PA)
* | \ WB2MNF | * <----pbbs Medford,NJ)
* | /\ * | * <----- Atco,NJ)
* | KC2TN \ * | *
* | / \ * | *
(Elk Neck,MD--> WB4APR-6 * * * * WB2RVX <---- Voorhes,NJ)
* * |
(Clarksville) * * |
(pbbs---> W3IWI--W3GXT-5| <------------ Baltimore,MD)
/* \ * | |
/ * *\ | |
/ * \ | |
/ KS3Q \ | | <--- pbbs Burtonsville,MD)
/ | \ \ | |
WB4JFI-5 - - WB4APR-5 <-- Annapolis,MD)temporarily off air
(DC) | |
| |
| WB4APR-4(temp 5) <----- Point Lookout,MD)
WG4T | <--------Charlottesville,VA)
(Roanoke) | ?
WB4QOJ---K4LKQ-1 | <---- Lynchburg,VA)
| \ | K4UMI-5 <------------Norfolk,VA)
| \ |
| (?) <----- Greensboro,NC)
| |
| (?) <----- Charlotte,NC)
(?) | <----- Florence,SC)
(missing links) <----- South Carolina)
|
WB4GQX-1 <----- Atlanta/Gainsville,GA)
\
WA4LYV <------ Sycamore,GA)
\
KA4DPF <----- Tipton,GA)
\
WB4RCY-1 <----- Jacksonville,FL)
\
KF4TT-1 <----- Gainsville,FL)
|
K4OZS <----- Ocala,FL)
\
\
N4JWX <----- Orlandao,FL)
\
(Clearwater) \
KC2FF------W1BEL----?----N2WX-7 <----- Melbourne,FL)
(Tampa) \ |
? |
\ |
(Okeechobee,FL----> WA4IYY |
\ |
K4NTA-1 <----- Stuart,FL)
|
WA4ARE-1 <----- W.Palm Beach,FL)
|
W4LDP-1 <----- Ft.Lauderdale,FL)
|
W4NVU <----- Miami,FL)
Please send any corrections or additions to the above linking
map to K1HTV via one of the EASTNET Packet Radio Bulletin Board
systems, the U.S. mail, or a phone call. Thanks.
73, Rich Zwirko - K1HTV
12509 Ransom Drive
Glenn Dale, MD 20769
phone (301)464-2133 (4:00-10:00 PM)
From bellcore!karn@umd5 Wed May 15 15:45:35 1985
Date: Wed, 15 May 85 18:14:34 edt
Subject: AXM's comments on TCP vs X.25
Tony, thanks for your comments.
At the risk of bringing over the "protocol wars" in which I and a couple of
the other technically-oriented packeteers have been embroiled for the past
9 months, I would like to add my own thoughts regarding TCP/IP vs X.25.
(Those who know me have most likely already heard this sermon.)
First of all, I wholeheartedly agree with your comments about X.25 being
incredibly complex and obsure. It also has a LOT of redundant functions,
with perhaps the best example being flow control at every layer.
I should point out that what is called "AX.25" is ONLY the link layer (LAPB)
from X.25 that has been bastardized to include both source and destination
callsigns in each packet. There is also the "digipeater" feature which
allows source routing through a chain of store-and-forward repeater
stations. The digipeaters are stateless and are thus very simple; only the
end stations participate in the "connection" and have to implement the
LAPB protocol.
Note the remarkable similarity between this and TCP/IP. AX.25 really
consists of two sub layers. The upper layer, which is essentially unmodified
LAPB, is being used as an end-to-end, virtual circuit, pseudo-transport
protocol analogous to TCP, while the lower layer, new with AX.25, is a pure
datagram protocol analogous to IP. (Obviously, TCP/IP are both much more
complete and robust than AX.25). This is all the more remarkable when you
consider that some of the main authors of AX.25 are the most vocal
detractors of TCP/IP, but I digress...
As it turns out, AX.25 implementations *have* been fairly compatible. Most
of the problems of late have not been misinterpretations of the spec,
but rather latent software bugs that have caused problems when boards
running the latest revision of the protocol try to talk to some of
the popular boards that have the original version. The revisions consist
mainly of adopting the remaining features of LAPB, such as timers T2 and T3.
These require the use of the poll/final bit and the availability of the
LAPB command/response indication, which was "broken" by the earlier
modification to the so-called LAPB address field. The changes to the spec
were carefully made to be backward compatible, but some problems always seem
to surface...
Regarding the overheads of TCP/IP vs X.25. While it is of course true the
the headers of TCP segments and IP datagrams are truly enormous to those
used to the "pathological bit-saving fetish" (to quote M. A. Padlipsky) of
X.25, you can always make overhead arbitrarily small by increasing the
allowable packet size. I got quite a reaction out of the X.25/VC "camp"
recently when I pointed out to them that the tiny packet size limits
actually in use on X.25 networks result in several percent MORE overhead in
a file transfer across X.25 than on a TCP/IP network!
Yes, I found RFC79[123] to be a breath of fresh air after the pseudo-legalese
of the CCITT documents. They can still take a lot of work to implement, but
are they really any harder than doing X.25, given that X.25 doesn't say
anything about how you build a network INTERNALLY? Don't forget that you
need a routing protocol, and an error-reporting protocol, and...
As I've said earlier, I think that TCP over AX.25 is a viable proposal,
especially given the amateur environment which may require link level
reliability measures (provided by AX.25) to improve performance over many
cascaded links. True, CSNET had real problems with performance in running
IP over X.25 due to the latter's tight window and packet size constraints,
but fortunately in AX.25 there is a "hook" into the underlying datagram
layer that allows you to bypass all that connect-oriented link level stuff
if you don't want it. I've been developing some rather strong feelings of
late against protocol conversion gateways. They increase the overall
complexity of the network with little benefit, restrict flexibility in
supporting new applications, and represent a reliability weak point. I
would rather do things "right" the first time instead of bending over
backwards to accomodate everything that has been done in recorded history.
I am aware of the various methods for sending IP datagrams over serial lines;
I are using SLIP here as an interim interlocation IP link for our 4.2BSD
machines. I like SLIP, and have suggested it be used between components
such as a "TCP-TNC" (e.g., an IBM PC running the MIT PC/IP code) and a
packet switch on, say, a Xerox 820. There's no need to waste precious HDLC
controller ports on short wire connections at slow speeds, especially when
there is no requirement for absolute reliability since you're just carrying
datagrams. FADCA and TAPR have developed an add-on board for the Xerox 820
that provides two HDLC channels (with a Zilog 8530) in addition to the two
HDLC/asynch channels already available with the Zilog SIO on the 820. This
means that an IP packet switch could be built on the 820, routing datagrams
between two SLIP/asynch ports connected to local TCP boxes, 4.2BSD machines
or dialup modems, and two AX.25/HDLC ports which can be connected to radios.
Anybody want to help implement this switch? I've already gotten the AX.25
code written and running, with the hooks for the packet switch layer. It
maintains multiple logical AX.25 connections over multiple physical links,
and is currently being used by a number of amateurs as a simple TNC.
I don't understand what you mean when you say "stamp out HDLC". Are you
referring to just the use of LAPB, the connection-oriented link layer
protocol, or are you also objecting to the use of the synchronous bit-stuffed
line encoding scheme? I agree with you on the former, but of course it's
needed for X.25 because the upper layers depend on reliable link connections.
Of course, IP lets you get around this, so you can still use "raw" HDLC
frames without LAPB if you want.
However, I do think that *raw* HDLC is very desirable on packet radio
channels. By "raw" HDLC, I mean the functions that are provided in chips
(e.g., the Intel 8273/4 and the Zilog SIO and 8530), including synchronous
transmission (saving you 2 bits/byte while still maintaining transparency),
packet framing and CRC protection. This greatly simplifies the software
design. They also make the use of DMA much easier (ask anybody who runs a
big UUCP gateway what incoming character interrupts do to his CPU.) No
amateur packet board uses DMA yet, but I think it'll be absolutely necessary
to go much beyond 9600 baud, the minimum channel speed for what I'd consider
"non-toy" applications.
Phil
From ron@BRL.ARPA Thu May 16 20:32:22 1985
Date: Thu, 16 May 85 22:41:27 EDT
Subject: Re: IP over X.25
I should point out that the fragementation issue is pretty much the
same if you are talking IP or link level. Doing it at the link level
wins out because you save copying the IP headers. Once you get around
that problem you must realize that fragmenting TCP datagrams is a BAD
idea. None of the reliability features of TCP handles (or can even
know about) a fragmented packet. While TCP can take care of out of
sequence or missing datagrams, it only handles it's own. If something
stomps on your IP or link fragment TCP handles it by assuming the entire
message was lost. For preformance in a lossy environment, you need to
bring the TCP datagram size down to that which can be sent over your
net without fragmentation.
-Ron
From @DCN6.ARPA:mills@dcn6 Thu May 16 22:22:23 1985
Date: 17-May-85 03:00:27-UT
Subject: Re: IP over X.25
Ron is reacting to traumatic experiences at BRL behind flakeways that drop
rather more packets than usual, in other words a fair model for a packet-radio
net. IP reassembly usually involves holding partially reassembled fragments
pending arrival of all of them. Under conditions of high packet losses, the
reassembly queues tend to clog with partially complete packets. Also, the
situation tends to create huge dispersions in retransmission-delay estimates,
leading to excessive retransmissions.
There is clear implication in the spec that end-end TCP peers should be able
to negotiate DOWN the 576-octet maximum packet size, as well as UP, but most
implementations refuse that (fuzzies are more flexible) magic. There are well-
known problems when the peers are themselves on big-packet nets with a small-
packet net in between (how would they know that?), but Amateur packet-radio
nets are not likely to fit that mold. Accordingly, one of the tricks the TCPs
need to learn is to believe the TCP max-size option and really do reduce the
max size.
Dave
-------
From milazzo@rice.ARPA Fri May 17 00:53:16 1985
Date: Fri, 17 May 85 01:28:01 CDT
Subject: IP over X.25 - the CSNET experience
I have spent some time helping to develop the CSNET IP-over-X.25
software, and still poke my nose into it on occastion. The CSNET
experience could be particularly instructive to packet-radio developers
because for various obscure technical reasons, the CSNET software
cannot negotiate away from the default of 2 outstanding 128-byte X.29
packets per channel. This situation is, according to my understanding,
similar to the current AX.25 standard.
In order to achieve suitable transmission rates in the CSNET/X25NET
environment, the original designers adopted a complex protocol
involving implicit fragmentation and round-robin use of multiple
simultaneous open X.25 channels. Channels are opened whenever an IP
datagram needs to go somewhere and no idle channels are available to
that destination. Later we added code to close channels after a
certain period of inactivity.
Well, it all sounds neat, but in practice it's a nightmare. After
three or four years of work, the implementation still does not address
certain fundamental problems such as (1) packet lifetime on a channel
queue or (2) downward tracking of channel utilization. Some of these
problems don't seem to have any sort of reasonable solution.
In summary, I agree with Phil Karn. Put the IP implementation above
your datagram ("digipeater"?) layer and let TCP provide end-to-end
reliability. X.25 and TCP/IP both have their places, but they don't
mix well at all.
If someone would like a more complete discussion of some of these
issues, please let me know. First, however, I recommend reading some
of the CSNET/X25NET design documents which the nice folks at CSNET
<cic@csnet-sh.ARPA> will no doubt be happy to provide.
Paul G. Milazzo
Dept. of Computer Science
Rice University, Houston, TX
ARPA: milazzo@rice.ARPA
UUCP: {cbosgd,convex,cornell,hp-pcd,shell,sun,ut-sally,waltz}!rice!milazzo
From Murray.pa@Xerox.ARPA Fri May 17 07:27:55 1985
Date: 17 May 85 06:41:11 PDT
Subject: Error rates
What's the ball park for error rates on amateur packet radio links?
From @DCN6.ARPA:mills@dcn6 Fri May 17 08:51:30 1985
Date: 17-May-85 14:31:02-UT
Subject: Re: Error rates
In-Reply-To: Your message of 17 May 85 06:41:11 PDT
Murray,
My experiments using loopback via two local digipeaters and IP/ICMP echo
messages showed packet-loss rates from one in four to one in ten, depending
on link quality between my TAPR and the digipeater. TCP/TELNET over full-bore
AX.25 worked reasonably well with AX.25 retransmissions for error control
and some (spurious) TCP retransmissions because the TCP round-trip delay
estimation algorithm had a tough time with the delay dispersions due AX.25
retransmissions(!), but the AX.25 broke after some 250 TCP segments on
good links and after only ten TCP segments on marginal ones.
Obviously we need a lot more data on link quality. I want to run link tests
using unsequenced, transparent mode, but my TAPR won't let me loopback to
myself in this mode. I'm trying to find volunteers locally that I can give
an LSI-11 fuzzball to.
Dave
-------
From ihnp4!cbnap!gws@mit-eddie.ARPA Sat May 18 14:45:44 1985
Date: 18 May 85 15:42:13 CDT (Sat)
Subject: packet programs lsi-11
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