Wireshark

  • Riverbed Technology
  • WinPcap
the world's foremost network protocol analyzer
  • Wireshark
    • About
    • Download
    • Blog
  • Get Help
    • Ask a Question
    • FAQs
    • Documentation
    • Mailing Lists
    • Online Tools
    • Wiki
    • Bug Tracker
  • Develop
    • Get Involved
    • Developer's Guide
    • Browse the Code
    • Latest Builds

Wireshark-bugs: [Wireshark-bugs] [Bug 2056] Problems sniffing on DOCSIS packets

Date Index Thread Index Other Months All Mailing Lists
Date Prev Date Next Thread Prev Thread Next


From: bugzilla-daemon@xxxxxxxxxxxxx
Date: Sun, 2 Dec 2007 22:04:35 +0000 (GMT)

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.

  • References:
    • [Wireshark-bugs] [Bug 2056] New: Problems sniffing on DOCSIS packets
      • From: bugzilla-daemon
  • Prev by Date: [Wireshark-bugs] [Bug 2017] VoIP trace crashes Wireshark when specific RTP Player buttons are clicked
  • Next by Date: [Wireshark-bugs] [Bug 2067] mergecap fails when "time_t" is "int"
  • Previous by thread: [Wireshark-bugs] [Bug 2056] Problems sniffing on DOCSIS packets
  • Next by thread: [Wireshark-bugs] [Bug 2056] Problems sniffing on DOCSIS packets
  • Index(es):
    • Date
    • Thread

Wireshark and the "fin" logo are registered trademarks of the Wireshark Foundation