HELP!! responded Tuple doesn't match after MASQUERADE, and marked as IP_CT_NEW,therefor no DNAT will be applied

[Yun Lin <overcloud@gmail.com>]

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@gmail.com