内核数据包处理

改进：
ﻩ
ﻩ4）数据包操作
错误：
ﻩ陷阱：
无符号数的强制类型转换,u32类型永远都是大于等于0的，当paylｏａd_len小于512时，判断就会不生效。
改进:
或者
ﻩ５)
风险：
陷阱:
ﻩ可能是异常数据包，offset不是你想要的
ﻩ正确做法：
ﻩ
ﻩ
ﻩ综述：数据包处理要时刻保持警醒,它可能不是你想象的样子！
ﻩ内存分配
获取ＩP头部
ﻩ
1)＿_netif＿receive_ｓｋb()在进入三层处理前就对nｅｔworｋ_headeｒ进行了设置。
2）ip＿ｒcｖ()中详细的检查保证了IP头部到ｎetfilteｒ后是完整的。
ﻩ3）netfilｔｅr可以尽情使用ip头部。
ﻩ获取tcp头部
错误１：
陷阱:
netfilｔｅr的钩子点是属于TＣP／IＰ协议栈的三层流程中，而四层的TCＰ头部此时还没有正确获取，只是初始化为IP头部的值，无法直接使用。
ﻩ模块卸载:
ﻩﻩ
2)每CPU变量
ﻩﻩ使用场景：
在钩子函数中使用的临时缓存区,不用每次申请释放，使用全局变量。
ﻩ方法:
ﻩhoｏk函数:
模块加载：
ﻩﻩ模块卸载:
ﻩ
ﻩﻩ注意：
ﻩﻩalloc_pｅrcｐｕ(）上限３2k
改进：
ﻩ2)查找数据包中的某个字符串
ﻩ风险：
ﻩ
陷阱：
可能会越界，数据包不一定是以'＼0＇结束。
ﻩ改进:
ﻩ
ﻩ一定要使用这一系列的函数:
strｎchｒ
ﻩsｔｒncpｙ
ﻩsｔrncat
ｓtrncmｐ
strｎicmp
ﻩｓtrnｌｅｎ
memcpy
3）移动指向数据包的指针
ﻩ风险:
ﻩ
陷阱：
ﻩ查找的字符串有可能是数据包的最后一部分。
ﻩﻩIPｖ6:%pI６%pi6
2)MAC地址
ﻩ%pM%ｐｍ
ﻩ3)字节序的转换
ﻩﻩntｏhs()ｎｔoｈl()ｈtｏns()hｔonl（）
ﻩﻩ＿_conｓｔ_nｔohl(）__consｔ_ntohs()__ｃｏnｓt＿htｏnl(）__ｃoｎｓt＿htons()
ﻩ区别:_＿ｃonsｔ＿*()是编译时处理的。
ﻩ错误2：
陷阱：
数据包可能是非线性的
ﻩ改进:
ﻩ
接口介绍：
ﻩ
计算三层头部相对于ｓkb->data的偏移
ﻩ从skb的指定偏移取制定长度的数据,如果要取的数据位于线性区，直接返回其开始指针,否则，则拷贝到bｕffer中,并将buｆfer指针返回。
打印信息
注意要点:
ﻩ1) IP地址输出
ﻩﻩIｐv4：%pI4%pｉ4
获取ＴCＰ负载
风险:
陷阱1：
数据包可能是非线性的,同TCＰ头部。
陷阱2:
ＴCP头部数据有可能是被篡改过的，tcｐｈ-＞doｆf如果很大怎么办?
改进1:
接口介绍:
ﻩ
判断sｋb的数据是否是非线性的
ﻩ改进2:
ﻩ
改进3：
ﻩ
接口介绍:
ﻩ
ﻩ
ﻩ将ｓkb线性化
解析数据
ﻩ1）判断数据包内容
风险1:
风险2：
ﻩ
陷阱：
ﻩ如果ｐaｙｌoaｄ的长度只有1个字节怎么办?
风险:
ﻩ陷阱1:
ﻩ如果需要申请的size是0会如何？
ﻩ陷阱2:
ﻩ多个cpu并发申请又会如何?
改进：
ﻩ问题:kmａlloc(0,.．.)返回值是什么？
ﻩ建议：相同的内存反复申请释放的情况下,请使用ｋmem＿ｃachｅ_alloｃ
建议的同步与互斥方法
1）rｃu锁
ﻩﻩ使用场景：进程上下文用来配置,软中断上下文只读配置的情况
内核数据包处理
———————————————————————————————— 作者：
———————————————————————————————— 日期：
数据包处理的一些建议
前言
我们大部分功能都需要解析数据,进行一系列的包匹配完成,但是目前,我们没有一个很好的框架来简化这个过程,大家处理数据包都是采用原生的linux内核接口,并且没有统一的规范要求如何使用这些接口,所以,存在大量的陷阱，一不留神就造成宕机。
ﻩ好处:性能高，接口简单
ﻩﻩ方法：
ﻩhoｏk函数读取配置，中断上下文:
ﻩﻩ
ﻩﻩ基于proc文件等的配置下发，进程上下文:
ﻩ
ﻩ另一种方法：
注意１:sｙｎchrｏniｚe_rｃｕ（)只能用于进程上下文，ｃalｌ＿ｒcu(）可以用于中断上下文。
ﻩﻩ注意2:datａ_ｆree_rcu的调用是软中断上下文,不能使用vfｒee。