hi! could you please revert my patch adding the check, and rather apply the following patch?
This way we should find out where/when/how this "impossible" configuration happens? I really need to understand what's going on, and I cannot reproduce the bug here. Thanks! -- - Harald Welte <[EMAIL PROTECTED]> http://gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
diff --git a/net/ipv4/netfilter/ip_nat_core.c b/net/ipv4/netfilter/ip_nat_core.c --- a/net/ipv4/netfilter/ip_nat_core.c +++ b/net/ipv4/netfilter/ip_nat_core.c @@ -262,6 +262,11 @@ ip_nat_setup_info(struct ip_conntrack *c int have_to_hash = !(conntrack->status & IPS_NAT_DONE_MASK); enum ip_nat_manip_type maniptype = HOOK2MANIP(hooknum); + if (conntrack == &ip_conntrack_untracked) { + printk(KERN_ERR "untracked connection in %s\n", __FUNCTION__); + dump_stack(); + } + IP_NF_ASSERT(hooknum == NF_IP_PRE_ROUTING || hooknum == NF_IP_POST_ROUTING || hooknum == NF_IP_LOCAL_IN @@ -356,6 +361,11 @@ unsigned int nat_packet(struct ip_conntr unsigned long statusbit; enum ip_nat_manip_type mtype = HOOK2MANIP(hooknum); + if (ct == &ip_conntrack_untracked) { + printk(KERN_ERR "untracked connection in %s\n", __FUNCTION__); + dump_stack(); + } + if (mtype == IP_NAT_MANIP_SRC) statusbit = IPS_SRC_NAT; else @@ -391,6 +401,11 @@ int icmp_reply_translation(struct sk_buf struct ip_conntrack_tuple inner, target; int hdrlen = (*pskb)->nh.iph->ihl * 4; + if (ct == &ip_conntrack_untracked) { + printk(KERN_ERR "untracked connection in %s\n", __FUNCTION__); + dump_stack(); + } + if (!skb_ip_make_writable(pskb, hdrlen + sizeof(*inside))) return 0;
pgprCFfq7xPfT.pgp
Description: PGP signature