Re: DOCSIS

[Martin Dubuc <martind1111 () gmail com>]

On Tue, Aug 24, 2010 at 3:06 PM, Guy Harris <guy () alum mit edu> wrote:

> On Aug 24, 2010, at 11:26 AM, Martin Dubuc wrote:
>
> > I am trying to decode the packet output from a Cisco CMTS with Wireshark,
> but I haven't succeeded doing so up to now. The packet output was the result
> of capturing packets out of the analyzer port after configuring the CMTS
> using the cable monitor and intercept commands (my assumption is that the
> packet output is in a DOCSIS 1.0 format). I have read in one of the
> Wireshark documentation page that there is a DOCSIS decode option in the
> Edit/Preferences... dialog under the Frame protocol, but this does not match
> my packet output. When I enable this option, WIreshark interprets the first
> 6 bytes of each frames as DOCSIS header, then the rest as ethernet frames.
> > The packet output that I get from my Cisco CMTS is formatted as follows:
> >
> > 14-byte Ethernet header
> > 20-byte IP header
> > 8-byte UDP header
> > 14-byte Ethernet header
> > 20-byte IP header
> > ...
> >
> > I believe that the first 42 bytes is what the Cisco CMTS prepends to the
> actual user traffic. I would like Wireshark to strip these 42 bytes on the
> display so that I can zoom in on the actual user traffic.
> > First of all, I would like to know if this format is actually DOCSIS or
> not.
>
> If that's truly what the packet looks like - i.e., the first 14 bytes look
> like a 6-byte Ethernet destination address followed by a 6-byte Ethernet
> source address followed by 2 bytes of 0x0800, and the next 20 bytes look
> like an IP header, starting with 0x45 (IPv4, 20 bytes), etc., then that is
> *NOT* DOCSIS.  It's some form of tunneling of Ethernet over some UDP
> protocol.
I do nort quite understand why we are not geting DOCSIS out, but you are
right, it looks like what we are getting is some form of tunneling of
Ethernet over some UDP protocol.


> > I would then like to know how I can tell the system to ignore the 42
> bytes when displaying the packets.
>
> Try running the editcap command on the capture file:
>
>        editcap -T ether {capture file} ethernet-capture.pcap
>
> and try reading ethernet-capture.pcap; it should show you the first 14-byte
> Ethernet header, followed by the 20-byte IP header, followed by the 8-byte
> UDP header, and, if the protocol used for encapsulation is supported by
> Wireshark, it should show you the second Ethernet header and IP header.

I have tried to run editcap, but the output file is identical to the input
file. I believe the data link type in the original capture file is Ethernet.
So, running editpcap is probably not useful.

I want to tell Wireshark to ignore the first 42 bytes when displaying the
packet decode. At present, Wireshark shows the first Ethernet header, the
first IP header and the first UDP header, but then it displays the rest of
the packet as a big blob of data. It is not smart enough to figure out that
what's inside the data field is in fact an Ethernet header, an IP header and
whatever else.

Is it possible to tell Wireshark to ignore the first 42 bytes and then
decode what follows as Ethernet and IP header or is it possible to tell
Wireshark that what follows the first Ethernet/IP/UDP is Ethernet/IP and
whatever is valid in that context?

___________________________________________________________________________
> Sent via:    Wireshark-users mailing list <wireshark-users () wireshark org>
> Archives:    http://www.wireshark.org/lists/wireshark-users
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
>             mailto:wireshark-users-request () wireshark org
> ?subject=unsubscribe
___________________________________________________________________________
Sent via:    Wireshark-users mailing list <wireshark-users () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
             mailto:wireshark-users-request () wireshark org?subject=unsubscribe