Re: [RFH] bridge: add new target NFQUEUE for ebtables

[Patrick McHardy <kaber@trash.net>]

Am 17.02.2011 14:37, schrieb Pierre Chifflier:
> On 02/17/2011 11:47 AM, Patrick McHardy wrote:
>> Am 16.02.2011 17:57, schrieb Pierre Chifflier:
>>> Hi,
>>>
>>> Thanks for your reply Patrick.
>>> So I did the following:
>>> - rebased on today's nf-next-2.6
>>> - apply only the first patch (which makes afinfo optional)
>>> - revert all other patches
>>> - apply the recent fix on nf_iterate since it was the cause of my oops
>>>
>>> I patched ebtables to use xt_NFQUEUE (using a struct xt_NFQ_info_v1 with
>>> arguments queuenum 1 and queues_total 1), and removed any other change.
>>>
>>> When I add a rule with the NFQUEUE target with ebtables, I almost
>>> immediately get a panic (full backtrace later in this mail).
>>>
>>> What is weird is that I got a NULL skb  in ebt_in_hook (frame 2) while
>>> the skb was not NULL earlier - like if it was stolen by some hook. Any
>>> idea on what could cause that ?
>>
>> The backtrace doesn't seem to be fully accurate. Please also post
>> the full oops output corresponding to the backtrace.
>>
>> Two more questions:
>>
>> - is the bridge device in promiscous mode?
>> - do you have IGMP snooping enabled?
>>
> 
> Here is the most relevant part of the log I could capture on the serial
> port.
> - Bridge device is not in promiscuous mode
> - CONFIG_BRIDGE_ICMP_SNOOPING is not set
> 
> What I do to reproduce the crash:
> - setup the bridge (at this point, everything is fine)
> - load an ebtables rule: ebtables -A FORWARD -j NFQUEUE
> the crash happens immediately when adding the rule.
> 
> If relevant, the code for ebt_NFQUEUE.c is available at
> https://www.wzdftpd.net/downloads/ebt_NFQUEUE.c
> 

Thanks, I'm going to give this a try myself during the weekend.