? Libnl is divided into several small libraries in design, and the application can choose the library to link when linking, without linking all the libraries to the application.
The main header file provided by libnl is
You can directly link the libnl library in gcc.
? Netlink protocol is a socket-based IPC mechanism, which can be used for communication between user-space processes and the kernel or between user-space processes. Netlink protocol is based on BSD socket and uses AF_NETLINK address cluster. Each Netlink protocol has its own protocol number (such as NETLINK_ROUTE, NETLINK_NETFILTER, etc.). ). Its addressing scheme is based on 32-bit port number (formerly known as PID), which is used to uniquely identify each peer-to-peer communication node.
? The network link address (port) consists of a 32-bit integer. Port zero is reserved for the kernel, which represents the socket of the kernel part in each Netlink protocol cluster, and other ports usually refer to the socket of user space.
? Note: At first, the process identifier (PID) was usually used as the local port number, but with the introduction of the threaded Netlink application, this method became ineffective because such a process required multiple sockets. In order to solve this conflict, libnl generates a unique port number based on the process identifier and an offset, which allows a process to use multiple sockets. For backward compatibility, the first socket still uses the process identifier as the port number.
? The most common application scenario of Netlink is that the user-space application sends a request to the kernel, such as setting/reading the IP address of the interface, and then accepts and processes the information returned by the kernel. The reply message is either an error message or a notification message of successful request.
? Netlink can also be directly used as an interprocess communication mechanism between user-space applications, but this method is not common and is usually replaced by unix domain sockets. This communication is not limited to two peer-to-peer communication nodes, and any node can communicate with other peer nodes. In addition, because Netlink supports multicast, a message can be received by multiple nodes at the same time.
? Note: In order to make sockets visible to both communication parties, these two sockets must be created under the same Netlink protocol group.
? This Netlink communication is a very common application mode, which allows daemons in user space that need to handle specific kernel events to listen to messages/events fed back by the kernel. These application processes usually subscribe to the multicast group used by the kernel, and the kernel uses it to inform the processes subscribing to the multicast group when certain events occur.
? Compared with direct addressing, multicast addressing is a better way because it has higher flexibility and can exchange information with user space application components at any time without informing the kernel.
? The Netlink protocol is usually based on messages, and messages usually consist of a Netlink message header (struct nlmsghdr) plus a payload. Although the payload can be composed of any data, its usual format is a fixed-size protocol-related header followed by a series of attributes.
? Netlink is different in handling requests, notifications and replies. The request message is provided with an NLM _ F _ request flag bit for requesting some responses from the receiver. In general, request messages are sent from user space to the kernel. Although this is not mandatory, the sequence number of each request message sent should be the last sequence number plus 1.
? Due to the nature of the request itself, the receiver may send another netlink message to respond to this request after receiving the request message. The sequence number of the reply message must be the same as the sequence number of the request message it responds to.
? The notification message is not so rigorous that no reply is needed, so the sequence number is usually set to 0.
The message type is mainly determined by the message type field of 16 in the message header. Netlink defines the following standard message types:
? Each netlink protocol can freely define its own message type. It should be noted that types smaller than NLMSG_MIN_TYPE(0x 10) are reserved, so they cannot be used. Usually we define our own message types to implement RPC mode. Suppose that the purpose of your netlink protocol is to allow you to configure some parts of a network device, so you want to provide read/write access to various configuration options. A typical "netlik solution" to accomplish this task is to define two message types, MSG_SETCFG and MSG_GETCFG:
? Sending a MSG_GETCFG request message usually receives a reply message of type MSG_SETCFG containing the current configuration information. In object-oriented terms, this is called "the kernel sets a local copy of configuration information in user space"
? Theoretically, the maximum length of netlink message is 4gb, but the buffer of socket generally does not set such a large space to accommodate 4gb messages. Usually, the length of a message is limited to the size of a page (PAGE_SIZE), and then a large message is divided into multiple messages by using fragmentation mechanism. The segmented message has NLM _ F _ multi-flag bits, and the receiver needs to continuously receive and parse the message until it receives the message with the message type NLMSG_DONE.
? Compared with the fragmented ip Bao Butong, the fragmented Netlink message does not need to be reorganized, but it can be reorganized if the protocol needs to be reorganized. Segmented messages are usually used to send object lists or object trees. In this case, a message segment only carries a few objects, which usually allows each message segment to be processed separately.
? An error message can be sent back as a response to the request message. The error message must use the standard message type NLMSG_ERROR, and its payload consists of the error code and the original request message header.
? The sender can ask the receiver to send an ACK message for each request message processed by setting the NLM_F_ACK flag bit. This method is usually used to let the sender synchronize the next operation after the receiver has processed the request.
? The NLM_F_ECHO flag is similar to the NLM_F_ACK flag, and it can be used together with the NLM _ F _ request flag bit, so that the sender can receive the notification information generated as a response to this request message, regardless of whether the sender has subscribed to the corresponding multicast group.
The GET request also defines some additional general flag bits:
? The use of these flags is completely optional, and many netlink protocols only use NLM _ F _ dump flags. This flag is usually used to request the receiver to send a list containing all the objects, which is usually a series of message fragments.
? There are also some flags related to new requests or aggregate requests. These flags and GET flags are mutually exclusive:
These symbols may have slightly different meanings in different netlink protocols.
? Netlink allows you to associate replies and requests through serial numbers. It should be noted that the serial number here is different from that of TCP and other protocols, and the serial number of Netlink is not mandatory. The sole purpose of the sequence number is to associate the reply message with the corresponding request message. The serial number is managed on a single socket basis.