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. -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
