RE: [PATCH net-next] change nfqueue failopen to apply also to receive message buffer in addition to queue size

Much of the issues raised become redundant due to a much simpler solution proposed by Pablo. Still two issues left, proc and potential existing bug in sk filter case. On March 21, 2016 2:23 PM, Florian Westphal wrote: > It looks like a bug -- AFAICS if a sk filter is active on the nfnetlink sk

RE: [PATCH net-next] change nfqueue failopen to apply also to receive message buffer in addition to queue size

On Monday, March 21, 2016 11:36 PM, Pablo Neira Ayuso wrote: > So isn't the more simple patch that I'm attaching achieving what you need? Yes. I applied the patch and it works as expected. Indeed much more simple. I intend to use this patch and would like it to eventually get into the formal

[PATCH net-next] change nfqueue failopen to apply also to receive message buffer in addition to queue size

Signed-off-by: Yigal Reiss --- NOTE: this is a re-send after being bounced by the test robot for a compiler warning. I hope I'm doing the right thing in resubmitting rather than replying to the original message. Recompiled w/o warnings and re-tested. This is follow-up on

[PATCH] change nfqueue fail-open mechanism to apply also to receive message

Signed-off-by: Yigal Reiss --- This is follow-up on http://marc.info/?l=netfilter-devel=145765526817347=2 Existing fail-open mechanism for nfqueue only applies for message that cannot be sent due to queue size (queue_maxlen). It does not apply when the failure is due to

[PATCH] brouted packet identified as PACKET_OTHERHOST blocked by higher protocol

The problem I'm trying to solve is that when packets being sent from one bridged interface to the other are brouted they get dropped by the IP layer. The reason is that the packet being raised has pkt_type of type PACKET_OTHERHOST. The semantics of brouting a packet is that it is sent up to

RE: [PATCH] brouted packet identified as PACKET_OTHERHOST blocked by higher protocol

Florian Westphal [mailto:f...@strlen.de] wrote: Maybe, but if you broute everything you might as well just remove the bridge... I want to be selective. My setup is a home router. So I can have ebtables rules for which traffic to (b)route and which to bridge, based on security/performance

RE: [PATCH] brouted packet identified as PACKET_OTHERHOST blocked by higher protocol

Florian Westphal f...@strlen.de wrote: Yigal Reiss (yreiss) yre...@cisco.com wrote: The problem I'm trying to solve is that when packets being sent from one bridged interface to the other are brouted they get dropped by the IP layer. The reason is that the packet being raised has pkt_type