| Linux kernel | |
| Netlink | |
| Operating System: | Linux |
| Platform: | Linux kernel |
| Genre: | Application programming interface |
| License: | GNU General Public License |
Netlink is a socket family used for inter-process communication (IPC) between both the kernel and userspace processes, and between different userspace processes, in a way similar to the Unix domain sockets available on certain Unix-like operating systems, including its original incarnation as a Linux kernel interface, as well as in the form of a later implementation on FreeBSD.[1] Similarly to the Unix domain sockets, and unlike INET sockets, Netlink communication cannot traverse host boundaries. However, while the Unix domain sockets use the file system namespace, Netlink sockets are usually addressed by process identifiers (PIDs).[2]
Netlink is designed and used for transferring miscellaneous networking information between the kernel space and userspace processes. Networking utilities, such as the iproute2 family and the utilities used for configuring mac80211-based wireless drivers, use Netlink to communicate with the Linux kernel from userspace. Netlink provides a standard socket-based interface for userspace processes, and a kernel-side API for internal use by kernel modules. Originally, Netlink used the socket family.
Netlink is designed to be a more flexible successor to ioctl; RFC 3549 describes the protocol in detail.
Netlink was created by Alexey Kuznetsov[3] as a more flexible alternative to the sophisticated but awkward communication method used for setting and getting external socket options. The Linux kernel continues to support for backward compatibility.
Netlink was first provided in the 2.0 series of the Linux kernel, implemented as a character device. By 2013, this interface is obsolete, but still forms an ioctl communication method; compare the use of .[4] The Netlink socket interface appeared in 2.2 series of the Linux kernel.
In 2022, experimental support for the Netlink protocol was added to FreeBSD. Initially, only a subset of the NETLINK_ROUTE family and NETLINK_GENERIC is supported.
| Bit offset | 0–15 | 16–31 | |||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 0 | Message length | ||||||||||||||||||||||||||||||||
| 32 | Type | Flags | |||||||||||||||||||||||||||||||
| 64 | Sequence number | ||||||||||||||||||||||||||||||||
| 96 | PID | ||||||||||||||||||||||||||||||||
| 128+ | Data | ||||||||||||||||||||||||||||||||
Unlike BSD sockets using Internet protocols such as TCP, where the message headers are autogenerated, the Netlink message header (available as) must be prepared by the caller. The Netlink socket generally works in a -like mode, even if was used to create it.
The data portion then contains a subsystem-specific message that may be further nested.
The family offers multiple protocol subsets. Each interfaces to a different kernel component and has a different messaging subset. The subset is referenced by the protocol field in the socket call:
int socket(AF_NETLINK, SOCK_DGRAM or SOCK_RAW, protocol)
Lacking a standard, and are not guaranteed to be implemented in a given Linux (or other OS) release. Some sources state that both options are legitimate, and the reference below from Red Hat states that is always the parameter. However, iproute2 uses both interchangeably.
A non-exhaustive list of the supported protocol entries follows:
Users can add a Netlink handler in their own kernel routines. This allows the development of additional Netlink protocols to address new kernel modules.[5]