From mboxrd@z Thu Jan 1 00:00:00 1970 From: Patrick McHardy Subject: Re: [RFH] bridge: add new target NFQUEUE for ebtables Date: Fri, 18 Feb 2011 14:42:23 +0100 Message-ID: <4D5E773F.7020804@trash.net> References: <4D49E1E0.50304@trash.net> <1296743540-8148-4-git-send-email-chifflier@edenwall.com> <4D4BFE3C.3060407@trash.net> <4D4C01B2.2030605@edenwall.com> <4D4C020A.9000909@trash.net> <4D5104C4.3010105@edenwall.com> <4D59C047.5050404@trash.net> <4D5C01E5.8000302@wzdftpd.net> <4D5CFCDD.10007@trash.net> <4D5D2497.5020908@wzdftpd.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: netfilter-devel@vger.kernel.org To: Pierre Chifflier Return-path: Received: from stinky.trash.net ([213.144.137.162]:44190 "EHLO stinky.trash.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751707Ab1BRNm1 (ORCPT ); Fri, 18 Feb 2011 08:42:27 -0500 In-Reply-To: <4D5D2497.5020908@wzdftpd.net> Sender: netfilter-devel-owner@vger.kernel.org List-ID: 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.