netfilter连接跟踪 resolve_normal_ct函数中的疑问??
时间:2010-08-10
来源:互联网
本帖最后由 __dreamcatcher 于 2010-08-10 20:38 编辑
本人在看netfilter的连接跟踪模块时,遇到了些疑问,请大家给与指点。
在nf_conntrack_in()的函数中调用了resolve_normal_ct,我在看这个函数时有点不明白的是if (NF_CT_DIRECTION(h) == IP_CT_DIR_REPLY)这句话什么时候才可以执行?
static inline struct nf_conn *
resolve_normal_ct(struct net *net,
struct sk_buff *skb,
unsigned int dataoff,
u_int16_t l3num,
u_int8_t protonum,
struct nf_conntrack_l3proto *l3proto,
struct nf_conntrack_l4proto *l4proto,
int *set_reply,
enum ip_conntrack_info *ctinfo)
{
if (!nf_ct_get_tuple(skb, skb_network_offset(skb),
dataoff, l3num, protonum, &tuple, l3proto,
l4proto)) {
pr_debug("resolve_normal_ct: Can't get tuple\n");
return NULL;
}
/* look for tuple match */
h = nf_conntrack_find_get(net, &tuple);
ct = nf_ct_tuplehash_to_ctrack(h);
if (NF_CT_DIRECTION(h) == IP_CT_DIR_REPLY) {
*ctinfo = IP_CT_ESTABLISHED + IP_CT_IS_REPLY;
/* Please set reply bit if this packet OK */
*set_reply = 1;
} else {
.......
*set_reply = 0;
}
.......
}
首先分析nf_ct_get_tuple()函数,在函数中存在这么一个问题,就是dst.dir始终被初始化为IP_CT_DIR_ORIGINAL,如下标记所示:
bool
nf_ct_get_tuple(const struct sk_buff *skb,
unsigned int nhoff,
unsigned int dataoff,
u_int16_t l3num,
u_int8_t protonum,
struct nf_conntrack_tuple *tuple,
const struct nf_conntrack_l3proto *l3proto,
const struct nf_conntrack_l4proto *l4proto)
{
memset(tuple, 0, sizeof(*tuple));
tuple->src.l3num = l3num;
if (l3proto->pkt_to_tuple(skb, nhoff, tuple) == 0)
return false;
tuple->dst.protonum = protonum;
tuple->dst.dir = IP_CT_DIR_ORIGINAL;
return l4proto->pkt_to_tuple(skb, dataoff, tuple);
}
在以后的nf_conntrack_find_get() 和 nf_ct_tuplehash_to_ctrack()函数中也没有发现tuple的dst.dir被修改,所以感觉resolve_normal_ct()函数中的
if (NF_CT_DIRECTION(h) == IP_CT_DIR_REPLY) { ,,,,,, }段一直无法执行。
知道我的某些地方理解的不正确,还请各位大虾帮忙指点一下,谢谢了!
此内核版本为linux-2.6.33.2
本人在看netfilter的连接跟踪模块时,遇到了些疑问,请大家给与指点。
在nf_conntrack_in()的函数中调用了resolve_normal_ct,我在看这个函数时有点不明白的是if (NF_CT_DIRECTION(h) == IP_CT_DIR_REPLY)这句话什么时候才可以执行?
static inline struct nf_conn *
resolve_normal_ct(struct net *net,
struct sk_buff *skb,
unsigned int dataoff,
u_int16_t l3num,
u_int8_t protonum,
struct nf_conntrack_l3proto *l3proto,
struct nf_conntrack_l4proto *l4proto,
int *set_reply,
enum ip_conntrack_info *ctinfo)
{
if (!nf_ct_get_tuple(skb, skb_network_offset(skb),
dataoff, l3num, protonum, &tuple, l3proto,
l4proto)) {
pr_debug("resolve_normal_ct: Can't get tuple\n");
return NULL;
}
/* look for tuple match */
h = nf_conntrack_find_get(net, &tuple);
ct = nf_ct_tuplehash_to_ctrack(h);
if (NF_CT_DIRECTION(h) == IP_CT_DIR_REPLY) {
*ctinfo = IP_CT_ESTABLISHED + IP_CT_IS_REPLY;
/* Please set reply bit if this packet OK */
*set_reply = 1;
} else {
.......
*set_reply = 0;
}
.......
}
首先分析nf_ct_get_tuple()函数,在函数中存在这么一个问题,就是dst.dir始终被初始化为IP_CT_DIR_ORIGINAL,如下标记所示:
bool
nf_ct_get_tuple(const struct sk_buff *skb,
unsigned int nhoff,
unsigned int dataoff,
u_int16_t l3num,
u_int8_t protonum,
struct nf_conntrack_tuple *tuple,
const struct nf_conntrack_l3proto *l3proto,
const struct nf_conntrack_l4proto *l4proto)
{
memset(tuple, 0, sizeof(*tuple));
tuple->src.l3num = l3num;
if (l3proto->pkt_to_tuple(skb, nhoff, tuple) == 0)
return false;
tuple->dst.protonum = protonum;
tuple->dst.dir = IP_CT_DIR_ORIGINAL;
return l4proto->pkt_to_tuple(skb, dataoff, tuple);
}
在以后的nf_conntrack_find_get() 和 nf_ct_tuplehash_to_ctrack()函数中也没有发现tuple的dst.dir被修改,所以感觉resolve_normal_ct()函数中的
if (NF_CT_DIRECTION(h) == IP_CT_DIR_REPLY) { ,,,,,, }段一直无法执行。
知道我的某些地方理解的不正确,还请各位大虾帮忙指点一下,谢谢了!
此内核版本为linux-2.6.33.2
作者: __dreamcatcher 发布时间: 2010-08-10
自己顶,求教!
作者: __dreamcatcher 发布时间: 2010-08-11
相关阅读 更多
热门阅读
-
office 2019专业增强版最新2021版激活秘钥/序列号/激活码推荐 附激活工具
阅读:74
-
如何安装mysql8.0
阅读:31
-
Word快速设置标题样式步骤详解
阅读:28
-
20+道必知必会的Vue面试题(附答案解析)
阅读:37
-
HTML如何制作表单
阅读:22
-
百词斩可以改天数吗?当然可以,4个步骤轻松修改天数!
阅读:31
-
ET文件格式和XLS格式文件之间如何转化?
阅读:24
-
react和vue的区别及优缺点是什么
阅读:121
-
支付宝人脸识别如何关闭?
阅读:21
-
腾讯微云怎么修改照片或视频备份路径?
阅读:28