http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=2056
guy@xxxxxxxxxxxx changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |INVALID
------- Comment #1 from guy@xxxxxxxxxxxx 2007-12-02 22:04 GMT -------
If the Ethernet on which you're capturing traffic has any devices on it other
than the CMTS and a *completely passive* sniffer (i.e., a sniffer that's not
transmitting packets), you run the risk of having not only DOCSIS traffic on
the Ethernet but also regular Ethernet traffic.
Wireshark cannot distinguish between those packets, so if the capture has a
link-layer type of DOCSIS or you have enabled the "Treat all frames as DOCSIS
frames" preference, it will attempt to interpret the Ethernet frames as DOCSIS
frames, and will report them as malformed frames.
That's the type of capture you have; frame 10, for example, is a DHCP Discover
packet over Ethernet, sent by the host with the Ethernet address
00:08:0e:1e:e2:dc. If interpreted as a DOCSIS packet, it looks like a
malformed packet.
Frames 2, 3, 7, 8, and 9, however, are DOCSIS MAC frames, and display as such
when interpreted as DOCSIS packets.
Frame 11 appears to be the same packet as frame 10, except with a DOCSIS
header; perhaps some machine on the Ethernet sent that frame to the CMTS, and
it sent the packet out on the cable, with a copy being sent out on the Ethernet
for sniffing. (It's a little odd, as the checksum on the Ethernet version of
the packet is wrong, and it has no UDP checksum; the DOCSIS version reports the
Ethernet checksum as a trailer (that's probably a bug, as a DOCSIS packet
containing an Ethernet packet can probably be guaranteed to contain an Ethernet
checksum in the Ethernet packet) and has a UDP checksum (probably because the
CMTS added a checksum).
--
Configure bugmail: http://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
