Age | Commit message (Collapse) | Author | Files | Lines |
|
Dump RTnetlink interface related info with attributes.
Signed-off-by: Vadim Kochan <vadim4j@gmail.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
|
|
Pull & print more netlink messages from one packet which can be sent
with MULTI flag.
Signed-off-by: Vadim Kochan <vadim4j@gmail.com>
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
|
|
Print 'Family' and 'Type' (considering family) fields in less mode.
Signed-off-by: Vadim Kochan <vadim4j@gmail.com>
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
|
|
Print nlmsg type name for rtnetlink messages.
Signed-off-by: Vadim Kochan <vadim4j@gmail.com>
[tk: ifdef guards for RTM_NEWNETCONF and RTMNEWMDB, other minor fixes]
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
|
|
Instead of just reproducing the macro name, provide a little more
information (as given in the comments next to the definitions in
linux/netlink.h)
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
|
|
Netlink messages don't use the term `family' instead of `protocol', so
stick to it when printing dissected information.
Also, functions with the `nl_' prefix are used by libnl, so in order to
not confuse it with libnl functions, rename nl_proto2str() to
nlmsg_family2str()
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
|
|
nlmsg proto handler can't identify Netlink protocol from nlmsghdr, so
sockaddr_ll can be used to get it.
Also renamed [proto -> handler] member in pkt_buff struct, which is more
understandable.
Example:
>U nlmon0 4756 1429891435s.14505747ns
[ NLMSG Proto 0 (RTNETLINK), Len 1160, Type 0x0010 (0x10), Flags 0x0002 (MULTI), Seq-Nr 1429891436, PID 31613 ]
Signed-off-by: Vadim Kochan <vadim4j@gmail.com>
[tklauser: Handle usage of NETLINK_SOCK_DIAG with pre 3.10 kernel
headers, fix nl_proto2str() return value, formatting changes]
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
|
|
The libnl3 examples [1] use <netlink/netlink.h> etc. and since
pkg-config returns the paths including the libnl3 path component, we
should specify our include paths relative to these ones, not
/usr/include.
[1] http://www.infradead.org/~tgr/libnl/doc/core.html#_linking_to_this_library
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
|
|
Commit 6c5d0caf3b7c ("netsniff-ng: Fix process name when sniffing nlmon
device") fixed the problem of not NULL-terminating the readlink() result
buffer by initializing the entire buffer with '\0'.
Switch to the more common and better readable idiom of explicitely
writing a NULL byte after the readlink result string to make this more
obvious. Also change the buffer size to PATH_MAX.
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
|
|
While sniffing nlmon device the process name can be
printed with non-letter characters because readlink does not
put line ending '\0'
Signed-off-by: Vadim Kochan <vadim4j@gmail.com>
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
|
|
Fixes sparse warnings like the following in some dissectors:
proto_arp.c:158:17: warning: symbol 'arp_ops' was not declared. Should it be static?
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
|
|
The port id field of the netlink message header does not necessarily
indicate the PID of the receiving process [1] (e.g. in case of
multithreaded applications or using multiple sockets). Mention this in
a comment.
[1] http://www.carisma.slowglass.com/~tgr/libnl/doc/core.html#core_netlink_fundamentals
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
|
|
In the netlink message dissector, use the PID from the header to look up
the process name of the sending process.
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
|
|
Add an initial implementation of a dissector to work on netlink messages
as received from an nlmon device.
Use can use it as follows to monitor netlink traffic to/from the kernel:
modprobe nlmon
ip link add type nlmon
ip link set nlmon0 up
netsniff-ng -i nlmon0
ip link set nlmon 0 down
ip link del dev nlmon0
rmmod nlmon
Fixes: #89
Suggested-by: Daniel Borkmann <dborkman@redhat.com>
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
|