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