I am going to conntrack and NAT for a udp traffic with destination port 4. So I just changed very a little lines of helper structer in the nf_conntrack_ftp.c : ftp[i][j].tuple.src.u.udp.port = 4; ftp[i][j].tuple.dst.protonum = IPPROTP_UDP; and right after it enters the conntrack_helper i printed out the tuple content of the skbuff. It looks like this: for the initiatted Query, ctinfo = IP_CT_NEW; the original tuple is: 0x0a151615:4 -> 0x0a161717:4 l3num:2 protonum:17 the reply tuple: 0x0a161717:4 -> 0x0a161716:4 l3num:2 protonum:17(here the ipt_MASQUERADE has altered the reply tuple after SNAT). and when the Response comes, the output is then: ctinfo = IP_CT_NEW(which i think should be IP_CT_IS_REPLY) original tuple: 0x0a161717:4 -> 0x0a161716:4 l3num:2 protonum:17 reply tuple: 0x0a161716:4 -> 0x0a161717:4 l3num:2 protonum:17 I think the promblem here is that when the Response get into "resolve_normal_ct()", it couldn't find the right tuple it belongs to, so the netfilter initiated a new tuple for it as what i'v printed out. But the original tuple of Response matched exactly the reply tuple of Query. It should find the right tuple when it get into PREROUTING hooks, but not initiated a new tuple of it.. Is there someone could help me figure this out?? best regards!! -- Yun Lin 76137 Karlsruhe Baden-Württemberg overcloud@xxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
