On Sep 17, 2008, at 12:09 PM, Wes wrote:
I noticed a difference between the way Wireshark decodes the
attached trace. Note: This is a Docsis trace so you will need to go
into Preferences/Protocols/Frames and enable Docsis
...only if the capture was done by an application that couldn't be
told to mark it as a DOCSIS trace even though it's capturing on
Ethernet; if you have a sufficiently recent version of libpcap,
Wireshark is not such an application (when capturing on an "Ethernet"
that's being fed by one of those Cisco boxes using the Ethernet as a
low-level tap for DOCSIS, select the "Link-layer header type" value of
"Data Over Cable Service Interface Specification" rather than the
default "Ethernet"), TShark is not such an application (capture with "-
y DOCSIS"), dumpcap is not such an application (capture with "-y
DOCSIS"), and tcpdump is not such an application (capture with "-y
DOCSIS").
That will give you a pcap file with a link-layer type of DOCSIS, which
Wireshark will automatically treat as DOCSIS regardless of how the
preference in question is set.
In Wireshark 0.99.5, these frames show a Ethernet destination of
"IPv6-Neighbor-Discovery_XX:XX:XX:XX". With Wireshark 1.0.2, the
Ethernet destination shows as "IPv6mcast_XX:XX:XX:XX". Can anyone
tell me which one is correct?
Wireshark 1.0.2 is correct; see bug 2456:
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=2456
RFC 2464 says that
An IPv6 packet with a multicast destination address DST, consisting
of the sixteen octets DST[1] through DST[16], is transmitted to the
Ethernet multicast address whose first two octets are the value 3333
hexadecimal and whose last four octets are the last four octets of DST.
So a MAC address of 33:33:XX:XX:XX:XX corresponds to an IPv6 multicast
address whose last four octets are XX:XX:XX:XX; those are not used
solely for neighbor discovery.
