* Verdict with ebtables? [not found] <AANLkTinCazaFKSXnfGe2e0nnfeRorV7AHcadQaxGvWg+@mail.gmail.com> @ 2010-11-11 10:05 ` Kfir Lavi 2010-11-11 10:48 ` Patrick McHardy 0 siblings, 1 reply; 4+ messages in thread From: Kfir Lavi @ 2010-11-11 10:05 UTC (permalink / raw) To: netfilter-devel Hi, It seems to me that its not possible to do a verdict in userspace of ethernet packets, like it is done with nfqueue and iptables. Why it is not implemented? Or, is there a way to do the same for packets that are not arp or ip? Thanks, Kfir ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Verdict with ebtables? 2010-11-11 10:05 ` Verdict with ebtables? Kfir Lavi @ 2010-11-11 10:48 ` Patrick McHardy 2010-11-14 11:56 ` Kfir Lavi 0 siblings, 1 reply; 4+ messages in thread From: Patrick McHardy @ 2010-11-11 10:48 UTC (permalink / raw) To: Kfir Lavi; +Cc: netfilter-devel On 11.11.2010 11:05, Kfir Lavi wrote: > Hi, > It seems to me that its not possible to do a verdict in userspace of > ethernet packets, like it is done with nfqueue and iptables. > Why it is not implemented? Nobody ever implemented it. IIRC the main problem is that under certain circumstances the packets need to be passed back to __netif_receive_skb() when queuing in LOCAL_IN, which isn't possible from the completion handler. ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Verdict with ebtables? 2010-11-11 10:48 ` Patrick McHardy @ 2010-11-14 11:56 ` Kfir Lavi 2010-11-15 9:39 ` Patrick McHardy 0 siblings, 1 reply; 4+ messages in thread From: Kfir Lavi @ 2010-11-14 11:56 UTC (permalink / raw) To: Patrick McHardy; +Cc: netfilter-devel On Thu, Nov 11, 2010 at 12:48 PM, Patrick McHardy <kaber@trash.net> wrote: > > On 11.11.2010 11:05, Kfir Lavi wrote: > > Hi, > > It seems to me that its not possible to do a verdict in userspace of > > ethernet packets, like it is done with nfqueue and iptables. > > Why it is not implemented? > > Nobody ever implemented it. IIRC the main problem is that under > certain circumstances the packets need to be passed back to > __netif_receive_skb() when queuing in LOCAL_IN, which isn't > possible from the completion handler. Thanks Patrick for your replay. Can you explain why it's not possible to pass packets back? Also, why should packets need to be sent back? Thanks, Kfir ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Verdict with ebtables? 2010-11-14 11:56 ` Kfir Lavi @ 2010-11-15 9:39 ` Patrick McHardy 0 siblings, 0 replies; 4+ messages in thread From: Patrick McHardy @ 2010-11-15 9:39 UTC (permalink / raw) To: Kfir Lavi; +Cc: netfilter-devel On 14.11.2010 12:56, Kfir Lavi wrote: > On Thu, Nov 11, 2010 at 12:48 PM, Patrick McHardy <kaber@trash.net> wrote: >> >> On 11.11.2010 11:05, Kfir Lavi wrote: >>> Hi, >>> It seems to me that its not possible to do a verdict in userspace of >>> ethernet packets, like it is done with nfqueue and iptables. >>> Why it is not implemented? >> >> Nobody ever implemented it. IIRC the main problem is that under >> certain circumstances the packets need to be passed back to >> __netif_receive_skb() when queuing in LOCAL_IN, which isn't >> possible from the completion handler. > > Thanks Patrick for your replay. > Can you explain why it's not possible to pass packets back? Because the completion handler is executed asynchronously, while the bridge receive functions are called directly from __netif_receive_skb(). > Also, why should packets need to be sent back? That's f.i. how the NF_BR_LOCAL_IN handler works for link-local packets. Have a look at br_handle_frame(). ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2010-11-15 9:39 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <AANLkTinCazaFKSXnfGe2e0nnfeRorV7AHcadQaxGvWg+@mail.gmail.com>
2010-11-11 10:05 ` Verdict with ebtables? Kfir Lavi
2010-11-11 10:48 ` Patrick McHardy
2010-11-14 11:56 ` Kfir Lavi
2010-11-15 9:39 ` Patrick McHardy
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).