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.
