BILLW@MATHOM.CISCO.COM (William Westfield) (08/23/88)
There are many different serial encapsulations used by TCP/IP over serial lines. To start with, it depends on whether the line is synchronous or asynchronous. The protocol used on async lines (SLIP) is pretty standard, and has its own RFC (RFC1055). On synchronous lines, things are more complicated - for example, our (cisco Systems) products support about 5 different encapsulations. Two of these are X.25 and DDN X.25, which are pretty much standardized. An ordinary X.25 protocol analyzer is useful for debugging these. We also support LAPB (level 2 of X.25) with and without a "packet type" field, and a sort of bare HDLC protocol (which is not any sort of standard, but can be documented). Other vendors are rumored to use DEC's DDCMP protocols, and/or various non-standard protocols, some of which are considered proprietary. There is currently an Internet Engineering Task Force who is investigating the specification of a standard for Point-to-Point serial links, but this is likely to take a while, and it is still likely that a vendor would like to talk their own protocol to their own boxes. I don't know of any serial analyzers that support ANY of the TCP/IP formats used on serial lines - even the standard ones... Bill Westfield cisco Systems. -------
dennis@rlgvax.UUCP (Dennis.Bednar) (08/23/88)
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
barmar@think.COM (Barry Margolin) (08/23/88)
In article <977@rlgvax.UUCP> dennis@rlgvax.UUCP (Dennis.Bednar) writes: > Justification of the Rules: The justifications you gave explain why there must be SOME escape convention (which should go without saying), but not why that particular one was chosen. Why is this particular escape convention better than the old "double the special characters" convention or preceding a special character by the escape character? I don't think the doubled-character convention would actually work in SLIP because of the lack of a header (if a packet begins with FRMEND_data_char there would be three FRMEND characters in a row, and it would look like the FRMEND_data_char is actually the last character of the previous packet). But it would work to precede a FRMEND_data_char or FRMESC_data_char with a FRMESC: when forming a packet, you search for a FRMEND or FRMESC; if you find a FRMESC first you remove it from the stream, read the next character into the packet buffer, and then search again. The only advantage I see of the chosen scheme is that packetization and escape processing can occur as separate steps; was this the issue that resulted in this more complex scheme? Barry Margolin Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
swb@DAINICHI.TN.CORNELL.EDU (Scott Brim) (08/23/88)
>I don't know of any serial analyzers that support ANY of the TCP/IP >formats used on serial lines - even the standard ones... > >Bill Westfield For a project we almost did last year, both Tekelec and LP-COM were interested in writing a TCP/IP formatting module for us to watch T1 lines (taking into account the encapsulation schemes of several vendors), and for a reasonable price to boot. One of them was even willing to talk with us during the development process to make sure it suited our needs(!) I don't know if they went ahead without us or not. Scott
spp@zabriskie.uucp (Steve Pope) (08/24/88)
>The justifications you gave explain why there must be SOME escape >convention (which should go without saying), but not why that >particular one was chosen. Why is this particular escape convention >better than the old "double the special characters" convention or >preceding a special character by the escape character? > >Barry Margolin Let me attempt an answer -- the SLIP frame-escape method has the property that the only place a FRAME_END character appears in the SLIP-encoded data is between packets, i.e. FRAME_END doesn't occur within a packet even in escaped form. Thus, transmitting SLIP's use one or more FRAME_ENDs to clear an idle channel, and a receiving slip always knows to reset itself if it gets a FRAME_END. This approach might have a slight robustness advantage. Other escape conventions might not provide the transmitting SLIP with a definite way of resetting the receiver if the receiver is in an unknown state. steve pope (spp@berkeley.EDU)
vixie@decwrl.dec.com (Paul Vixie) (08/24/88)
# Let me attempt an answer -- the SLIP frame-escape method has the # property that the only place a FRAME_END character appears in the # SLIP-encoded data is between packets, i.e. FRAME_END doesn't occur # within a packet even in escaped form. Now let _me_ list another reason why this is a Good Thing. There are quite a few smart serial devices in the world these days. Most of the time they don't use any of their smarts -- getting UNIX line editing into the serial board is something one can be quite proud of, if one can make it work at all. If you can help do SLIP by adding some logic to your serial card, you can get a nice performance bang for a small amount of effort: tell your serial card to collect bytes until a timeout, buffer overflow, or terminating character in the input. If you use a large enough timeout and buffer, your main CPU only has to deal with SLIP when a whole packet has arrived. If you don't have a smart serial card, you can still get a little bit of benefit from this down in the lowest levels of your input driver. But if you have a protocol that makes you keep track of state between input characters, it gets harder no matter where you are trying to optimize it, and you will probably end up not optimizing it. Yours for fewer interrupts, -- Paul Vixie Digital Equipment Corporation Work: vixie@dec.com Play: paul@vixie.UUCP Western Research Laboratory uunet!decwrl!vixie uunet!vixie!paul Palo Alto, California, USA +1 415 853 6600 +1 415 864 7013
rminnich@super.ORG (Ronald G Minnich) (08/24/88)
In article <80@volition.dec.com> vixie@decwrl.dec.com (Paul Vixie) writes: >Now let _me_ list another reason why this is a Good Thing. There are quite >a few smart serial devices in the world these days. Most of the time they >don't use any of their smarts -- getting UNIX line editing into the serial Second the motion. Actually there have been quite a few systems over the years that support 'break sets' or 'tell me when you get this character or an overflow'. A few that come to mind: HP3000-supported 'tell me when you get a buffer terminated by x'- with timeout DG Eclipse with their smart ALM- supported programmable break sets. Commodore Amiga- supports 'tell me when you get a buffer terminated by x' Louie Mammakos' port of the Karn code uses the amiga's ability to suck up a bunch of characters 'til you get FRAME_END. This is a Good Thing. Saves the amiga OS a lot of work, and opens the possibility of letting a smart chip do the job. The 'two escape chars. in a row' seems like a good idea till you have to handle all the weird exception conditions... i had never really thought about why the way SLIP does it is such a good idea till now, but it sure is a good idea. ron