[Guy Harris <gharris@xxxxxxxxx>]

On Sun, Sep 15, 2002 at 02:12:26PM -0400, Stephen Oberholtzer wrote:
> These devices do, at certain times, use hybrid protocol mixing PPP with
> Ethernet framing;

I.e., Ethernet-like frames are sent over a serial connection, intermixed
with PPP frames?

Or are those frames sent over different devices?

> thus, it would be extremely
> useful to store both PPP and Ethernet frames in a single capture file.

If the frames are sent over different devices, it might be useful to
store them both in a single capture file, but you could probably live
without it.

Even if they're both sent over the serial line, you might be able to
split them out into separate capture files.

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

Presumably by "capture protocol" you mean "capture file format".

You'd need one that not only supports a per-packet link-layer type but
to which you can *add* a new per-packet link-layer type, for "PPP that
never elides the address and control field".

There is a format that lets you mix PPP and Ethernet frames; it's the
text file format produced by the "snoop" command in Toshiba TR-600 and
TR-650 ISDN routers, at least according to the comment in
"wiretap/toshiba.c".  However, the only way to add support for your new
link-layer type would be if only certain characters were used in the
first character of the channel field in that output, in which case you
could use an unused character value.  I don't know if that's the case,
though.

Furthermore, its time stamp mechanism only supports a time within a day,
not a date.

> If so, what is it?  If not, I need some assistance modifying Ethereal
> to support it

If not, you'd need to first *invent* an "it" to support, and then add to
Ethereal code to read it.  Given that, you might want to just give up
and store the PPP and Ethernet frames in separate capture files.

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

You'd:

	add a new WTAP_ENCAP_ value to "wiretap/wtap.h", with a value
	equal to the current value of WTAP_NUM_ENCAP_TYPES in that file;

	increase the value of WTAP_NUM_ENCAP_TYPES by 1;

	add to the end of the "encap_table[]" array in "wiretap/wtap.c"
	an entry giving a long (descriptive) name and a short (easy to
	type on a command line - no spaces, no capital letters, etc.)
	name for the new encapsulation type, with the usual comment
	before it giving the WTAP_ENCAP_ value name.

> 3. I need some assistance modifying the existing PPP decoder to support
> these new PPP options.

	make a copy of "dissect_ppp_hdlc()" in "packet-ppp.c", give it
	a new name and an extra "gboolean force" argument, and modify it
	so that:

		it doesn't check the first byte for CHDLC_ADDR_UNICAST
		or CHDLC_ADDR_MULTICAST (i.e., skip the stuff that
		checks for those values and calls "call_dissector()"
		with "chdlc_handle");

		it does

			if (force || byte0 == 0xff)

		instead of

			if (byte0 == 0xff)

		in various places;

	replace all the code in "dissect_ppp_hdlc()" with a call to your
	new routine, passing a value of FALSE for the "force" argument;

	add a new routine that's just like "dissect_ppp_hdlc()" except
	it calls your new routine with a value of TRUE for the "force"
	argument;

	in "proto_reg_handoff_ppp()", add a new "dissector_handle_t"
	variable, assign to it the result of a call to
	"create_dissector_handle()" with your new dissector routine and
	"proto_ppp", and then call "dissector_add()" with arguments of
	"wtap_encap", your new WTAP_ENCAP_ value, and the new
	"dissector_handle_t" variable.

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

It'd be best to do what's described above.  To what "new options" are
you referring?

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

See the README.developer and README.tvbuff files in the "doc" directory
of the Ethereal source; if you'll be making the dissector a plugin
dissector rather than one compiled into Ethereal, see also
README.tvbuff.

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

See the "packet-*.c" files in the top-level Ethereal source directory
and in the various "plugins/*" directories for examples.  I'd pick a
dissector for a protocol that runs atop TCP; if it's a text-based
protocol like FTP, HTTP, SMTP, etc. pick one of those dissectors, and
if it's a binary protocol pick a dissector for another binary protocol.