[Stephen Oberholtzer <soberholtzer@xxxxxxxxxxxxxx>]

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

<description of protocol snipped>

<reason why PPP doesn't decode the address/control bytes snipped>

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

Yes, a while after I sent this email that realization occurred to me, and I
modified my capture program to remove the
escaping from the packets.

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

<snip>

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

<description of pppdump format snipped>

> Of the two alternatives:
> 
<alternatives snipped>

As I am both the user and the programmer, I prefer to make the detection
more automatic.

These devices do, at certain times, use hybrid protocol mixing PPP with
Ethernet framing; thus, it would be extremely
useful to store both PPP and Ethernet frames in a single capture file.

These devices use some custom parameters added to the PPP packets, for the
negotiation of certain
parameters specific to our devices' operation; having Ethereal decode these
parameters would be very useful.

They also have an application-layer protocol that runs on
TCP-over-IP-over-PPP that I would also like Ethereal
to be able to decode.

So:

1. Is there a capture protocol that supports the 'struct timeval'
timestamping of libpcap format and a per-packet link layer type?  If so,
what is it?  If not, I need some assistance modifying Ethereal to support it
(or if a win32 dll can be created to do this, all the better).

2. I need some assistance creating a new link layer type that always has
PPP-in-HDLC-framing-with-16bit-checksums.

3. I need some assistance modifying the existing PPP decoder to support
these new PPP options.  Perhaps it would be
   best to clone the current PPP stuff, then modify it to (1) always use the
HDLC stuff, and (2) use the new options?

4. I need some assistance creating a whole new protocol decoder.


'I need some assistance' == 'I have no idea what I'm doing, so a specific
example would be incredibly useful'.