netlink与tcp_diag编程
Posted broler
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了netlink与tcp_diag编程相关的知识,希望对你有一定的参考价值。
概览
http://m.oschina.net/blog/351007有一个示例程序,但是它用的v1的接口。
http://kristrev.github.io/2013/07/26/passive-monitoring-of-sockets-on-linux/
教了怎么用v2的接口。
inet_diag和tcp_diag是两个模块,但是统一使用inet_diag的接口,inet_diag又是使用netlink的接口。要使用你得加载这两个模块,大部分的发行版都是默认加载的(ss命令就是用这个)。
使用这套接口去获得tcp信息,涉及到两个问题:请求格式和返回格式。
请求格式是这样的:
struct
{
struct nlmsghdr nlh;
struct inet_diag_req_v2 r;
} req;
因为netlink要求一个通用的netlink头部后面跟具体请求类型对应的数据头部。这里的数据头部使用inet_diag_req_v2或者inet_diag_req都可以。是两种版本的实现,inet_diag_req_v2更友好一些。
netlink头部填充
http://stuff.onse.fi/man?program=netlink§ion=7
netlink使用通用的socket接口,只是添加了一个新的类型。创建netlink的socket的方法:
#include<asm/types.h>
#include <sys/socket.h>
#include <linux/netlink.h>
netlink_socket =socket(AF_NETLINK, socket_type, netlink_family);
socket_type只可以是SOCK_RAW或者SOCK_DGRAM,内核并不区分这两种,所以用户使用哪个都可以。而netlink_family就是用来选择具体netlink在内核端沟通的模块了:
netlink请求头部
netlink的请求头部结构体是
struct nlmsghdr{
__u32 nlmsg_len; /* Length of message including header. */
__u16 nlmsg_type; /* Type of message content. */
__u16 nlmsg_flags; /* Additional flags. */
__u32 nlmsg_seq; /* Sequence number. */
__u32 nlmsg_pid; /* Sender port ID. */
};
由于netlink要求一个netlink请求头部后面要跟具体的请求类型的头部(例如inet_diag
的请求就需要跟inet_diag的头部),所以这里有个nlmsg_len域,用来表示netlink头部加上请求头部一起的长度。
nlmsg_type就是后端对应的功能模块,随着内核功能的完善,这个支持的模块也在增长。见下节。nlmsg_flags就是针对操作的后端的操作flag,见下下节。
一个netlink请求的头部允许有多个nlmsghdr,每个的nlmsg_flags域要设置NLM_F_MULTI,最后一个设置NLMSG_DONE。这种多个nlmsghdr结构体的情况,每个头部的数据都紧跟在这个头部的后面。
nlmsg_pid用来表示发送这个请求的进程pid(所以你可以伪造为其他进程发送),nlmsg_seq是用户自己设置的,内核的返回也会回复这个,可以让用户用来追踪任何一个请求。如果你嫌烦,可以在bind的时候填好pid,这里可以直接设个0,没人会怪你。
netlink后端功能模块
NETLINK_ROUTE用来与邻居表路由表,数据包分类器等路由子系统通信,获取信息或者设置。
NETLINK_W1就是GPIO用来拉高或者拉低某一根线的内核子系统,所以用户如果使用GPIO就可以不用动内核,直接在用户空间操作GPIO了。
NETLINK_USERSOCK就是用户端socket,使用这个处理netlink请求的单位就不是内核了,而是用户空间的的另外一头的某个进程。恩,你想的没错,这个就是进程间通信的又一种方案。由于是socket,一端可以监听,另一端发送的只要将发送的目标地址填充为目标进程的pid就好(netlink的发送地址不是ip编码的,而是pid等编码的)。
这种IPC最牛逼的地方在于可以支持multicast,多播的通信。一个消息同时发送给多个接受者,但是普通的回环地址lo的socket通信也可以做到这一点。
NETLINK_FIREWALL这个是跟内核的netfilter的ip_queue模块沟通的选项。ip_queue是netfilter提供的将网络数据包从内核传递到用户空间的方法,内核中要提供ip_queue支持,在用户层空间打开一个netlink的socket后就可以接受内核通过ip_queue所传递来的网络数据包,具体数据包类型可由iptables命令来确定,只要将规则动作设置为“-j QUEUE”即可。
之所以要命名为ip_queue,是因为这是一个队列处理过程,iptables规则把指定的包发给QUEUE是一个数据进入队列的过程,而用户空间程序通过netlink socket获取数据包进行裁定,结果返回内核,进行出队列的操作。
在iptables代码中,提供了libipq库,封装了对ipq的一些操作,用户层程序可以直接使用libipq库函数处理数据。
NETLINK_IP6_FW与NETLINK_FIREWALL的功能一样,只是是专门针对ipv6的。
NETLINK_INET_DIAG就是同网络诊断模块通信使用的,最常用的是tcp_diag模块,可以获得tcp连接的最详细信息。
NETLINK_NFLOG是内核用来将netfilter的日志发送到用户空间的方法。
NETLINK_XFRM就是与内核的ipsec子模块通信的机制。
NETLINK_SELINUX与内核的selinux通信。
NETLINK_ISCSI是open iscsi的内核部分,通过iscsi可以组成iscsi网络,让你的网路存储系统high起来。
NETLINK_AUDIT与内核的audit模块通信。记录了一大堆事件。
NETLINK_FIB_LOOKUP用户可以自由的查询fib路由表了。fib是快速转发表,里面量很大,刷新比较快,服务于快速查找和快速转发,而不是服务于用户空间设置,用户空间设置使用的路由表是rib,在内核中rib会转化为fib。
NETLINK_CONNECTOR是内核端的模块如果想要使用netlink接口对用户提供服务,这个模块可以去注册一个netlink回调,用户空间使用这个子系统就可以连接到特定的内核模块。
NETLINK_NETFILTER用于控制netfilter的。
NETLINK_DNRTMSG:DECnet的,大部分人用不到
NETLINK_KOBJECT_UEVENT:sys子系统使用的uevent事件。内核内所有设备的uevent事件都会通过这个接口发送到用户空间
NETLINK_GENERIC:这个也是内核模块用来提供netlink接口的方式。通过这种方式提供的接口都可以复用这一个子系统。
NETLINK_CRYPTO:可以使用内核的加密系统或者修改查询内核的加密系统参数。
netlink请求nlmsg_flags
由于涉及到具体的后端请求类型,所以这个flag的设计时尽可能通用的,在不同的后端的时候会有不同的表现。大家可以大概了解一下每个flag的意思,但是在使用的使用要根据不同的用途区别对待。
与具体模块无关的通用设置:
NLM_F_REQUEST:所有请求类型的netlink都会设置
NLM_F_MULTI:用于表示多个netlink请求在同一个包的NLMSG_DONE结尾最后一个头部
NLM_F_ACK:由于netlink是不可靠的,可以通过让内核回复ack模拟的实现可靠(其实绝大多数情况下是可靠的,如果不可靠说明内存不够了)
NLM_F_ECHO:这是让内核响应这个请求,一般需要内核响应的(但是也不是所有的内核子系统都是按照这个模型设计的),如果不设置,很可能只有ack(如果设置了NLM_F_ACK的话)
专门为GET类的请求附带的flag:
NLM_F_ROOT:返回满足条件的整个表,而不是单个的entry
NLM_F_MATCH:返回所有匹配的,这个在内核中只是提供了一个接口,并没有具体的实现。所以目前设不设都无所谓。但是比如tcp_diag的根据sockid获取单条tcp连接信息的功能,就可以使用这个标志,只是目前还没有实现而已。
NLM_F_ATOMIC:请求返回表的时候,返回的是一个快照
NLM_F_DUMP:这个是(NLM_F_ROOT|NLM_F_MATCH)的组合,意思是返回全部满足指定条件的条目。
专为SET类的请求附带的flag
NLM_F_REPLACE:取代已经存在的匹配条目
NLM_F_EXCL:如果条目已经存在就不取代
NLM_F_CREATE:如果不存在就创建
NLM_F_APPEND:加在对象列表的最后
netlink的请求类型nlmsgs_type
这个与具体的后端模块相关的,不是netlink还是提供了集中通用的消息类型(但是实际使用的使用一般要按照情况使用对应的后端模块定义的type,例如inet_diag就定义了TCPDIAG_GETSOCK,DCCPDIAG_GETSOCK这两种类型的type)。这些通用的在include/uapi/rtnetlink.h中定义了一坨。
inet_diag模块
概览
inet_diag是diag系统中的一部分,他的上面还有sock_diag,下面有tcp_diag。所有的inet_diag都被注册到sock_diag内部的静态数据结构,每一个inet_diag都是一个方法调用的列表,登记了各种需要的操作。主要有三个:destroy、dump和get_info,get_info用于销毁的时候,实际使用的时候只有dump和detroy。
netlink请求头部
inet_diag模块是netlink后端的一个子系统,他的请求头部如下
struct inet_diag_req_v2 {
38 __u8 sdiag_family;
39 __u8 sdiag_protocol;
40 __u8 idiag_ext;
41 __u8 pad;
42 __u32 idiag_states;
43 struct inet_diag_sockidid;
44 };
这个是请求inet_diag的请求,sdiag_family,sdiag_protocol这些就和正常的socket一样的设置AF_INET,IPPROTO_TCP。idiag_states就是指tcp的连接状态(如果是UDP的话就是UDP,这取决于你填充的netlink的.nlh.nlmsg_type= TCPDIAG_GETSOCK;)。我们这里关注tcp,这就就填你关注的tcp连接状态,内核对tcp连接状态的定义有两套:
enum {
TCP_ESTABLISHED= 1,
TCP_SYN_SENT,
TCP_SYN_RECV,
TCP_FIN_WAIT1,
TCP_FIN_WAIT2,
TCP_TIME_WAIT,
TCP_CLOSE,
TCP_CLOSE_WAIT,
TCP_LAST_ACK,
TCP_LISTEN,
TCP_CLOSING, /* Now a valid state */
TCP_NEW_SYN_RECV,
TCP_MAX_STATES /* Leave at the end! */
};
enum {
TCPF_ESTABLISHED= (1 << 1),
TCPF_SYN_SENT = (1 << 2),
TCPF_SYN_RECV = (1 << 3),
TCPF_FIN_WAIT1 = (1 << 4),
TCPF_FIN_WAIT2 = (1 << 5),
TCPF_TIME_WAIT = (1 << 6),
TCPF_CLOSE = (1 << 7),
TCPF_CLOSE_WAIT = (1 << 8),
TCPF_LAST_ACK = (1 << 9),
TCPF_LISTEN = (1 << 10),
TCPF_CLOSING = (1 << 11),
TCPF_NEW_SYN_RECV= (1 << 12),
};
所以,你可以很明显的看出来应该用第二套。第一套是用来给内部使用的,第二套使用来给外部使用的。第二套可以轻松的实现不同状态的组合设置。
所以,我们这里的idiag_states就用第二套来组合设置。如果想要全部,你就可以任性的使用0xff来搞定。还有一个idiag_ext域,
enum {
104 INET_DIAG_NONE,
105 INET_DIAG_MEMINFO,
106 INET_DIAG_INFO,
107 INET_DIAG_VEGASINFO,
108 INET_DIAG_CONG,
109 INET_DIAG_TOS,
110 INET_DIAG_TCLASS,
111 INET_DIAG_SKMEMINFO,
112 INET_DIAG_SHUTDOWN,
113 };
这个ext可以获得更多种类的信息,包括内存(ss –m参数),如果不填(就是填0)就是INET_DIAG_NONE,表示啥都不要。也可以看出来,同一个请求只能请求一种数据。我们比较关注tcp连接的信息,所以使用INET_DIAG_INFO。
还有一个是唯一标识一个socket的域,
struct inet_diag_sockid {
14 __be16 idiag_sport;
15 __be16 idiag_dport;
16 __be32 idiag_src[4];
17 __be32 idiag_dst[4];
18 __u32 idiag_if;
19 __u32 idiag_cookie[2];
20 #define INET_DIAG_NOCOOKIE (~0U)
21 };
可以看到,标识一个socket不是用的五元组,而是源ip:源端口,目的ip:目的端口,从哪个设备获得的,还有唯一的标示内核中的一个socket的cookie,这个cookie值是在内核中计算sock结构体的sk_cookie域得出来的,一般用户端不需要填充这个域,在两个字节都放个INET_DIAG_NOCOOKIE就去就可以了。
内核内部在连接表中查找:
而内核的这个实现只会查找ESTABLISHED状态和LISTEN状态的连接,所以想要查询其他状态的tcp连接信息的可以洗洗睡了。最后那个socket绑定的设备也是必须的,因为内核中的查找也要使用这个信息。
但是不是所有的请求都需要填充所有的头部,例如如果你想要全部dump整个tcp连接表,就可以不填sockid域(置0)。
你会发现idiag_src和idiag_dst都是4个字节的,这并不是要你输入字符串,而是要兼容ipv6,所以这个接口是ipv6和ipv4通用的。ipv4的话只需要填充第一个单位就可以了。
注意的是这里地址和端口是网络序的,idiag_if一般是0,如果你不确定,先全部填0,选项上用NLM_F_DUMP就可以看到现有的都是怎么存储的了。但是要获得单个的socket的信息需要使用NLM_F_ATOMIC,当然NLM_F_REQUEST都是必须的。
操作种类
总体来说,所有的sock_diag都只提供一种对外接口,那就是dump。但是显然的只有这么一种是不够的。inet_diag就用这个dump接口实现了dump和对其他操作的封装。这个dump对应的inet_diag模块内部的操作是inet_diag_handler_cmd函数。想要获得netlink本身的dump信息,必须得设置NLM_F_DUMP这个flag(#define NLM_F_DUMP (NLM_F_ROOT|NLM_F_MATCH)),但是执行功能时我们是希望获得tcp连接的信息,由于内核保存tcp连接信息的方式是使用tcp_hashinfo全局结构体,所以本质上,就是查询的这个哈希表,而这个哈希表中只有ESTABLISHED和LISTEN状态,所以,你也查不到别的状态。
内核还有一个get_info接口可以获得很多数据,但是sock_diag没有对外提供,其实完全可以对外提供的,就可以获得tcp最详细的数据。也就是说现在inet_diag和tcp_diag都支持获得tcp_info,只是sock_diag没有对外提供。而tcp通过getsockopt对外提供了获得tcp_info结构体的能力。
获得数据内容
其实tcp_diag能获得很多数据,除了tcp_info之外,还可以获得一些拥塞控制算法和内存上的信息(都在idiag_ext域指定):
struct inet_diag_msg {
87 __u8 idiag_family;
88 __u8 idiag_state;
89 __u8 idiag_timer;
90 __u8 idiag_retrans;
91
92 struct inet_diag_sockidid;
93
94 __u32 idiag_expires;
95 __u32 idiag_rqueue;
96 __u32 idiag_wqueue;
97 __u32 idiag_uid;
98 __u32 idiag_inode;
99 };
这个是基础的所能获得的信息,tcp_info就放在这些数据后面,如果是其他的请求也是一样的道理。
以上是关于netlink与tcp_diag编程的主要内容,如果未能解决你的问题,请参考以下文章