Sat, 19 Feb 2000 14:43:47 +1100
In message <200002190333.WAA04228@opium.mbsi.ca> you write:
> Hi Rusty,
> The new NAT expect stuff doesn't work here when MASQUERADing ftp
> connections. The PORT command gets properly rewritten, but then the
> incoming ftp-data SYN is rejected by the packet-filter.
> ftp_nat_expected() is never called, because in ip_nat_rule_find()
> ip_conntrack_master_get() returns NULL.
> Are you aware of this problem? need more info?
Yep. I'm off for the weekend (up to Sydney to celebrate Richard
Gooch's devfs finally getting official blessing!), but here's the info
which was sent to me (my ftp tests are obviously NOWHERE NEAR good
enough: HINT people!)
After a little more stepping through the 0.90.1 code I found yet a couple of problems in ftp nat :
1) conntrack expected tuple's dst ip is not set to the NATed one, so the reply packets aren't launching the nat expect callbacks.
2) ftp_nat_expected looks into the slave, not into master conntrack as it should.
ftp_nat_expected(struct sk_buff **pskb,
unsigned int hooknum,
struct ip_conntrack_tuple_hash *h,
struct ip_nat_info *info,
struct ip_conntrack *master,
struct ip_nat_info *masterinfo,
unsigned int *verdict)
struct ip_nat_multi_range mr;
u_int32_t newdstip, newsrcip, newip;
struct ip_ct_ftp *ftpinfo;
/* Master must be an ftp connection */
ftpinfo = STRUCT_RESERVED_PTR(ip_conntrack, h->ctrack,
Here we take the ftpinfo from slave, not master!
And in previous mail I reported that the expectant field is not initialized. So there are at least three reasons why ftp isnt't working.