Ethereal-users: [Ethereal-users] Ethereal and PPP (as in, the protocol, not the capture interfac

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: Stephen Oberholtzer <soberholtzer@xxxxxxxxxxxxxx>
Date: Sat, 14 Sep 2002 02:02:37 -0400
Here where I work, we work with embedded devices that communicate with a
central gateway over a shared physical medium, using PPP as the protocol.
The devices are individually identified by using the full
PPP-with-HDLC-like-framing protocol like thus:


xx 03 yy yy    . . .   zz zz
^^    ^^ ^^            ^^ ^^
 |    protocol         16-bit checksum
 |
device address


This physical medium is of a serial nature, and we have a utility that can
capture the data from a serial port and decode it into PPP, IP, and UDP/TCP
pieces.  Unfortunately, it's a piece of crap.  It has no logging or
filtering ability, does not handle truncated frames well at all (displays
random junk), and crashes any time it receives more than a few packets every
minute :(  Because of this, I would very much like to use Ethereal to
analyze these packets.

Since Ethereal cannot capture from a serial port, I created a simple program
that would log the data from the port and create a libpcap capture file to
view in Ethereal.  I set the 'link type' in the file header to
LINKTYPE_PPP_HDLC (50), which the comments in libpcap's savefile.c describe
as follows:

 * LINKTYPE_PPP is for use when there might, or might not, be an RFC 1662
 * PPP in HDLC-like framing header (with 0xff 0x03 before the PPP protocol
 * field) at the beginning of the packet.
 *
 * LINKTYPE_PPP_HDLC is for use when there is always such a header; the
address field
 * might be 0xff, for regular PPP, or it might be an address field for Cisco
 * point-to-point with HDLC framing as per section 4.3.1 of RFC 1547 ("Cisco
 * HDLC").  This is, for example, what you get with NetBSD's DLT_PPP_SERIAL.


However, when I load the created files up in Ethereal, it recognizes the PPP
part, but assumes that anything
that doesn't start with 0xFF doesn't have the (address, 0x03) prefix.


It gets better! It does NOT properly decode the 0x7D escape prefix, which is
required upon the initial sync-up:


ff 7d 23 c0 21 ...

This is the beginning of an LCP packet (c021).  As per the PPP RFC, until an
async char map is negotiated,
all control characters (0x00 to 0x1F) must be escaped with 0x7D.  However,
Ethereal decodes this packet as:

Address: 0xff
Control: 0x7d
Protocol: OSI (0x0023)

and displays "Unknown ISO protocol (c0)" in the Info column.



Shows you how often anybody ever looks at PPP in Ethereal.



-- 
Stevie-O

Real programmers use COPY CON PROGRAM.EXE