search for: nf_drop

...terate(struct li /* Optimization: we don't need to hold module reference here, since function can't sleep. --RR */ - switch (elem->hook(hook, skb, indev, outdev, okfn)) { - case NF_QUEUE: - return NF_QUEUE; - - case NF_STOLEN: - return NF_STOLEN; - - case NF_DROP: - return NF_DROP; - - case NF_REPEAT: - *i = (*i)->prev; - break; - + verdict = elem->hook(hook, skb, indev, outdev, okfn); + if (verdict != NF_ACCEPT) { #ifdef CONFIG_NETFILTER_DEBUG - case NF_ACCEPT: - break; - - default: - NFDEBUG("Evil return from %p(%u).\n", -...

On Fri, 07 Jan 2005 17:05:59 +0000 David Woodhouse <dwmw2@infradead.org> wrote: > On Sat, 2004-12-18 at 08:50 +0100, Andi Kleen wrote: > > It's not really an oops, just a warning that stack space got quiet > > tight. > > > > The problem seems to be that the br netfilter code is nesting far too > > deeply and recursing several times. Looks like a design

...al Priority: P2 Component: ip_conntrack AssignedTo: laforge@netfilter.org ReportedBy: Bob.Halley@nominum.com Background Our application uses ip_queue in prerouting to divert DNS UDP packets to a userland daemon which inspects them and then issues a NF_ACCEPT or NF_DROP verdict back to the kernel. We found that if several packets with the same conntrack tuple, i.e. the same src addr, src port, dst addr, and dst port, arrive very close together, then only the first one accepted by our software actually makes it back out to the wire; the others are silently dropped...

...called. after processing, the callback function calls nfq_set_verdict(). after a **verdict** is returned, next packet will pop from the queue. notice that a packet will not pop from queue if its preceding packet has not been issued a verdict. This verdict values are NF_ACCEPT for accepting packet, NF_DROP for dropping the packet. Now what if i want to concatenate the udp payloads of the incoming and outgoing packet without touching client and server side code? If i want to concatenate udp payloads from our app this very app, then we need to have multiple packets at hand. But we have seen that a pa...

...en pass the result back to ebtable code. Everything seemed to be working fine until i encountered locking issues. In the ebt_do_table code there is a "read_lock_bh" is used. When i try to wait inside this code path after sending info to my userspace tool and before returning NF_ACCEPT or NF_DROP, either the CPU hangs or i get an error "schedule while atomic". I tried out different methods for waiting like "wait_event_timeout" or busy while loop etc. The problem that I understood is that since read_lock_bh disables CPU preemption and do "local_bh_disable", if...

...culprit: 120: /* Don't try to NAT if this packet is not conntracked */ 121: if (ct == &nf_conntrack_untracked) 122: return NF_ACCEPT; 123: 124: nat = nfct_nat(ct); -> 125: if (!nat) -> 126: return NF_DROP; If I read this correctly, packets for connections which aren't tracked at all are accepted, but packets for connections which are being tracked don't have NAT information are dropped. Is there any reason why line 126 shouldn't return NF_ACCEPT? Thanks, -Ted -- Configure...

Looks like the GSO is involved? I got this while running Dom0 only (no guests), with a BOINC/Rosetta@home application running on all 4 cores. changeset: 10649:8e55c5c11475 Build: x86_32p (pae). ------------[ cut here ]------------ kernel BUG at net/core/dev.c:1133! invalid opcode: 0000 [#1] SMP CPU: 0 EIP: 0061:[<c04dceb0>] Not tainted VLI EFLAGS: 00210297 (2.6.16.13-xen