Netlink

(4 intermediate revisions by the same user not shown)

Line 1:

Netlink sockets (PF_NETLINK) are a mechanism within Linux to retrieve and manage various aspects of the networking stacks -- they are a Linux-specific extension to the Berkeley Sockets model, and should not be used in portable programs. The information available via netlink sockets was previously available to userspace, if at all, via a collection of <tt>ioctl(2)</tt>s and a grabbag of <tt>get*(2)</tt> custom-purpose system calls; the majority of these are obsoleted by netlink sockets, but still implemented for backwards compatability. [http://www.faqs.org/rfcs/rfc3549.html RFC 3549] provides a snapshot current as of kernel 2.4.6; the netlink socket interface, however, is prone to change. That doesn't affect RFC 3549 as much as one might think, as it really has nothing to do with the netlink programming model; I suspect it to be a joke Andi Kleen perpetrated knowing that W. Richard Stevens wasn't around to call him out on it anymore.

~~The~~ <tt>~~netlink(3)~~</tt> ~~man page includes the following text:~~

==IFA_ADDRESS v IFA_LOCAL==

<~~pre~~>~~NOTES~~

When browsing the <tt>IFA_*</tt> attributes of an rtnetlink <tt>ADDR</tt> message, do not naively think that <tt>IFA_ADDRESS</tt> is the local address. The local address is <tt>IFA_LOCAL</tt>. On a broadcast device, this will be the same as <tt>IFA_ADDRESS</tt>, but on a point-to-point link, <tt>IFA_ADDRESS</tt> is the <i>remote</i> side of the link!

It is ~~often better to use netlink via libnetlink than via~~ the ~~low-level~~

~~kernel interface~~.</~~pre~~>~~It has been~~ this ~~author's experience that this is untrue;~~ the ~~cold hard reality is that just about anything involving netlink sockets is bound~~ to ~~be unpleasant~~, ~~usually in~~ the ~~extreme, and libnetlink won't improve things in the slightest. [[libdank]] has grown a capable netlink module over~~ the ~~years, and I would advise its use.~~

==Netlink Families==

As in the third argument to <tt>socket(2)</tt>; the full and current list of families can be had at your local <tt>netlink(7)</tt> man page. Here's the important ones:

* <tt>NETLINK_ROUTE</tt> — pretty much everything corresponding to <tt>ip(8)</tt>, also known as <tt>iproute</tt>, including:

* <tt>NETLINK_ROUTE</tt> — pretty much everything corresponding to <tt>ip(8)</tt>, also known as <tt>[[iproute]]</tt>, including:

** <tt>RTM_NEWLINK, RTM_DELLINK, RTM_GETLINK</tt> — device tables (ifinfomsg and rtattr structs) (see <tt>netdevice(7)</tt>)

** <tt>RTM_NEWADDR, RTM_DELADDR, RTM_GETADDR</tt> — address tables (ifaddrmsg and rtattr structs)

Line 15:

Line 13:

** <tt>RTM_NEWRULE, RTM_DELRULE, RTM_GETRULE</tt> — rule tables for advanced routing (rtmsg structs)

** See <tt>rtnetlink(7)</tt> for more info

* <tt>NETLINK_SOCK_DIAG</tt> — socket ~~monitoring~~, as used by <tt>ss(8)</tt>

* <tt>NETLINK_SOCK_DIAG</tt> — socket snapshots, as used by <tt>ss(8)</tt>

** Aliased as <tt>NETLINK_INET_DIAG</tt>

** ~~<tt>ss~~(8)~~</tt> as of at least 2019 seems~~ to ~~actually be using <tt>NETLINK_NFLOG</tt>~~

** This can only generate snapshots (it was originally added to assist checkpointing). It cannot be subscribed to for streaming events.

* <tt>NETLINK_NFLOG</tt> — [[iptables]] replacement for <tt>NETLINK_QUEUE</tt> since 2.6.14

** Userspace provided by <tt>libnetfilter</tt>

** <tt>ss(8)</tt> uses this when invoked with <tt>-E</tt> to print events continuously

* <tt>NETLINK_QUEUE</tt> — '''obsolete''' [[iptables]] packet interface for userspace

** Used the <tt>ip_queue</tt> kernel module and the QUEUE target

** Userspace was provided the [https://en.wikipedia.org/wiki/Libipq libipq] wrapper library.

==Extended error handling==

Using the confusingly named <tt>NETLINK_EXT_ACK</tt> <tt>SOCK_RAW</tt>-level socket option, the <tt>nlmsgerr</tt> structs accompanying <tt>NLMSG_ERROR</tt> messages will be followed by a set of TLVs from <tt>enum nlmsgerr_attrs</tt>, assuming the backend family supports this functionality.

==Netlink Stupidity==

Netlink: Difference between revisions

Dank (talk | contribs)

@@ Line 1: / Line 1: @@
 Netlink sockets (PF_NETLINK) are a mechanism within Linux to retrieve and manage various aspects of the networking stacks -- they are a Linux-specific extension to the Berkeley Sockets model, and should not be used in portable programs. The information available via netlink sockets was previously available to userspace, if at all, via a collection of <tt>ioctl(2)</tt>s and a grabbag of <tt>get*(2)</tt> custom-purpose system calls; the majority of these are obsoleted by netlink sockets, but still implemented for backwards compatability. [http://www.faqs.org/rfcs/rfc3549.html RFC 3549] provides a snapshot current as of kernel 2.4.6; the netlink socket interface, however, is prone to change. That doesn't affect RFC 3549 as much as one might think, as it really has nothing to do with the netlink programming model; I suspect it to be a joke Andi Kleen perpetrated knowing that W. Richard Stevens wasn't around to call him out on it anymore.
-The <tt>netlink(3)</tt> man page includes the following text:
+==IFA_ADDRESS v IFA_LOCAL==
-<pre>NOTES
+When browsing the <tt>IFA_*</tt> attributes of an rtnetlink <tt>ADDR</tt> message, do not naively think that <tt>IFA_ADDRESS</tt> is the local address. The local address is <tt>IFA_LOCAL</tt>. On a broadcast device, this will be the same as <tt>IFA_ADDRESS</tt>, but on a point-to-point link, <tt>IFA_ADDRESS</tt> is the <i>remote</i> side of the link!
-       It is often better to use netlink via libnetlink than via the low-level
-       kernel interface.</pre>It has been this author's experience that this is untrue; the cold hard reality is that just about anything involving netlink sockets is bound to be unpleasant, usually in the extreme, and libnetlink won't improve things in the slightest. [[libdank]] has grown a capable netlink module over the years, and I would advise its use.
 ==Netlink Families==
 As in the third argument to <tt>socket(2)</tt>; the full and current list of families can be had at your local <tt>netlink(7)</tt> man page. Here's the important ones:
-* <tt>NETLINK_ROUTE</tt> — pretty much everything corresponding to <tt>ip(8)</tt>, also known as <tt>iproute</tt>, including:
+* <tt>NETLINK_ROUTE</tt> — pretty much everything corresponding to <tt>ip(8)</tt>, also known as <tt>[[iproute]]</tt>, including:
 ** <tt>RTM_NEWLINK, RTM_DELLINK, RTM_GETLINK</tt> — device tables (ifinfomsg and rtattr structs) (see <tt>netdevice(7)</tt>)
 ** <tt>RTM_NEWADDR, RTM_DELADDR, RTM_GETADDR</tt> — address tables (ifaddrmsg and rtattr structs)
@@ Line 15: / Line 13: @@
 ** <tt>RTM_NEWRULE, RTM_DELRULE, RTM_GETRULE</tt> — rule tables for advanced routing (rtmsg structs)
 ** See <tt>rtnetlink(7)</tt> for more info
-* <tt>NETLINK_SOCK_DIAG</tt> — socket monitoring, as used by <tt>ss(8)</tt>
+* <tt>NETLINK_SOCK_DIAG</tt> — socket snapshots, as used by <tt>ss(8)</tt>
 ** Aliased as <tt>NETLINK_INET_DIAG</tt>
-** <tt>ss(8)</tt> as of at least 2019 seems to actually be using <tt>NETLINK_NFLOG</tt>
+** This can only generate snapshots (it was originally added to assist checkpointing). It cannot be subscribed to for streaming events.
 * <tt>NETLINK_NFLOG</tt> — [[iptables]] replacement for <tt>NETLINK_QUEUE</tt> since 2.6.14
 ** Userspace provided by <tt>libnetfilter</tt>
+** <tt>ss(8)</tt> uses this when invoked with <tt>-E</tt> to print events continuously
 * <tt>NETLINK_QUEUE</tt> — '''obsolete''' [[iptables]] packet interface for userspace
 ** Used the <tt>ip_queue</tt> kernel module and the QUEUE target
 ** Userspace was provided the [https://en.wikipedia.org/wiki/Libipq libipq] wrapper library.
+==Extended error handling==
+Using the confusingly named <tt>NETLINK_EXT_ACK</tt> <tt>SOCK_RAW</tt>-level socket option, the <tt>nlmsgerr</tt> structs accompanying <tt>NLMSG_ERROR</tt> messages will be followed by a set of TLVs from <tt>enum nlmsgerr_attrs</tt>, assuming the backend family supports this functionality.
 ==Netlink Stupidity==