Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site mit-eddie.UUCP
Path: utzoo!linus!philabs!cmcl2!harvard!talcott!panda!genrad!mit-eddie!@DCN6.ARPA:mills@dcn6.arpa
From: @DCN6.ARPA:mills@dcn6.arpa
Newsgroups: net.ham-radio.packet
Subject: IP/TCP bumps and grinds
Message-ID: <78@mit-eddie.UUCP>
Date: Mon, 14-Oct-85 00:04:57 EDT
Article-I.D.: mit-eddi.78
Posted: Mon Oct 14 00:04:57 1985
Date-Received: Tue, 15-Oct-85 07:06:56 EDT
Sender: daemon@mit-eddi.UUCP
Organization: MIT, Cambridge, MA
Lines: 49

From: mills@dcn6.arpa
Folks,

Over the weekend I cobbled up a driver to connect my LSI-11/73 fuzzball to the
Heath HD-4040 TAPR board running the WA8DED firmware in host mode. The driver
provides interactive access from the operator terminal to the TAPR board as
well as Internet datagram access to our local net and the Internet world. My
intent was to bring up an experimental (access controlled) IP datagram gateway
in the Washington, DC, area. I found good news and bad.

The good news is that IP datagrams fly quite handily in connection mode. I was
able to connect to myself (via the WB4JFI-5 digipeater) and read the mail on
my fuzzball via the radio channel, which provoked some solid citizens to ask
what I was doing with all those unprintable characters. (Turns out one of the
solids was a coordinator for the DDN IP/TCP implementation program!) The flow
control and opaque coding problems I had with the orginal TAPR firmware are
absent. I was able to change the protocol-id field from the default (F0) to
the value assigned for IP (CC), but I doubt this avoided the clutter on the
screens of the curious eavesdroppers. I conclude the lashup works in
connection-oriented mode.

The bad news is that the drat thing does not play in connectionless mode. The
WA8DED firmware apparently refuses to believe the user is interested in U
frames as data and presents them as monitoring information instead. I can
understand the implementor's reluctance to horse around in this area, since to
do it right requires that the level-2 source route and protocol id be
available to the host. The WA8DED code attempts to hide all level-2 details,
which makes this hard. I would rather the entire packet, along with source
route and protocol id, be passed on to the host, instead of just the data
field.

As most of you probably know, the WA8DED firmware implements four virtual
channels, although they cannot be separately addressed from the radio side.
Thus, it should be possible for up to four remote TAPR/IP hosts to connect to
an Internet host on the other side of my fuzzball gateway, each on a separate
channel. This requires some way to associate return datagrams with the right
channel, which will require some sort of dynamic IP-address-to-callsign
mapping table. We Internetters have faced that problem before - with Ethernets
and X.121 public nets, not to mention volleyball tournaments.

It may be possible to fool mother nature by peeking at the first octet of the
monitoring message and capturing source routes in a configuration table,
possibly dynamically updated using the monitor-message header, which is
available in formatted form, but such heroics must await another weekend.
Meanwhile, if I can flush another LSI-11 rabbit from the underbrush here, the
first IP/TCP two-way may yet come to pass.

Dave, W3HCF
-------