https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=2519
--- Comment #3 from Chris Maynard <christopher.maynard@xxxxxxxxx> 2010-09-29 08:15:01 PDT ---
(In reply to comment #2)
> Thanks for explanation, I changed the topic.
> OTOH I'm now wondering why the bytes from 0x06 to 0x0D aren't dissected.
I guess this explains it: http://www.tcpdump.org/pcap3_man.html
Of particular relevance under pcap_datalink()/DLT_LINUX_SLL:
[BEGIN COPY]
a 2-byte field, in network byte order, containing the length of the link layer
address of the sender of the packet (which could be 0);
an 8-byte field containing that number of bytes of the link layer header (if
there are more than 8 bytes, only the first 8 are present);
[END COPY]
So, the Linux cooked header is a fixed length and the 8 bytes from offset 0x06
to 0x0D are reserved for where the link layer address would be if the length of
the link layer address field was non-zero. In this case it's zero, so
Wireshark skips the dissection since the bytes are meaningless.
Of course looking at packet-sll.c, it seems to me that there is a bug there.
Skipping to the switch starting at line 191 (SVN34262), the default case is not
properly handled if halen > 8.
Instead of this:
if (tree) {
proto_tree_add_item(fh_tree, hf_sll_src_other, tvb,
6, halen, FALSE);
}
We should have something like this:
if (tree) {
proto_tree_add_item(fh_tree, hf_sll_src_other, tvb,
6, halen > 8 ? 8 : halen, FALSE);
}
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
