Wireshark-users: Re: [Wireshark-users] Displaying Cisco Cable Monitor and Intercept Traffic
Yes. That does the trick. Would it make sense to make this modification in the svn tree? This way, we could support Cisco Cable Monitor and Intercept "off-the-shelf".
Should I submit such patch?
Martin
On Wed, Aug 25, 2010 at 2:04 PM, Christopher Maynard
<Chris.Maynard@xxxxxxxxx> wrote:
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
___________________________________________________________________________
Sent via: Wireshark-users mailing list <wireshark-users@xxxxxxxxxxxxx>
Archives: http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
mailto:wireshark-users-request@xxxxxxxxxxxxx?subject=unsubscribe
