https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=12018
--- Comment #7 from Guy Harris <ghar...@sonic.net> ---
(In reply to Matthieu Coudron from comment #0)
Please find enclosed a netlink packet capture made on linux thanks to the
> rtmon module.
> Its data link type is set to Netlink. There are cooked headers
No, there are headers that vaguely have the *form* of LINKTYPE_LINUX_SLL cooked
headers, but that are different from the original design and intent of
LINKTYPE_LINUX_SLL cooked headers:
* they don't use the "Packet type" field, even to indicate direction;
* they don't use the "ARPHRD_ type" field to indicate the type of the address
in the "Link-layer address" field;
* they don't use the "Link-layer address type" or "Link-layer address" fields;
* they don't use the "Protocol type" field to hold a standard Linux skbuff
protocol field value, they use it to hold a Netlink protocol value.
> and packets are properly decoded as netlink.
> My question is:
> shouldn't the data link type be set to linux cook headers (SLL) instead of
> netlink (netlink can be deduced from sll.hatype) since outer headers are
> cooked ?
No, the question should be "*Should* the data link type be set to Linux cooked
headers (SLL) instead of netlink?", and the answer is "no, because that
requires the dissector for Linux cooked headers to do extra weird stuff to
dissect packets".
I'm going to try to make it slightly less weird, but it's still annoying. What
would have been *best* would have been if LINKTYPE_NETLINK had, for example, a
4-byte header, containing a Netlink protocol type in network byte order (or
little-endian, whichever is more convenient - but not host byte order, please,
that requires special hackery in code to read pcap and pcapng files), followed
by a sequence of RFC 3549 Netlink messages.
Unfortunately, the damage has been done, and we would still need to support
dissecting the existing LINKTYPE_NETLINK messages, even if we were to add a
LINKTYPE_NETLINK_DONE_RIGHT link-layer type.
> Why is there a need for netlink data type ?
Because if you *don't* have a Netlink data type, and instead abuse
LINKTYPE_LINUX_SLL, it requires special handling in the dissector for
LINKTYPE_LINUX_SLL.
(It's bad enough that it requires special handling for GRE, which also abuses
the LINKTYPE_LINUX_SLL header, but that abuse, and the special handling it
requires, isn't *quite* as ugly. I'm going to try to do the special handling
in a slightly less ugly fashion, not involving "OK, I'm going to skip all the
header processing and jump directly to the LINKTYPE_NETLINK dissector".)
--
You are receiving this mail because:
You are watching all bug changes.
___________________________________________________________________________
Sent via: Wireshark-bugs mailing list <wireshark-bugs@wireshark.org>
Archives: https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe
