可编译易用的模块化nf-HiPAC移植成功
2014-11-22 18:41
239 查看
模块化nf-HiPAC的工作只能排在晚上完成,周四晚上折腾到12点终于算是完成了。效果也还不错,最初的tar包放到了下载频道“模块化的nf- HiPAC”,也会有另外的人放在github上,下载频道的主要是为了使用,而github上的主要是为了更新,这主要鉴于nf-hipac在还有很多 TODO的情况下就停止了更新.
Planned Features:
implement better algorithmic core: The new core will dramatically reduce memory usage while at the same time improving the running time of insert and delete operations. The lookup performance will be improved radically too, especially for bigger rulesets.
The concepts and the design are already developed, but the implementation is still in its very early stages
add support for transactions
add support for ipv6
add support for MAC matches
add functionality similar to iptables-restore
add native support for set of ranges (e.g. ippools). Each native match is not a single range but instead a set of ranges, which makes a single rule more expressive
consider making HiPAC available for NAT and mangle tables
consider removing "rule prefix mismatch" limitation
the next big step in the far future will be to extend the HiPAC algorithm to do classification with several stages. The HiPAC algorithm will then be capable of combining several classification problems in one data structure, e.g. it will be possible to
solve routing, firewalling and traffic control with one HiPAC lookup. The idea is to shorten the packet forwarding path by combining e.g. fib_lookup and iptables filter lookup into one HiPAC query
Outstanding Bugfixes:
fix handling of jump rules containing iptables matches (currently only some known iptables matches are allowed in jump rules)
in the current version the number of rule updates per second is limited by the number of synchronize_rcu() calls per second. This slows down rule updates dramatically. Future releases will work around this problem and will offer full rule update speed again
Other Stuff:
man page for userspace tool
add more documentation
more in-depth performance tests
模 块化后的nf-hipac可以直接编译出一个ko文件以及一个用户态的工具nf-hipac程序。值得注意的是,我在移植过程中,去掉了和 iptables模块的联动机制,这有两方面的原因,第一是因为这方面的移植比较复杂,iptables的内核API在内核版本之间变化太大了;另一方面 就是还真的不怎么会用到iptables的match/target模块,如果使用了大量的iptables match/target模块,还不如直接就用iptables呢,再者说,iptables模块只是延展了nf-hipac的功能,对其性能是一个打折
的过程。
以下是模块化移植工作遇到的一些问题:
需要将match/target操作进行移植,内核API变化太大,砍去。
这 部分比较容易。2.6.13版本的netlink的input回调函数参数是一个socket,创建者需要自己创建内核线程来从该socket的 queue中持续获取skb并且维护queue本身,这部分工作在高版本内核中得到了简化,因为input回调函数的参数就是skb本身,队列的维护由 netlink系统完成。
在原始的nf-hipac中,为了节省内存,用了两套内存管理方案,即mini alloc/free以及big alloc/free,在调试这部分的时候遇到了不少问题,加之现在内存没必要那么节省,我就统一采用了big alloc/free,也就是说统一在vmalloc区域进行分配。
说实话,2.6.32内核对net namespace的支持也只是个半吊子,但无论如何接口已经适配了,这就是说我必须按照net namespace的要求来处理proc_net。
我只是测试了2.6.32内核和3.9.6内核,对于其它版本的内核并没有测试,这种风格也是拜ipset-6.23所赐,要知道,我也是一个很较真儿的人,有时候也会有点书生气。
...
即便是不下载tgz压缩包,也可以通过打patch的方式构建编译目录。
新建一个nf-hipac空目录并cd到它,然后执行:
patch -p1 < $path/nfhipac-1.0.0.patch
就 会将所有的文件和目录置于该目录下,然后make;make install即可。注意,编译的时候需要准备好你的当前内核版本头文件,链接到/lib/modules/`uname -r`/build。 最后给出一个比较长的patch,即nfhipac-1.0.0.patch文件:51CTO下载中心。
Planned Features:
implement better algorithmic core: The new core will dramatically reduce memory usage while at the same time improving the running time of insert and delete operations. The lookup performance will be improved radically too, especially for bigger rulesets.
The concepts and the design are already developed, but the implementation is still in its very early stages
add support for transactions
add support for ipv6
add support for MAC matches
add functionality similar to iptables-restore
add native support for set of ranges (e.g. ippools). Each native match is not a single range but instead a set of ranges, which makes a single rule more expressive
consider making HiPAC available for NAT and mangle tables
consider removing "rule prefix mismatch" limitation
the next big step in the far future will be to extend the HiPAC algorithm to do classification with several stages. The HiPAC algorithm will then be capable of combining several classification problems in one data structure, e.g. it will be possible to
solve routing, firewalling and traffic control with one HiPAC lookup. The idea is to shorten the packet forwarding path by combining e.g. fib_lookup and iptables filter lookup into one HiPAC query
Outstanding Bugfixes:
fix handling of jump rules containing iptables matches (currently only some known iptables matches are allowed in jump rules)
in the current version the number of rule updates per second is limited by the number of synchronize_rcu() calls per second. This slows down rule updates dramatically. Future releases will work around this problem and will offer full rule update speed again
Other Stuff:
man page for userspace tool
add more documentation
more in-depth performance tests
模 块化后的nf-hipac可以直接编译出一个ko文件以及一个用户态的工具nf-hipac程序。值得注意的是,我在移植过程中,去掉了和 iptables模块的联动机制,这有两方面的原因,第一是因为这方面的移植比较复杂,iptables的内核API在内核版本之间变化太大了;另一方面 就是还真的不怎么会用到iptables的match/target模块,如果使用了大量的iptables match/target模块,还不如直接就用iptables呢,再者说,iptables模块只是延展了nf-hipac的功能,对其性能是一个打折
的过程。
以下是模块化移植工作遇到的一些问题:
1.iptables模块的问题
需要将match/target操作进行移植,内核API变化太大,砍去。
2.netlink接口问题
这 部分比较容易。2.6.13版本的netlink的input回调函数参数是一个socket,创建者需要自己创建内核线程来从该socket的 queue中持续获取skb并且维护queue本身,这部分工作在高版本内核中得到了简化,因为input回调函数的参数就是skb本身,队列的维护由 netlink系统完成。
3.内存问题
在原始的nf-hipac中,为了节省内存,用了两套内存管理方案,即mini alloc/free以及big alloc/free,在调试这部分的时候遇到了不少问题,加之现在内存没必要那么节省,我就统一采用了big alloc/free,也就是说统一在vmalloc区域进行分配。
4.net namespace问题
说实话,2.6.32内核对net namespace的支持也只是个半吊子,但无论如何接口已经适配了,这就是说我必须按照net namespace的要求来处理proc_net。
5.其它
我只是测试了2.6.32内核和3.9.6内核,对于其它版本的内核并没有测试,这种风格也是拜ipset-6.23所赐,要知道,我也是一个很较真儿的人,有时候也会有点书生气。...
即便是不下载tgz压缩包,也可以通过打patch的方式构建编译目录。
新建一个nf-hipac空目录并cd到它,然后执行:
patch -p1 < $path/nfhipac-1.0.0.patch
就 会将所有的文件和目录置于该目录下,然后make;make install即可。注意,编译的时候需要准备好你的当前内核版本头文件,链接到/lib/modules/`uname -r`/build。 最后给出一个比较长的patch,即nfhipac-1.0.0.patch文件:51CTO下载中心。
相关文章推荐
- 可编译易用的模块化nf-HiPAC移植成功
- Fedora8上交叉编译qtopia4移植成功到s3c2410开发板
- Fedora8上交叉编译qtopia4移植成功到s3c2410开发板
- S3C6410移植u-boot-2010.3(1)成功编译的开始
- 编译支持x264 编码的ffmpeg并成功移植到docker
- MAC系统下编译FFmpeg-Android (从编译到移植Androidstudio成功)(一)
- 可编译易用的模块化nf-HiPAC移植成功
- 程序移植到VS2010,编译成功但是无法启动lib文件
- X3 C++ PluginFramework 已经在Linux下移植编译成功(转载)
- S3C6410移植u-boot-2010.3(1)成功编译的开始
- QTE移植成功后的交叉编译
- 移植安装linux的包时,常见的库链接,可能会导致编译不成功
- Fedora8上交叉编译qtopia4移植成功到s3c2410开发板
- android2.3系统成功下载编译移植到BeagleBoard上
- 移植Gens for linux到arm--------编译成功
- Fedora8上交叉编译qtopia4移植成功到s3c2410开发板
- Fedora8上交叉编译qtopia4移植成功到s3c2410开发板
- u-boot-2016.01移植笔记之先让u-boot可以编译成功以及添加2440单板
- QTE移植成功后的交叉编译
- (OK) 移植,编译,安装 LineageOS-14.1-kiwi (Android-7.1.1,运行在Huawei honor 5x) for VirtualBox - 90% 成功