Hi Guy,
Here's another alternative. I can add a preference to the Frame Protocol,
that achieves the same thing. This is *alot* cleaner programatically, as
the only file I mess with is packet-frame.c and the changes are
minimal. The downside is that it's not very intuitive to the user that
they need to look under frame preferences to enable the DOCSIS
preference. Any thoughts on which is better?
The discussion about code bloat for features that weren't used very often
on the ethereal-dev alias also peaked my interest. The way I see it, the
DOCSIS dissector is useful, but only to a small number of people. It is
for this reason that I would really like to make this a module. With this
in mind, I was wondering if it was possible to test for the presence of a
module. If so, I could add a check in dissect_frame() that checks for the
presence of the DOCSIS module and the preference setting before setting the
encapsulation type.
Thanks in Advance,
Anand
At 09:18 PM 6/25/2002 -0700, Guy Harris wrote:
On Mon, Jun 24, 2002 at 10:22:00AM -0400, Anand V. Narwani wrote:
> So this is starting to make a little more sense. I have one more
question
> though: If I add a DLT_DOCSIS encapsulation type to libpcap, would I
lose
> the ability to "Save as..." other file types (Sniffer for example)?
If the file type has support for DOCSIS as a link-layer type, no, you
wouldn't lose it, as long as you added the right mapping from
WTAP_ENCAP_DOCSIS to the appropriate link-layer type.
If the file type *doesn't* have support for DOCSIS as a link-layer type,
you would have to map WTAP_ENCAP_DOCSIS to "Ethernet". (It's not as if
the other network analyzer whose file format you were writing could
dissect the traffic as DOCSIS traffic if it doesn't support DOCSIS as a
link-layer type, unless it has its own "pretend that Ethernet is DOCSIS"
option.)
However, if you added DLT_DOCSIS, you'd also need to add some mechanism
to libpcap by which you could override the OS's idea of what the
link-layer type of the capture device should be.
_______________________________________________
Ethereal-dev mailing list
Ethereal-dev@xxxxxxxxxxxx
http://www.ethereal.com/mailman/listinfo/ethereal-dev
--
Anand V. Narwani, CCIE 3892
Advanced Engineering Services
Cisco Systems, Inc.
Direct/Fax: 919.392.3404
Email: anarwani@xxxxxxxxx
"Meddle not in the affairs of dragons, for you are crunchy and taste good
with ketchup"Attachment:
prefs2.jpg
Description: JPEG image
