catalog

1. Netlink簡介 2. Netlink Function API Howto 3. Generic Netlink HOWTO kernel API 4. RFC 3549 Linux Netlink as an IP Services Protocol 5. sendmsg、recvmsg In User Space 6. kernel_recvmsg、kernel_sendmsg In Kernel Space 7. NetLink Sockets C++ Library 8. Netlink Protocol Library Suite (libnl)

?

1. Netlink簡介

Netlink is a flexible, robust, wire-format communications channel typically used for kernel to user communication although it can also be used for user to user and kernel to kernel communications. Netlink communication channels are associated with families or "busses", where each bus deals with a specific service; for example

1. 路由daemon(NETLINK_ROUTE) 2. 1-wire子系統(NETLINK_W1) 3. 用戶態socket協議(NETLINK_USERSOCK) 4. 防火墻(NETLINK_FIREWALL) 5. socket監視(NETLINK_INET_DIAG) 6. netfilter日志(NETLINK_NFLOG) 7. ipsec安全策略(NETLINK_XFRM) 8. SELinux事件通知(NETLINK_SELINUX) 9. iSCSI子系統(NETLINK_ISCSI) 10. 進程審計(NETLINK_AUDIT) 11. 轉發信息表查詢(NETLINK_FIB_LOOKUP) 12. netlink connector(NETLINK_CONNECTOR) 13. netfilter子系統(NETLINK_NETFILTER) 14. IPv6防火墻(NETLINK_IP6_FW) 15. DECnet路由信息(NETLINK_DNRTMSG) 16. 內核事件向用戶態通知(NETLINK_KOBJECT_UEVENT) 17. 通用netlink(NETLINK_GENERIC)

Netlink相對于系統調用，ioctl以及/proc文件系統而言具有以下優點

1. 為了使用netlink，用戶僅需要在include/linux/netlink.h中增加一個新類型的netlink協議定義即可，如 #define NETLINK_MYTEST 17 然后，內核和用戶態應用就可以立即通過 socket API 使用該 netlink 協議類型進行數據交換。但系統調用需要增加新的系統調用，ioctl 則需要增加設備或文件， 那需要不少代碼，proc 文件系統則需要在 /proc 下添加新的文件或目錄，那將使本來就混亂的 /proc 更加混亂 2. netlink是一種異步通信機制，在內核與用戶態應用之間傳遞的消息保存在socket緩存隊列中，發送消息只是把消息保存在接收者的socket的接 收隊列，而不需要等待接收者收到消息，但系統調用與 ioctl 則是同步通信機制，如果傳遞的數據太長，將影響調度粒度 3．使用 netlink 的內核部分可以采用模塊的方式實現，使用 netlink 的應用部分和內核部分沒有編譯時依賴，但系統調用就有依賴，而且新的系統調用的實現必須靜態地連接到內核中，它無法在模塊中實現，使用新系統調用的應用在編譯時需要依賴內核 4．netlink 支持多播，內核模塊或應用可以把消息多播給一個netlink組，屬于該neilink 組的任何內核模塊或應用都能接收到該消息，內核事件向用戶態的通知機制就使用了這一特性，任何對內核事件感興趣的應用都能收到該子系統發送的內核事件 5．內核可以使用 netlink 首先發起會話(雙向的)，但系統調用和 ioctl 只能由用戶應用發起調用 6．netlink 使用標準的 socket API，因此很容易使用，但系統調用和 ioctl則需要專門的培訓才能使用

0x2: Netllink通信流程

從用戶態-內核態交互的角度來看，Netlink的通信流程如下

1. 應用程序將待發送的數據通過sendmsg()傳給Netlink，Netlink進行"組包"，這實際上是一次內存拷貝 2. Netlink在buffer滿之后，即組包完成，將消息一次性進行"穿透拷貝"，即copy_from_user、copy_to_user，這是一次代價較高的系統調用 3. 內核模塊從Netlink的buffer逐個取出數據包，即拆包，這個過程可以串行的實現，也可以異步地實現

Relevant Link:

http://www.linuxfoundation.org/collaborate/workgroups/networking/netlink

?

2. Netlink Function API Howto

0x1: User Space

用戶態應用使用標準的socket APIs，socket()、bind()、sendmsg()、recvmsg()、close()就能很容易地使用netlink socket

socket(AF_NETLINK, SOCK_RAW, netlink_type) 1. 參數1: 1) AF_NETLINK2) PF_NETLINK //在 Linux 中，它們倆實際為一個東西，它表示要使用netlink2. 參數2:1) SOCK_RAW2) SOCK_DGRAM3. 參數3: 指定Netlink協議類型 #define NETLINK_ROUTE 0 /* Routing/device hook */ #define NETLINK_W1 1 /* 1-wire subsystem */ #define NETLINK_USERSOCK 2 /* Reserved for user mode socket protocols */ #define NETLINK_FIREWALL 3 /* Firewalling hook */ #define NETLINK_INET_DIAG 4 /* INET socket monitoring */ #define NETLINK_NFLOG 5 /* netfilter/iptables ULOG */ #define NETLINK_XFRM 6 /* ipsec */ #define NETLINK_SELINUX 7 /* SELinux event notifications */ #define NETLINK_ISCSI 8 /* Open-iSCSI */ #define NETLINK_AUDIT 9 /* auditing */ #define NETLINK_FIB_LOOKUP 10 #define NETLINK_CONNECTOR 11 #define NETLINK_NETFILTER 12 /* netfilter subsystem */ #define NETLINK_IP6_FW 13 #define NETLINK_DNRTMSG 14 /* DECnet routing messages */ #define NETLINK_KOBJECT_UEVENT 15 /* Kernel messages to userspace */ #define NETLINK_GENERIC 16 //NETLINK_GENERIC是一個通用的協議類型，它是專門為用戶使用的，因此，用戶可以直接使用它，而不必再添加新的協議類型

對于每一個netlink協議類型，可以有多達 32多播組，每一個多播組用一個位表示，netlink 的多播特性使得發送消息給同一個組僅需要一次系統調用，因而對于需要多撥消息的應用而言，大大地降低了系統調用的次數

bind(fd, (struct sockaddr*)&nladdr, sizeof(struct sockaddr_nl)); 函數bind()用于把一個打開的netlink socket與netlink源socket地址綁定在一起。netlink socket的地址結構如下struct sockaddr_nl {//字段 nl_family 必須設置為 AF_NETLINK 或著 PF_NETLINK sa_family_t nl_family;//字段 nl_pad 當前沒有使用，因此要總是設置為 0unsigned short nl_pad;/*字段 nl_pid 為接收或發送消息的進程的 ID1. nl_pid = 0: 消息接收者為內核或多播組2. nl_pid != 0: nl_pid 實際上未必是進程 ID，它只是用于區分不同的接收者或發送者的一個標識，用戶可以根據自己需要設置該字段 */__u32 nl_pid;/*nl_groups 用于指定多播組，bind 函數用于把調用進程加入到該字段指定的多播組1. nl_groups = 0: 該消息為單播消息，調用者不加入任何多播組2. nl_groups != 0: 多播消息*/__u32 nl_groups; };

值得注意的是，傳遞給 bind 函數的地址的 nl_pid 字段應當設置為本進程的進程 ID，這相當于 netlink socket 的本地地址。但是，對于一個進程的多個線程使用 netlink socket 的情況，字段 nl_pid 則可以設置為其它的值，如

pthread_self() << 16 | getpid();

字段 nl_pid 實際上未必是進程 ID,它只是用于區分不同的接收者或發送者的一個標識，用戶可以根據自己需要設置該字段

關于使用netlink api及其相關參數，請參閱另一篇文章 http://www.cnblogs.com/LittleHann/p/3867214.html //搜索：user_client.c(用戶態程序)

從netlink發送消息相關的數據結構中我們可以看出netlink發送消息的邏輯

1. 對于程序員來說，發送消息的系統調用接口只有sendmsg，每次調用sendmsg只需要傳入struct msghdr結構體的實例即可 2. 對于每個struct msghdr結構的實例來說，都必須指定struct iovec成員，即所有單個的消息都會被"掛入"一個"隊列"中，用于緩存集中發送 3. 每個代表"消息隊列"的struct iovec結構體實例，都必須指定struct nlmsghdr成員，即消息頭，用于實現"多路復用"和"多路分解"

0x2: Kernel Space

內核使用netlink需要專門的API，這完全不同于用戶態應用對netlink的使用。如果用戶需要增加新的netlink協 議類型，必須通過修改linux/netlink.h來實現，當然，目前的netlink實現已經包含了一個通用的協議類型 NETLINK_GENERIC以方便用戶使用，用戶可以直接使用它而不必增加新的協議類型

在內核中，為了創建一個netlink socket用戶需要調用如下函數 struct sock *netlink_kernel_create(int unit, void (*input)(struct sock *sk, int len));

當內核中發送netlink消息時，也需要設置目標地址與源地址，linux/netlink.h中定義了一個宏

struct netlink_skb_parms {/*Skb credentials struct scm_creds {//pid表示消息發送者進程ID，也即源地址，對于內核，它為 0u32 pid;kuid_t uid;kgid_t gid;};struct scm_creds creds; /*字段portid表示消息接收者進程 ID，也即目標地址，如果目標為組或內核，它設置為 0，否則 dst_group 表示目標組地址，如果它目標為某一進程或內核，dst_group 應當設置為 0 */__u32 portid;__u32 dst_group;__u32 flags;struct sock *sk; }; #define NETLINK_CB(skb) (*(struct netlink_skb_parms*)&((skb)->cb))

在內核中，模塊調用函數 netlink_unicast 來發送單播消息

int netlink_unicast(struct sock *sk, struct sk_buff *skb, u32 pid, int nonblock);

Relevant Link:

http://www.cnblogs.com/iceocean/articles/1594195.html http://blog.csdn.net/zcabcd123/article/details/8272423

?

3. Generic Netlink HOWTO kernel API

Relevant Link:

http://www.linuxfoundation.org/collaborate/workgroups/networking/generic_netlink_howto

?

4. RFC 3549 Linux Netlink as an IP Services Protocol

A Control Plane (CP) is an execution environment that may have several sub-components, which we refer to as CPCs.? Each CPC provides control for a different IP service being executed by a Forwarding Engine (FE) component.? This relationship means that there might be several CPCs on a physical CP, if it is controlling several IP services. ?
In essence, the cohesion between a CP component and an FE component is the service abstraction.

0x1: Control Plane Components (CPCs)

Control Plane Components encompass signalling protocols, with diversity ranging from dynamic routing protocols, such as OSPF to tag distribution protocols, such as CR-LDP. Classical management protocols and activities also fall under this category.
These include SNMP、COPS、and proprietary CLI/GUI configuration mechanisms.? The purpose of the control plane is to provide an execution environment for the above-mentioned activities with the ultimate goal being to configure and manage the second Network Element (NE) component: the FE.? The result of the configuration defines the way that packets traversing the FE are treated.

0x2: Forwarding Engine Components (FECs)

The FE is the entity of the NE that incoming packets (from the network into the NE) first encounter.
The FE's service-specific component massages the packet to provide it with a treatment to achieve an IP service, as defined by the Control Plane Components for that IP service.? Different services will utilize different FECs.? Service modules may be chained to achieve a more complex service ?
When built for providing a specific service, the FE service component will adhere to a forwarding model.

1. Linux IP Forwarding Engine Model

?

____ +---------------++->-| FW |---> | TCP, UDP, ... || +----+ +---------------+| |^ v| _|_+----<----+ | FW || +----+^ || YTo host From hoststack stack^ ||_____ | Ingress ^ Y device ____ +-------+ +|---|--+ ____ +--------+ Egress ->----->| FW |-->|Ingress|-->---->| Forw- |->| FW |->| Egress | device+----+ | TC | | ard | +----+ | TC |-->+-------+ +-------+ +--------+

The figure above shows the Linux FE model per device.? The only mandatory part of the datapath is the Forwarding module, which is RFC 1812 conformant.? The different Firewall (FW), Ingress Traffic Control, and Egress Traffic Control building blocks are not mandatory in the datapath and may even be used to bypass the RFC 1812 module.
These modules are shown as simple blocks in the datapath but, in fact, could be multiple cascaded, independent submodules within the indicated blocks.

2. IP Services

In the diagram below, we show a simple FE<->CP setup to provide an example of the classical IPv4 service with an extension to do some basic QoS egress scheduling and illustrate how the setup fits in this described model.

Control Plane (CP).------------------------------------| /^^^^^^\ /^^^^^^\ || | | | COPS |-\ || | ospfd | | PEP | \ || \ / \_____/ | |/------\_____/ | / || | | | / || |_________\__________|____|_________|| | | |******************************************Forwarding ************* Netlink layer ************Engine (FE) *****************************************.-------------|-----------|----------|---|-------------| IPv4 forwarding | | || FE Service / / || Component / / || ---------------/---------------/--------- || | | / | |packet | | --------|-- ----|----- | packetin | | | IPv4 | | Egress | | out-->--->|------>|---->|Forwarding|----->| QoS |--->| ---->|->| | | | | Scheduler| | || | ----------- ---------- | || | | || --------------------------------------- || |-------------------------------------------------------

0x3: Netlink Logical Model

In the diagram below we show a simple FEC<->CPC logical relationship. We use the IPv4 forwarding FEC (NETLINK_ROUTE, which is discussed further below) as an example.

Control Plane (CP).------------------------------------| /^^^^^\ /^^^^^\ || | | / CPC-2 \ || | CPC-1 | | COPS | || | ospfd | | PEP | || | / \____ _/ || \____/ | || | | |****************************************|************* BROADCAST WIRE ************FE---------- *****************************************.| IPv4 forwarding | | | || FEC | | | || --------------/ ----|-----------|-------- || | / | | | || | .-------. .-------. .------. | || | |Ingress| | IPv4 | |Egress| | || | |police | |Forward| | QoS | | || | |_______| |_______| |Sched | | || | ------ | || --------------------------------------- || |-----------------------------------------------------

Netlink logically models FECs and CPCs in the form of nodes interconnected to each other via a broadcast wire.
The wire is specific to a service.? The example above shows the broadcast wire belonging to the extended IPv4 forwarding service.
Nodes (CPCs or FECs as illustrated above) connect to the wire and register to receive specific messages.? CPCs may connect to multiple wires if it helps them to control the service better.? All nodes(CPCs and FECs) dump packets on the broadcast wire.? Packets can be discarded by the wire if they are malformed or not specifically formatted for the wire.? Dropped packets are not seen by any of the nodes.? The Netlink service may signal an error to the sender if it detects a malformatted Netlink packet.

0x4: Message Format

There are three levels to a Netlink message: The general Netlink message header, the IP service specific template, and the IP service specific data.
從網絡的角度來看，Netlink是一種傳輸層通信協議

0 1 2 30 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| || Netlink message header || |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| || IP Service Template || |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| || IP Service specific data in TLVs || |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The Netlink message is used to communicate between the FEC and CPC for parameterization of the FECs, asynchronous event notification of FEC events to the CPCs, and statistics querying/gathering (typically by a CPC).

0x5: Protocol Model

1. Service Addressing

Access is provided by first connecting to the service on the FE.? The connection is achieved by making a socket() system call to the PF_NETLINK domain.? Each FEC is identified by a protocol number.? One may open either SOCK_RAW or SOCK_DGRAM type sockets, although Netlink does not distinguish between the two.? The socket connection provides the basis for the FE<->CP addressing.
Connecting to a service is followed (at any point during the life of the connection) by either issuing a service-specific command (from the CPC to the FEC, mostly for configuration purposes), issuing a statistics-collection command, or subscribing/unsubscribing to service events.? Closing the socket terminates the transaction.

2. Netlink Message Header

Netlink messages consist of a byte stream with one or multiple Netlink headers and an associated payload.? If the payload is too big to fit into a single message it, can be split over multiple Netlink messages, collectively called a multipart message.? For multipart messages, the first and all following headers have the NLM_F_MULTI Netlink header flag set, except for the last header which has the Netlink header type NLMSG_DONE.

0 1 2 30 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Length |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Type | Flags |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Sequence Number |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Process ID (PID) |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3. The ACK Netlink Message

This message is actually used to denote both an ACK and a NACK. Typically, the direction is from FEC to CPC (in response to an ACK request message).? However, the CPC should be able to send ACKs back to FEC when requested.? The semantics for this are IP service specific.

0 1 2 30 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Netlink message header || type = NLMSG_ERROR |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Error code |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| OLD Netlink message header |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Relevant Link:

https://tools.ietf.org/html/rfc3549

?

5. sendmsg、recvmsg In User Space

0x1: sendmsg

/source/net/socket.c

/** BSD sendmsg interface*/ SYSCALL_DEFINE3(sendmsg, int, fd, struct msghdr __user *, msg, unsigned, flags) {struct compat_msghdr __user *msg_compat = (struct compat_msghdr __user *)msg;struct socket *sock;struct sockaddr_storage address;struct iovec iovstack[UIO_FASTIOV], *iov = iovstack;unsigned char ctl[sizeof(struct cmsghdr) + 20] __attribute__ ((aligned(sizeof(__kernel_size_t))));/* 20 is size of ipv6_pktinfo */unsigned char *ctl_buf = ctl;struct msghdr msg_sys;int err, ctl_len, iov_size, total_len;int fput_needed;err = -EFAULT;if (MSG_CMSG_COMPAT & flags) {if (get_compat_msghdr(&msg_sys, msg_compat))return -EFAULT;}else {err = copy_msghdr_from_user(&msg_sys, msg);if (err)return err;}sock = sockfd_lookup_light(fd, &err, &fput_needed);if (!sock)goto out;/* do not move before msg_sys is valid */err = -EMSGSIZE;if (msg_sys.msg_iovlen > UIO_MAXIOV)goto out_put;/* Check whether to allocate the iovec area */err = -ENOMEM;iov_size = msg_sys.msg_iovlen * sizeof(struct iovec);if (msg_sys.msg_iovlen > UIO_FASTIOV) {iov = sock_kmalloc(sock->sk, iov_size, GFP_KERNEL);if (!iov)goto out_put;}/* This will also move the address data into kernel space */if (MSG_CMSG_COMPAT & flags) {err = verify_compat_iovec(&msg_sys, iov, (struct sockaddr *)&address, VERIFY_READ);} elseerr = verify_iovec(&msg_sys, iov, (struct sockaddr *)&address, VERIFY_READ);if (err < 0)goto out_freeiov;total_len = err;err = -ENOBUFS;if (msg_sys.msg_controllen > INT_MAX)goto out_freeiov;ctl_len = msg_sys.msg_controllen;if ((MSG_CMSG_COMPAT & flags) && ctl_len) {err = cmsghdr_from_user_compat_to_kern(&msg_sys, sock->sk, ctl, sizeof(ctl));if (err)goto out_freeiov;ctl_buf = msg_sys.msg_control;ctl_len = msg_sys.msg_controllen;} else if (ctl_len) {if (ctl_len > sizeof(ctl)) {ctl_buf = sock_kmalloc(sock->sk, ctl_len, GFP_KERNEL);if (ctl_buf == NULL)goto out_freeiov;}err = -EFAULT;/** Careful! Before this, msg_sys.msg_control contains a user pointer.* Afterwards, it will be a kernel pointer. Thus the compiler-assisted* checking falls down on this.*/if (copy_from_user(ctl_buf, (void __user *)msg_sys.msg_control, ctl_len))goto out_freectl;msg_sys.msg_control = ctl_buf;}msg_sys.msg_flags = flags;if (sock->file->f_flags & O_NONBLOCK)msg_sys.msg_flags |= MSG_DONTWAIT;err = sock_sendmsg(sock, &msg_sys, total_len);out_freectl:if (ctl_buf != ctl)sock_kfree_s(sock->sk, ctl_buf, ctl_len); out_freeiov:if (iov != iovstack)sock_kfree_s(sock->sk, iov, iov_size); out_put:fput_light(sock->file, fput_needed); out:return err; }

/source/net/socket.c

int sock_sendmsg(struct socket *sock, struct msghdr *msg, size_t size) {struct kiocb iocb;struct sock_iocb siocb;int ret;init_sync_kiocb(&iocb, NULL);iocb.private = &siocb;/*調用__sock_sendmsg進行UDP數據報的發送*/ret = __sock_sendmsg(&iocb, sock, msg, size);if (-EIOCBQUEUED == ret)ret = wait_on_sync_kiocb(&iocb);return ret; }static inline int __sock_sendmsg(struct kiocb *iocb, struct socket *sock, struct msghdr *msg, size_t size) {struct sock_iocb *si = kiocb_to_siocb(iocb);int err;si->sock = sock;si->scm = NULL;si->msg = msg;si->size = size;err = security_socket_sendmsg(sock, msg, size);if (err)return err;/*const struct proto_ops inet_dgram_ops = {.family = PF_INET,.owner = THIS_MODULE,.release = inet_release,.bind = inet_bind,.connect = inet_dgram_connect,.socketpair = sock_no_socketpair,.accept = sock_no_accept,.getname = inet_getname,.poll = udp_poll,.ioctl = inet_ioctl,.listen = sock_no_listen,.shutdown = inet_shutdown,.setsockopt = sock_common_setsockopt,.getsockopt = sock_common_getsockopt,.sendmsg = inet_sendmsg,.recvmsg = sock_common_recvmsg,.mmap = sock_no_mmap,.sendpage = inet_sendpage,#ifdef CONFIG_COMPAT.compat_setsockopt = compat_sock_common_setsockopt,.compat_getsockopt = compat_sock_common_getsockopt,#endif};EXPORT_SYMBOL(inet_dgram_ops);從結構體中可以看出，sendmsg()對應的系統調用是inet_sendmsg()我們繼續跟進分析inet_sendmsg()\linux-2.6.32.63\net\ipv4\af_inet.c*/return sock->ops->sendmsg(iocb, sock, msg, size); }

\linux-2.6.32.63\net\ipv4\af_inet.c

int inet_sendmsg(struct kiocb *iocb, struct socket *sock, struct msghdr *msg, size_t size) {struct sock *sk = sock->sk;/* We may need to bind the socket. */if (!inet_sk(sk)->num && inet_autobind(sk))return -EAGAIN; /*INET SOCKET調用協議特有sendmsg操作符 對于INET socket中的udp發送，協議特有操作符集為udp_protlinux-2.6.32.63\net\ipv4\udp.cstruct proto udp_prot = {.name = "UDP",.owner = THIS_MODULE,.close = udp_lib_close,.connect = ip4_datagram_connect,.disconnect = udp_disconnect,.ioctl = udp_ioctl,.destroy = udp_destroy_sock,.setsockopt = udp_setsockopt,.getsockopt = udp_getsockopt,.sendmsg = udp_sendmsg,.recvmsg = udp_recvmsg,.sendpage = udp_sendpage,.backlog_rcv = __udp_queue_rcv_skb,.hash = udp_lib_hash,.unhash = udp_lib_unhash,.get_port = udp_v4_get_port,.memory_allocated = &udp_memory_allocated,.sysctl_mem = sysctl_udp_mem,.sysctl_wmem = &sysctl_udp_wmem_min,.sysctl_rmem = &sysctl_udp_rmem_min,.obj_size = sizeof(struct udp_sock),.slab_flags = SLAB_DESTROY_BY_RCU,.h.udp_table = &udp_table,#ifdef CONFIG_COMPAT.compat_setsockopt = compat_udp_setsockopt,.compat_getsockopt = compat_udp_getsockopt,#endif};EXPORT_SYMBOL(udp_prot);可以看出，對于UDP，流程進入udp_sendmsg函數(.sendmsg對應的是udp_sendmsg()函數)，我們繼續跟進udp_sendmsg()\linux-2.6.32.63\net\ipv4\udp.c*/return sk->sk_prot->sendmsg(iocb, sk, msg, size); } EXPORT_SYMBOL(inet_sendmsg);

0x2: recvmsg

/source/net/socket.c

/** BSD recvmsg interface*/ SYSCALL_DEFINE3(recvmsg, int, fd, struct msghdr __user *, msg, unsigned int, flags) {struct compat_msghdr __user *msg_compat = (struct compat_msghdr __user *)msg;struct socket *sock;struct iovec iovstack[UIO_FASTIOV];struct iovec *iov = iovstack;struct msghdr msg_sys;unsigned long cmsg_ptr;int err, iov_size, total_len, len;int fput_needed;/* kernel mode address */struct sockaddr_storage addr;/* user mode address pointers */struct sockaddr __user *uaddr;int __user *uaddr_len;if (MSG_CMSG_COMPAT & flags) {if (get_compat_msghdr(&msg_sys, msg_compat))return -EFAULT;}else {err = copy_msghdr_from_user(&msg_sys, msg);if (err)return err;}sock = sockfd_lookup_light(fd, &err, &fput_needed);if (!sock)goto out;err = -EMSGSIZE;if (msg_sys.msg_iovlen > UIO_MAXIOV)goto out_put;/* Check whether to allocate the iovec area */err = -ENOMEM;iov_size = msg_sys.msg_iovlen * sizeof(struct iovec);if (msg_sys.msg_iovlen > UIO_FASTIOV) {iov = sock_kmalloc(sock->sk, iov_size, GFP_KERNEL);if (!iov)goto out_put;}/* Save the user-mode address (verify_iovec will change the* kernel msghdr to use the kernel address space)*/uaddr = (__force void __user *)msg_sys.msg_name;uaddr_len = COMPAT_NAMELEN(msg);if (MSG_CMSG_COMPAT & flags)err = verify_compat_iovec(&msg_sys, iov, (struct sockaddr *)&addr, VERIFY_WRITE);elseerr = verify_iovec(&msg_sys, iov, (struct sockaddr *)&addr, VERIFY_WRITE);if (err < 0)goto out_freeiov;total_len = err;cmsg_ptr = (unsigned long)msg_sys.msg_control;msg_sys.msg_flags = flags & (MSG_CMSG_CLOEXEC|MSG_CMSG_COMPAT);/* We assume all kernel code knows the size of sockaddr_storage */msg_sys.msg_namelen = 0;if (sock->file->f_flags & O_NONBLOCK)flags |= MSG_DONTWAIT;err = sock_recvmsg(sock, &msg_sys, total_len, flags);if (err < 0)goto out_freeiov;len = err;if (uaddr != NULL) {err = move_addr_to_user((struct sockaddr *)&addr, msg_sys.msg_namelen, uaddr, uaddr_len);if (err < 0)goto out_freeiov;}err = __put_user((msg_sys.msg_flags & ~MSG_CMSG_COMPAT), COMPAT_FLAGS(msg));if (err)goto out_freeiov;if (MSG_CMSG_COMPAT & flags)err = __put_user((unsigned long)msg_sys.msg_control - cmsg_ptr, &msg_compat->msg_controllen);elseerr = __put_user((unsigned long)msg_sys.msg_control - cmsg_ptr, &msg->msg_controllen);if (err)goto out_freeiov;err = len;out_freeiov:if (iov != iovstack)sock_kfree_s(sock->sk, iov, iov_size); out_put:fput_light(sock->file, fput_needed); out:return err; }

?

6. kernel_recvmsg、kernel_sendmsg In Kernel Space

0x1: kernel_recvmsg

/source/net/socket.c

int kernel_recvmsg(struct socket *sock, struct msghdr *msg, struct kvec *vec, size_t num, size_t size, int flags) {mm_segment_t oldfs = get_fs();int result;set_fs(KERNEL_DS);/** the following is safe, since for compiler definitions of kvec and* iovec are identical, yielding the same in-core layout and alignment*/msg->msg_iov = (struct iovec *)vec, msg->msg_iovlen = num;result = sock_recvmsg(sock, msg, size, flags);set_fs(oldfs);return result; }

對于內核態來說，數據包此時已經copy到了Netlink的KERNEL態緩存了

0x2: kernel_sendmsg

/source/net/socket.c

int kernel_sendmsg(struct socket *sock, struct msghdr *msg, struct kvec *vec, size_t num, size_t size) {mm_segment_t oldfs = get_fs();int result;set_fs(KERNEL_DS);/** the following is safe, since for compiler definitions of kvec and* iovec are identical, yielding the same in-core layout and alignment*/msg->msg_iov = (struct iovec *)vec;msg->msg_iovlen = num;result = sock_sendmsg(sock, msg, size);set_fs(oldfs);return result; }

Relevant Link:

http://www.opensource.apple.com/source/Heimdal/Heimdal-247.9/lib/roken/sendmsg.c https://fossies.org/dox/glibc-2.21/sysdeps_2mach_2hurd_2sendmsg_8c_source.html http://lxr.free-electrons.com/source/net/socket.c

?

7. NetLink Sockets C++ Library

0x1: Features

1. Cross Platform Library 2. Easy to use 3. Powerful and Reliable 4. Supports both Ip4 and Ip6 5. SocketGroup class to manage the connections 6. OnAcceptReady, OnReadReady, OnDisconnect callback model 7. Fully documented library API 8. Enables to Develop socket functionality extremely Fast 9. Fits single threaded and multi-threaded designs

Relevant Link:

http://sourceforge.net/projects/netlinksockets/

?

8. Netlink Protocol Library Suite (libnl)

The libnl suite is a collection of libraries providing APIs to netlink protocol based Linux kernel interfaces.
Netlink is a IPC mechanism primarly between the kernel and user space processes. It was designed to be a more flexible successor to ioctl to provide mainly networking related kernel configuration and monitoring interfaces.

?

The interfaces are split into several small libraries to not force applications to link against a single, bloated library.

0x1: libnl

Core library implementing the fundamentals required to use the netlink protocol such as socket handling, message construction and parsing, and sending and receiving of data. This library is kept small and minimalistic. Other libraries of the suite depend on this library.

0x2:?libnl-route

API to the configuration interfaces of the NETLINK_ROUTE family including network interfaces, routes, addresses, neighbours, and traffic control.

0x3: libnl-genl

API to the generic netlink protocol, an extended version of the netlink protocol.

0x4: libnl-nf

API to netlink based netfilter configuration and monitoring interfaces (conntrack, log, queue)

Relevant Link:

http://www.carisma.slowglass.com/~tgr/libnl/ http://www.carisma.slowglass.com/~tgr/libnl/doc/core.html

?

Copyright (c) 2015 LittleHann All rights reserved

?

轉載于:https://www.cnblogs.com/LittleHann/p/4418754.html

總結

以上是生活随笔為你收集整理的NetLink Communication Mechanism And Netlink Sourcecode Analysis的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。