Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-users: Re: [Wireshark-users] Displaying Cisco Cable Monitor and Intercept Traffic

From: Christopher Maynard <Chris.Maynard@xxxxxxxxx>
Date: Wed, 25 Aug 2010 18:04:09 +0000 (UTC)
Martin Dubuc <martind1111@...> writes:
> 
> The traffic coming out of the CMTS LAN analyzer port looks like this:
> |  14-byte Ethernet header
> |  20-byte IP header
> |  8-byte UDP header
> v
> ^
> | 14-byte Ethernet header
> | 20-byte IP header
> | ...
> The first part (Ethernet/IP/UDP header) is fabricated by the CMTS. The second
part (Ethernet/IP/...) is the end-user traffic.If I load a PCAP file with this
type of traffic in Wireshark, Wireshark displays the Ethernet/IP/UDP header as
one would expect, but it does not decode the second part, the end-user traffic.
It displays the end-user traffic as one big data blob.I am surprised that
Wireshark is not able to decode the second part, the end-user traffic. I am not
sure if we need to do some sort of configuration, or if we should write a
special dissector that can handle this type of encapsulation.Martin

Maybe UDP port X -> Ethernet "Decode As" capability would work for you?  That
would require a patch to the Ethernet dissector, something like:

Index: packet-eth.c
===================================================================
--- packet-eth.c        (revision 33919)
+++ packet-eth.c        (working copy)
@@ -658,4 +658,5 @@
        dissector_add("ethertype", ETHERTYPE_ETHBRIDGE, eth_withoutfcs_handle);
        dissector_add("chdlctype", ETHERTYPE_ETHBRIDGE, eth_withoutfcs_handle);
        dissector_add("gre.proto", ETHERTYPE_ETHBRIDGE, eth_withoutfcs_handle);
+       dissector_add("udp.port", 0, eth_maybefcs_handle);
 }

That should allow Ethernet to show up as Transport level "Decode As" target, so
you should then be able to right-click on a packet, choose "Decode As", then
assign UDP port X to be decoded as Ethernet.  I'm not sure if
eth_maybefcs_handle is the right one to use though; maybe eth_withoutfcs_handle
would be better?  There might be another, better alternative, but this is just
one idea that looks like it would work for you.

- Chris