Wireshark · Ethereal-dev: Re: [Ethereal-dev] Dissector for DOCSIS

["Anand V. Narwani" <anarwani@xxxxxxxxx>]

Hello Guy et al,
Thanks for the prompt response on this!  You are correct in inferring that 
the CMTS will forward frames directly from the RF interface to the Fast 
Ethernet interface in raw octet form.  To make matters more complicated, 
Cable Monitor allows you to forward Data Frames without the DOCSIS header, 
so you could conceivably get a capture with a mixture of frames with DOCSIS 
headers on them and valid 802.3 frames.
After thinking about it for a little bit, I decided to require that data 
frames be forwarded with the DOCSIS header, since this would provide more 
information and solve the issue of trying to trying to write some sort of 
Heuristic dissector.   I believe that a dissector of this type would be 
prone to errors.
You are also correct in assuming that I would want to capture with Ethereal 
or some such capture tool. Here's what I did to allow me to test my dissector:
1. I added a new encapsulation type to wtap.c:  WTAP_ENCAP_DOCSIS
2. I then added a global preference to the prefs_dlg.c to add a new page 
called DOCSIS Preferences.  This sets a global boolean.  The intent here is 
that if this preference is set, all frames will be treated as DOCSIS frames.
3. In packet-frame.c, I added a check for that boolean, that will set 
pinfo->fd->lnk_t = WTAP_ENCAP_DOCSIS
4. The DOCSIS dissector is registered using: dissector_add("wtap_encap", 
WTAP_ENCAP_DOCSIS, docsis_handle);

This allows me to capture with Ethereal, and save files in libpcap format, 
and open .enc files containing DOCSIS frames.  I have been able to capture 
with Tethereal, but it does not dissect the frames correctly.   I would 
guess that this is because I didn't set that preference on the command 
line. Does this seem to be a reasonable approach?  Can anyone think of a 
better way to do this?

Would it be possible to map the WTAP_ENCAP_DOCSIS to a standard Ethernet 
Encapsulation, so that I would not have to muck with the libpcap code?   I 
would prefer not to make a change to the underlying libpcap code, since 
only a small subset of people would actually use the DOCSIS dissector.

Thanks,
Anand


At 02:39 AM 6/23/2002 -0700, Guy Harris wrote:
> On Sun, Jun 23, 2002 at 05:10:13AM +0200, Joerg Mayer wrote:
> > On Sat, Jun 22, 2002 at 09:04:14PM -0400, Anand V. Narwani wrote:
> > > I am currently having trouble deciding how to decide a Frame is a DOCSIS
> > > frame or not.  Looking at the problem more closely, I cannot see a
> > > reasonable way of differentiating a DOCSIS frame from a normal Ethernet
> > > frame, since the packets a captured from an Fast Ethernet interface 
> off of
> > > the CMTS.  I've decided to add an Encapsulation type for DOCSIS and have
> > > this enabled by a global preference.  My question is this:  Does 
> anyone see
> > > any unintended consequences of this approach?  For example, would there
> > > need to be any special handling for saving captures to a non-ethereal 
> format?
> >
> > I think there are three way to solve this:
> > 1) create a new encapsulation type
> > 2) Add a flag to ethereal gui that tells it to dissect all ethernet frames
> >    as docsis frames.
> > 3) Make the docsis decoder a heuristic decoder at a very low level and
> >    check whether the packet can be dissected properly (this would be
> >    much more reliable if the traces actually contained the HCS, but it
> >    looks like the HCS is always 0).
> >
> > 3 is quite expensive in terms of CPU and maybe accuracy, 2 has problems 
> with
> > tethereal, 1 looks best to me, as the capturing entitiy really should 
> have the
> > necessary information and should pass that information to ethereal.
>
> If, as I'm beginning to infer is the case:
>
>         1) the Cisco box uses the Ethernet as a raw octet pipe and puts
>            raw DOCSIS MAC frames on the Ethernet (i.e., the stuff it
>            puts on the Ethernet does *NOT* conform to IEEE Std 802.3 or
>            the D/I/X Ethernet II spec)
>
> and
>
>         2) you'd be capturing that traffic with an ordinary Ethernet
>            packet analyzer - perhaps with Ethereal or Tethereal itself
>
> then the only way you'd get a new encapsulation type would be if some
> program you controlled were doing the capturing.
>
> If that program were Ethereal or Tethereal, the only way to get it to
> use that new encapsulation type as the link-layer type would be to
> specify a preference, so in order to do 1) with Ethereal or Tethereal
> you'd have to do something very similar to 2)!
>
> Fortunately, 2), if that flag is a standard protocol preference, *is*
> doable with Tethereal as well - *all* protocol preferences can be
> controlled from the Tethereal command line *and* the Ethereal command
> line with the "-o" option.  You'd just do something such as
>
>         tethereal -w docsis.pcap -o eth.treat_as_docsis:true
>
> Wiretap encapsulation types, however, don't exist by themselves in
> capture files; they're a layer removed from that - various encapsulation
> type values in capture files get mapped to Wiretap encapsulation types
> based on the type of capture file.
>
> Ethereal's native capture file format being libpcap format, this would
> require that a new DLT_DOCSIS DLT_ type be added to libpcap.  That would
> mean that you'd have to specify a command-line or configuration option
> when *capturing* the non-Ethernet DOCSIS MAC traffic from an Ethernet,
> but you wouldn't have to specify that option when reading a saved
> capture file.
>
> If you didn't support using Ethereal or Tethereal as the capture
> program, you could avoid getting a new DLT_DOCSIS type - but you'd have
> to invent a new capture file format for that program, and add support to
> Wiretap to read that capture file format.
>
> As for Anand's question about saving captures to a non-Ethereal format
> (i.e., not libpcap format), the answer is "you wouldn't be able to do
> that unless the capture file format supports DOCSIS as a link-layer
> type" - and if you didn't add a new DLT_DOCSIS type, you wouldn't even
> be able to save captures in *Ethereal* format, as that's just libpcap
> format.
>
>
> _______________________________________________
> 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"