ok.
连接状态信息获取出来了,用的另一种思路,不依附以前的netlink,而直接通过系统的proc文件系统获取的信息,这样不要考虑同步异步问题,也提高了多线程的效率。
不过一下午都纠结在如何分解这些字符串中,但后来还是省去了这种繁琐的分解上面。
另辟溪路:
谢谢seen大哥给出的另一条抓包的路,确实也不用考虑阻塞问题了,我原以为netlink的效率会很高。
如果nf_conntrack内核模块与user space只有唯一的"proc"通讯的话,那只能用"cat方式“了。给后期的nat实现带来了一定的影响。
连接跟踪实现:
貌似现在的思路越来越明朗了:
关于链接跟踪
1,通过"proc"与nf_conntrack内核模块通讯,获取连接信息
2,通过之前自己已实现ip包过滤模块的hook,来获得ip头,tcp,udp头信息并通过netlink获取连接信息
类似“ipv4 2 tcp 6 5 TIME_WAIT src=192.168.0.25 dst=221.238.249.178 sport=39027 dport=80 packets=6 bytes=1119 src=221.238.249.178 dst=192.168.0.25 sport=80 dport=39027 packets=5 bytes=2474 [ASSURED] mark=0 secmark=0 use=1"
只是里面的bytes mark secmark use TIME_WAIT 这几个信息不知道是从哪来的???
_________________________________________________
发现不是单播 和多播的问题
问题出再多线程建立多个sock时候发生阻塞,虽然局部变量sock在有时候能够成功,但在多线程同时创建的时候就发生错误了。
没办法,只能共享一个sock链接和绑定了,但动态获取ip数据包的时候也很容易和添加禁止ip发生阻塞,内核模块只要稍微没做的好,用户态这么的线程接收函数就会出现“死锁”现象,所以确定需要解决的重点在:不管网络层是否有网络数据包,内核模块都需要即使返回消息给用户态,这样才不会让用户态无限等下去....这是今天解决的问题。
并分享下今天的成果:

________________________________________________________
单播与多播
虽然前几天解决了多线程发送消息的问题,没有发生错误,但是感觉效果不是很好,我添加了端口的小功能,发现和IP信息包同时启动共用同一协议的NL连接时的反应很慢,甚至丢失数据。
因为在外面,今天晚上再去试试多播异步传送。
int netlink_unicast(struct sock *ssk, struct sk_buff *skb, u32 pid, int nonblock);
data指向要被发送的 netlink信息,pid是接收进程的pid号。这里使用NLPID公式1。Nonblock表示这个API在接收缓冲不可用或者立即返回失败时是不是 被阻塞。
我们也可以使用多播来发送信息。下面的函数将发送一个消息到一个配置了特殊pid和多播组的进程。
代码:
void netlink_broadcast(struct sock *ssk, struct sk_buff *skb, u32 pid, u32 group, int allocation);
其中group是所有接收的多播组的标志号。Allocation是内核内存分配类型。如果是再中断上下文环境,有GFP_ATOMIC,其他的有GFP_KERNEL。这取决于内核需要分配一个内存块还是分配多个缓冲用来克隆这个多播信息。
本文来自电脑杂谈,转载请注明本文网址:
https://www.pc-fly.com/a/jisuanjixue/article-36628-5.html
我们不针对美国
非权力非战略能定而