[Guy Harris <gharris@xxxxxxxxx>]

On Sat, Sep 14, 2002 at 02:02:37AM -0400, Stephen Oberholtzer wrote:
> 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

	...

> 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.

There are, I think, at least some capture files that use the same
identifier in the per-file or per-packet header for both
PPP-in-HDLC-framing using only the all-stations address and Cisco HDLC,
which would require there to be a PPP dissector that, at minimum, treats
anything that begins with 0x0f or 0x8f as being Cisco HDLC rather than
PPP.

In addition, there are files that don't distinguish between
PPP-with-HDLC-like-framing and PPP-with-no-framing-whatsoever, which
requires there to be a dissector that looks for the default HDLC-like
framing and, if it doesn't see it (or a Cisco HDLC header), assumes it
has PPP-with-no-framing.

It would probably be possible to, for some other capture file identifier
(or capture file *type*, which, if you read on, you will see is what you
really need here), have it assume that all frames use RFC 1662 headers
but don't necessarily use only the all-stations address, in which case
there could be another dissector to handle that case.

> It gets better! It does NOT properly decode the 0x7D escape prefix,

It does not even *ATTEMPT* to decode that prefix, and never will, as
it's not intended to.

Ethereal's PPP dissector was not written to dissect the raw byte stream
from a PPP serial connection.  It was written to dissect the packets
that an OS's packet capture mechanism would hand to an application
(tcpdump, Ethereal, whatever) using that mechanism.

Those packet capture mechanisms hand packets to applications *AFTER*
having divided the byte stream into frames *AND* removing escapes.  If
Ethereal handled escapes, it would rather badly mangle the results of
capturing data through those mechanisms.

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

Not true - people *do* look at it a fair bit.

It just shows how often people take raw byte streams and attempt to
stuff them into a libpcap-format capture for PPP.

The format that would mostly be appropriate would be
pppdump format, as that format has a raw byte stream and the code to
read it in Ethereal's Wiretap library frames the stream and undoes the
escaping.

However the PPP daemon used in some user-mode PPP implementations on
Linux and, I think, BSD doesn't always use HDLC-like framing, so pppdump
files are given a WTAP_ENCAP_ type that is dissected using the "maybe
this has HDLC-like framing, maybe it doesn't" dissector.

There are a couple of alternatives here.

You could add to that dissector an option to force interpretation as
PPP-in-HDLC-like-framing.

Or you could:

	add a new WTAP_ENCAP_ value for "always assume an HDLC-like
	encapsulation header";

	create a new capture file format, that mostly looks like pppdump
	format but has a "magic number" at the beginning to distinguish
	it from pppdump format (and from other formats);

	modify the pppdump-file reading code to check for that format
	and, if it detects that format, set the file encapsuation type
	to that WTAP_ENCAP_ value rather than WTAP_ENCAP_PPP_WITH_PHDR
	and set the file type for the new file type for that file;

	have a dissector that always assumes PPP in HDLC-like framing,
	and arrange that dissector be called for the new WTAP_ENCAP_
	type.

In either case, your program to read from the serial port should write
out the data in a pppdump-like format; in the second case, it'd write
out the magic number first.

I don't know whether pppdump format is well-documented anywhere; the
comments at the beginning of "wiretap/pppdump.c" describe it somewhat.

The file should start with a "Reset time" record, which is 0x07 followed
by, in big-endian format, a 4-byte UNIX-format time stamp value for the
time the program started recording data, i.e.  seconds since January 1,
1970, 00:00:00 GMT (GMT, *not* local time).

The record types are:

	"Time step (short)" - 0x06 followed by a 1-byte value giving the
	number of 1/10ths of seconds since the previous time indication
	was written to the file.

	"Time step (long)" - 0x05 followed by, in big-endian format, a
	4-byte number of 1/10ths of seconds since the previous time
	indication was written to the file.

	"Received data" - 0x02, followed by, in big-endian format, a
	2-byte byte count, followed by that number of raw bytes from the
	serial port, going in one direction.

	"Sent data" - 0x01, followed by, in big-endian format, a
	2-byte byte count, followed by that number of raw bytes from the
	serial port, going in the opposite direction from "Received data".

Of the two alternatives:

	the first one is a bit less work for the programmer (you only
	add a Boolean preference setting to the PPP dissector and make
	"dissect_ppp_hdlc()" check the Boolean variable for that setting
	and, if it's true, skip the checks for Cisco HDLC  and
	compressed format and alway dissect the first two octets as
	address and control octets), but a bit more work for the user
	(you have to get to the PPP preferences with the
	"Edit->Preferences" dialog box, change that setting - along with
	the FCS setting, which you'd change to "16-bit FCS" - and save
	the settings, which means that Ethereal will then interpret many
	PPP captures as PPP in HDLC-like framing even if the frame
	doesn't begin with 0xff 0x03, and will continue to do so until
	the setting is changed again);

	the second one is a bit more work for the programmer (you have
	to add a new capture file type), but a bit less work for the
	user (it'll automatically dissect the packets correctly in files
	in that format).