| Bug ID |
12018
|
| Summary |
netlink not decoded unless data link type set to netlink
|
| Product |
Wireshark
|
| Version |
Git
|
| Hardware |
x86
|
| OS |
All
|
| Status |
CONFIRMED
|
| Severity |
Minor
|
| Priority |
Low
|
| Component |
Dissection engine (libwireshark)
|
| Assignee |
[email protected]
|
| Reporter |
[email protected]
|
Created attachment 14248 [details]
Netlink captured on linux with rtmon module
Build Information:
Version 2.1.0 (v2.1.0rc0-1527-g3b2e7b6 from master)
Copyright 1998-2016 Gerald Combs <[email protected]> and contributors.
License GPLv2+: GNU GPL version 2 or later
<http://www.gnu.org/licenses/old-licenses/gpl-2.0.html>
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Compiled (64-bit) with Qt 5.4.2, with libpcap, with POSIX capabilities (Linux),
with libnl 3, with libz 1.2.8, with GLib 2.46.1, with SMI 0.4.8, with c-ares
1.10.0, with Lua 5.2, with GnuTLS 3.3.15, with Gcrypt 1.6.3, with MIT Kerberos,
with GeoIP, without QtMultimedia, without AirPcap.
Running on Linux 4.2.0-23-generic, with locale C, with libpcap version 1.7.4,
with libz 1.2.8, with GnuTLS 3.3.15, with Gcrypt 1.6.3.
Intel(R) Core(TM) i5-3210M CPU @ 2.50GHz (with SSE4.2)
Built using gcc 5.2.1 20151010.
--
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 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
? Why is there a need for netlink data type ?
I changed the netlink data type from netlink to linux sll:
$ editcap netlink_generated_from_rtmon.pcap -T linux-sll
netlink_changed_dlt.pcap
Resulting pcap available here:
https://transfer.sh/hQPnR/netlink-changed-dlt.pcap
Now if I open this very pcap, even though sll.hatype value didn't change, it
does not recognize the inner packet as a netlink one.
You are receiving this mail because:
- You are watching all bug changes.