Re: Serial TCP/IP - all the same?


Dennis.Bednar (rlgvax!dennis@uunet.uu.net)
22 Aug 88 22:32:53 GMT


In article <In article <759@stcns3.stc.oz>, 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



This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:43:13 GMT