search for: ip_ct_dir_origin

Displaying 7 results from an estimated 7 matches for "ip_ct_dir_origin".

Did you mean: ip_ct_dir_original
2006 Apr 13
3
[Bug 466] u.tcp used where u.udp should be, in tftp nat helper
...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.
2003 Aug 02
0
[SECURITY] Netfilter Security Advisory: Conntrack list_del() DoS
...d 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 table. */ static inline int is_confirmed(struct ip_conntrack *ct) { - return ct->tuplehash[IP_CT_DIR_ORIGINAL].list.next !=3D NULL; + return test_bit(IPS_CONFIRMED_BIT, &ct->status); } =20 extern unsigned int ip_conntrack_htable_size; diff -urN --exclude-from=3Ddiff.exclude linux-2.4.20-base/net/ipv4/netfilte= r/ip_conntrack_core.c linux-2.4.20-del/net/ipv4/netfilter/ip_conntrack_core= =2Ec ---...
2002 Jan 20
0
[ANNOUNCE] Bug in kernel == 2.4.10 causing netfilter problem
.../* 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_REPLY]); LIST_DELET...
2016 Oct 04
13
[Bug 1087] New: Window Tracking not disabled
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
2013 Mar 20
2
netfilter+libvirt=(smth got broken?)
Hello, I'm having problem setting up filtering traffic for a virtual machine managed by libvirt. Strange thing is, such a setup has been working fine for me on an older version of distro (namely, opensuse 11.3 w/updates, kernel 2.6.34, libvirt 0.8.8) but refused to work on shiny new opensuse 12.4 (kernel 3.7.10, libvirt 1.0.2). The definition of filter in question is pretty simple:
2011 Apr 07
8
[Bug 714] New: Kernel panics in same_src()
...t 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 really know. It happen...
2013 Jul 05
4
[Bug 831] New: oops in find_appropriate_src+219
...018 #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) <<<panic because rdx...