Hacker Chronicles 2/HACKER2.BIN/477.OVERVIEW.DOC

Text File | 1987-06-11 | 10KB | 176 lines

This is an overview of the various modules making up the KA9Q Amateur Radio
Internet Protocol package. Each section first describes the protocol that
is supported, followed by a description of the implementation.

Subnet layer:

A. Standard 10 megabit Ethernet.

The driver provided is for the 3-Com 3C500 (IE) controller for the PC.  Tight
(3 instruction) assembler loops are used instead of DMA for copying data in and
out of the controller's buffer; this seems fast enough.  Only the receiver is
interrupt driven; incoming packets are placed on a queue which is then emptied
at a more leisurely pace by the main loop code.  Since Ethernet is so fast,
the transmitter routine busy-waits for completion. The IE controller has only
a single buffer which is shared between receive and transmit. Packets
occasionally get lost under heavy load, especially when several TCP
connections are active at once and/or the TCP receive window sizes are
larger than the MSS values. This is very hard to fix without going to a
newer, more reasonably designed controller.

B. Serial Line IP (SLIP) - a very simple technique for sending Internet
Datagrams across ordinary asynchronous lines (e.g., modems). Its only function
is to delimit datagrams with framing characters, which are "byte stuffed"
for transparency. No error checking is provided; the checksums that are part
of IP, TCP and UDP are relied on for this.  SLIP is popular on UNIX
systems that support TCP/IP, so this represented the easiest way to get my
package up and talking with other Internet sites.  It also allows the use of
existing AX.25 TNCs without modifying the latter, although this is should
only be done as a stopgap measure until an HDLC link level driver can be
integrated directly into the package.

C. AX.25/KISS TNC - sends and receives IP and ARP datagrams encapsulated in
AX.25 Unnumbered Information (UI) frames. This allows an unlimited number of
simultaneous users on the local radio channel, since there are no
connections at link level.  The special AX.25 Level 3 Protocol ID values of
hex CC (IP) and CD (ARP) are used.

This mode of operation requires that the TNC run special "KISS TNC" code.  A
version developed for the TNC-2 by K3MC is provided in this distribution.
The standard TNC-2 ROM must be replaced with a bootstrap ROM and the KISS
TNC code downloaded into the serial port. Note that this style of operation
is NOT compatible with a "stock" TNC carrying SLIP formatted datagrams in
connected mode.

D. AX.25/PACCOMM PC-100 interface (NOT YET WORKING) - The PC-100 is an
I/O adapter card for the PC containing a Zilog 8530 Serial Communications
Controller and two AMD 7910 World Chip modems.  The encapsulation method
is identical to (and compatible with) the AX.25/KISS TNC interface driver.

E. Address Resolution Protocol (ARP) - used for the automatic mapping of IP
addresses to link or subnet addresses. While originally designed for the
specific task of mapping IP to Ethernet addresses, the protocol is general
enough to be used on any link or subnet that supports a broadcast facility.
ARP is described in ARPA RFC-826.

Both Ethernet and AX.25 format addresses are currently supported.  Instead
of discarding a packet when an ARP request is sent, this implementation
holds it on a queue for a limited time, pending a response to the request.

Internet layer:

F. Internet Protocol (IP) - the universal network-level datagram protocol
of the ARPA Internet. It corresponds roughly to level 3 of the ISO Reference
Model (ISORM). (Actually, IP belongs to the 3B internetwork sublayer if you
follow the amoeboid proliferation of ISO sublayers). Routines are provided
to generate, receive and route (i.e., packet switch) IP datagrams. IP is
specified in ARPA RFC-791 and MIL-STD-1777.

IP datagram fragmentation and reassembly is fully implemented. The IP options
Loose Source Routing, Strict Source Routing and Record Route are supported;
Stream ID, Security and Timestamp are ignored. (Few, if any, IP options are
used extensively in the ARPA Internet).  The IP module includes a routing
(packet switching) facility; currently this consists of a table containing a
list of host-specific destinations along with a "default" entry that may be
used when the desired destination is not found in the table. No protocol is
yet provided to actually manage the table; currently it must be done manually,
either locally or remotely.  NB! "Networks" (in the ARPA Class-A/B/C sense)
are not yet understood, in that all entries in the routing table (except for
the default entry) must be host-specific.  This will be fixed in the future
with a "generalized subnetting" scheme that will allow each entry in the table
to have an arbitrary, variable length "subnet mask."

G. Internet Control Message Protocol (ICMP) - the error reporting adjunct
to IP. It appears as a pseudo-protocol on top of IP, but is actually
considered to be part of IP. The IP routines automatically generate ICMP
messages whenever an error occurs in the processing of IP datagrams;
incoming ICMP messages are passed up to the originating end-to-end protocol
for appropriate action. ICMP is specified in ARPA RFC-792.

This ICMP supports all options except ICMP Timestamps.

Host-Host Layer:

H. Transmission Control Protocol (TCP) - provides a reliable, sequenced
"virtual circuit" or "connection-oriented" service atop IP on an end-to-end
basis. It corresponds to the Transport layer (level 4) of the OSI model.
Since a single TCP module supports multiple connections through the use of
port numbers, it also provides Session (level 5) functionality without
the need for a distinct layer. (Or it makes the session layer unnecessary,
depending on your point of view). TCP is specified in ARPA RFC-793 and
MIL-STD-1778.

The implementation supports an arbitrary number of simultaneous connections,
limited only by memory space for control blocks. An "upcall" mechanism is
available to notify the user of three events: connection state change, receive
data available and transmit buffer space available. The Maximum Segment Size
option is understood and used when it is received, and a global variable is
used for generating MSS in outgoing segments. There is currently no
provision for sending URGent data.  The latest recommendations on "tinygram"
avoidance (Nagle, ARPA RFC-896) are implemented and work quite well.

I. User Datagram Protocol (UDP) - provides only a simple, unguaranteed
"datagram" or "connectionless" service, adding only checksums and port
multiplexing to the raw service provided by IP. As an alternative to TCP,
UDP also sits at level 4 (and 5) of the ISORM. UDP is specified in ARPA
RFC-768.

The implementation supports the creation of queues on local sockets. An upcall
mechanism similar to that used in TCP notifies the user when datagrams have
arrived.

Application Layer:

J. File Transfer Protocol (FTP) - for transfer of binary or text files
between hosts. FTP uses two TCP connections - one for exchanging commands and
responses in the form of ASCII strings, and the other for the actual
data transfers. FTP is defined in ARPA RFC-959.

FTP is implemented in two parts, a server half and a client half. The server
half supports multiple simultaneous remote users, although at the moment
there is no access control; anyone may access, delete or overwrite any file
on the machine.  The client half is invoked by the "ftp" command.

K. Remote login protocol (Telnet) - for logging into remote systems and
negotiating various options, such as remote vs local echoing. Telnet itself
is documented in ARPA RFC-854, with the many options defined in other
RFCs.

The client half supports the ECHO and TRANSMIT-BINARY options; it is invoked
by the "telnet" command. A telnet "server" has been written, but since MS-DOS
isn't a timesharing system it is used for keyboard-to-keyboard conversations
instead. An incoming connect request to the local Telnet port creates a local
Telnet session and notifies the local user. He may then select the new session
and carry out a conversation with the remote initiator.

L. Simple Mail Transfer Protocol (SMTP) - as the name implies, is used for the
transfer of electronic mail between hosts. SMTP commands and responses are
strings of ASCII characters resembling those used by FTP. SMTP uses a
single TCP connection for both control and the actual mail messages.
SMTP is described in ARPA RFC-821; headers in mail messages are described
in RFC-822.

A simple version server (receiver) is implemented; it accepts mail from a
remote sender and appends it to a mailbox. Mail forwarding, which accounts for
much of the complexity in other mail servers, is not implemented. A mail
client ("user agent") for composing and sending messages developed by Bdale
Garbee, N3EUA, is included.  It is called 'BM', and is documented elsewhere.

M. Session control - the user may manage several simultaneous Telnet and
FTP client invocations. Only one client session is "active" at any one time,
but the user may quickly switch between them. Terminal output arriving for
an inactive session is held until that session is again made active.  (Note
that this is in addition to the multiple server sessions which go on
automatically "in the background", i.e., without operator intervention).

The Internet package has been tested with and works under DoubleDos 3.1U
by SoftLogic Solutions, allowing the system to be simultaneously "on the net"
while executing conventional MS-DOS commands.  The net program uses the special
DoubleDos function call 0EEH to relinquish the processor when it isn't needed;
this speeds up the task running in the other partition.  This function is a
"no-op" when DoubleDos isn't active.

Phil Karn, KA9Q
4 Nov 1986

updated 870525 by Bdale, N3EUA