[bugzilla-daemon@xxxxxxxxxxxxx]

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.