Path: utzoo!attcan!uunet!rlgvax!dennis
From: dennis@rlgvax.UUCP (Dennis.Bednar)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Serial TCP/IP - all the same?
Summary: yes SLIP is a standard.
Message-ID: <977@rlgvax.UUCP>
Date: 22 Aug 88 22:32:53 GMT
References: <759@stcns3.stc.oz>
Organization: Computer Consoles Inc, Reston VA
Lines: 116

In article <759@stcns3.stc.oz>, dave@stcns3.stc.oz (Dave Horsfall) writes:
> Just a simple question - is there a single standard for TCP/IP over an
> RS-232 line (SLIP?), or are there many (like Ethernet1.0/2.0/802.3 etc)?
> 
> We are trying to determine what is wrong with our serial link (a CCI
> Power 6/32 running Sys V) and our local agents have never heard of a
> serial TCP/IP analyser, but are willing to write a protocol module for
> the famous LM-1 box.  If we can provide the specs, that is.

Yes, there is a single standard for SLIP.  It basically is a protocol
that describes the format and manner when sending IP packets over a
serial (RS-232 asynchronous) line. SLIP is not that complicated.
Basically SLIP describes the characters used to surround an IP packet,
and describes how such characters may be sent as data within the IP
packet by using data escaping conventions. There are several sources
of information:

	The recent RFC written by John Romkey (I believe) that describes SLIP,
	A mail message that I once posted that describes SLIP (below).

You can also use a line monitor (aka datascope) to look at the packets
on the RS-232 asynch line.  From my own experience, when things don't
work, it is usually a network configuration or routing problem.  Make sure
that your gateways file is correct.  Netstat or nstat may be helpful.
Also check that your hosts file is correct. Usually one of
the gateways doesn't know how to properly forward an IP packet, and the
packet sometimes loops until the TTL (time to live) field in the IP
header hits zero, and the packet disintegrates.

Finally, it would be rather easy to write a SLIP RS-232 line analyzer.
Simply dedicate two RS-232 ports for "passing thru" information, while
capturing it.  That is, read from port 1, and write the same to port 2,
and vice-versa. Place the two ports between the sending and receiving
machines, and you then passively intercept the traffic between the
two active machines. Then you can use your computer to analyze the packets
at a leisurely basis.  I once wrote such a tool.

Below is the text of an old message that describes the SLIP packet format,
and justifies the rules for the escape conventions used:

		How IP Packets are Sent over an Asynchronous Line



	+------------+--------------------------------------------+-------------+
	| LNI header |    LNI (Local Network Interface) data      | LNI Trailer |
	+------------+-----------+------------+-------------------+-------------+
	             | IP header | TCP header | optional TCP data |
	             +-----------+------------+-------------------+

	             |<------------ Data Encoding Rules --------->|


			Special Octets Used For Data Encoding

	 Name      Hex  Octal  Decimal    Description
	FRMEND     0xc0  0300    192      Frame End Character
	FRMESC     0xdb  0333    219      Frame Escape Character
	M_FRMEND   0xdc  0334    220      Meta Frame End Character
	M_FRMESC   0xdd  0335    221      Meta Frame Escape Character


	There is no LNI header for an asynchronous serial line.
	That is, there is no special character to introduce a sent frame.

	In the LNI data field, the sender applies the following rules:
	A data FRMEND octet is sent as FRMESC, M_FRMEND sequence.
	A data FRMESC octet is sent as FRMESC, M_FRMESC sequence.
	All other octets are sent without any translation.
	The receiving IP decodes by stripping and translating the extra octets.

	The LNI trailer contains only the FRMEND octet.
	That is, a frame is sent ending with the FRMEND character.



	Example:
	Want to send ('a', FRMESC, 'b', FRMEND, 'c').
	Sent as ('a', FRMESC, M_FRMESC, 'b', FRMESC, M_FRMEND, 'c', FRMEND).
	Note the last sent octet is not part of the LNI data field.



	Data Octet To Send               Data Sequence Actually Sent
	Hex   Octal   Decimal             Hex           Octal       Decimal
	0xdb  0333    219           (0xdb, 0xdd)    (0333, 0335)    (219, 221)
	0xc0  0300    192           (0xdb, 0xdc)    (0333, 0334)    (219, 220)






	Justification of the Rules:

	1. Sending the FRMEND data octet as a FRMESC, M_FRMEND sequence:
	   We must be able to send the FRMEND as a data character,
	   so the FRMEND has to be escaped, otherwise the receiver would
	   misinterpret it as a premature end of packet.


	2. Sending the FRMESC data octet as a FRMESC, M_FRMESC sequence:
	   Because the FRMESC is used as an escape, there has to be a way
	   of treating a FRMESC as data.  For example, if this rule weren't
	   defined, then there would be an ambiguous packet.  Suppose the
	   sender wanted to send the (data_char, FRMESC, M_FRMEND, data_char)
	   sequence.  According to rule 1 only, there would be no translation
	   of octets.  Therefore the receiver would receive it as
	   (data_char, FRMEND_data_char, data_char),
	   which is not what is intended.

-- 
FullName:	Dennis Bednar
UUCP:		{uunet|sundc}!rlgvax!dennis
USMail:		CCI; 11490 Commerce Park Dr.; Reston VA 22091
Telephone:	+1 703 648 3300