search for: tuplehash

...VED Resolution| |INVALID ------- Additional Comments From netfilter@linuxace.com 2006-04-13 06:19 MET ------- Unclear which version kernel you're looking at, but this is correct in 2.6.latest exp->saved_proto.udp.port = ct->tuplehash[IP_CT_DIR_ORIGINAL].tuple.src.u.udp.port; -- Configure bugmail: https://bugzilla.netfilter.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.

...=3D (1 << IPS_ASSURED_BIT), + + /* Connection is confirmed: originating packet has left box */ + IPS_CONFIRMED_BIT =3D 3, + IPS_CONFIRMED =3D (1 << IPS_CONFIRMED_BIT), }; =20 #include <linux/netfilter_ipv4/ip_conntrack_tcp.h> @@ -159,7 +164,7 @@ struct ip_conntrack_tuple_hash tuplehash[IP_CT_DIR_MAX]; =20 /* Have we seen traffic both ways yet? (bitset) */ - volatile unsigned long status; + unsigned long status; =20 /* Timer function; drops refcnt when it goes off. */ struct timer_list timeout; @@ -254,7 +259,7 @@ /* It's confirmed if it is, or has been in the hash tabl...

...> /* Remove from both hash lists: must not NULL out next ptrs, > otherwise we'll look unconfirmed. Fortunately, LIST_DELETE > doesn't do this. --RR */ > LIST_DELETE(&ip_conntrack_hash > [hash_conntrack(&ct->tuplehash[IP_CT_DIR_ORIGINAL].tu= ple)], > &ct->tuplehash[IP_CT_DIR_ORIGINAL]); > LIST_DELETE(&ip_conntrack_hash > [hash_conntrack(&ct->tuplehash[IP_CT_DIR_REPLY].tuple= )], > &ct->tuplehash[IP_CT_DIR_REP...

...; /* He Yi Oct 22, 2006 */ if( inet_addr_type(iph->daddr) == RTN_LOCAL ) { DEBUGP("DO NOT CHANGE PPTP CALL ID FOR LOCAL SERVICE!\n"); new_callid = ct_pptp_info->pns_call_id; } else { /* NATed src port is the dst port of the reply */ new_callid = ct->tuplehash [IP_CT_DIR_REPLY].tuple.dst.u.tcp.port; } /* save new call ID in ct info */ ct_pptp_info->pns_call_id = ntohs(new_callid); break; ...... It says, if the connection's destination is the local service, then do not mangle the peer's call-ID. -- Confi...

...cpu_idle at ffffffff8100ae7d gdb nf_nat.ko (gdb) l* nf_nat_setup_info+1497 0xf49 is in nf_nat_setup_info (net/ipv4/netfilter/nf_nat_core.c:135). 130 const struct nf_conntrack_tuple *tuple) 131 { 132 const struct nf_conntrack_tuple *t; 133 134 t = &ct->tuplehash[IP_CT_DIR_ORIGINAL].tuple; 135 return (t->dst.protonum == tuple->dst.protonum && 136 t->src.u3.ip == tuple->src.u3.ip && 137 t->src.u.all == tuple->src.u.all); 138 } 139 Steps to Reproduce: I don't reall...

https://bugzilla.netfilter.org/cgi-bin/bugzilla/show_bug.cgi?id=71 ------- Additional Comments From laforge@netfilter.org 2003-03-30 21:18 ------- First of all: You didn't even specify the particular kernel version you are running, not even mentioning which versions of which patches you are using (if any). Secondly, I don't see anything strange in this setup. DNAT with FTP sessions

http://bugzilla.netfilter.org/show_bug.cgi?id=586 Summary: Problems changing the source address of a packet Product: libnetfilter_queue Version: unspecified Platform: All OS/Version: All Status: NEW Severity: blocker Priority: P1 Component: libnetfilter_queue AssignedTo: laforge at netfilter.org

...0010 SS: 0018 #22 [ffff881810db3f30] cpu_idle at ffffffff8100204a crash> >From the dump looked like ct was NULL during the call of find_appropriate_src->same_src, which led to the panic. same_src(const struct nf_conn *ct,const struct nf_conntrack_tuple *tuple) { t = &ct->tuplehash[IP_CT_DIR_ORIGINAL].tuple; <<<<ct was NULL } 0xffffffffa1491a44 <find_appropriate_src+212>: mov 0x20(%rbx),%rdx 0xffffffffa1491a48 <find_appropriate_src+216>: mov (%rbx),%rax 0xffffffffa1491a4b <find_appropriate_src+219>: cmp %r8b,0x3e(%rdx) <<<...

https://bugzilla.netfilter.org/show_bug.cgi?id=1087 Bug ID: 1087 Summary: Window Tracking not disabled Product: conntrack-tools Version: unspecified Hardware: x86_64 OS: All Status: NEW Severity: enhancement Priority: P5 Component: conntrack-daemon Assignee: netfilter-buglog