On 07.06.2011 05:33, Brad Campbell wrote: > On 07/06/11 04:10, Bart De Schuymer wrote: >> Hi Brad, >> >> This has probably nothing to do with ebtables, so please rmmod in case >> it's loaded. >> A few questions I didn't directly see an answer to in the threads I >> scanned... >> I'm assuming you actually use the bridging firewall functionality. So, >> what iptables modules do you use? Can you reduce your iptables rules to >> a core that triggers the bug? >> Or does it get triggered even with an empty set of firewall rules? >> Are you using a stock .35 kernel or is it patched? >> Is this something I can trigger on a poor guy's laptop or does it >> require specialized hardware (I'm catching up on qemu/kvm...)? > > Not specialised hardware as such, I've just not been able to reproduce > it outside of this specific operating scenario. The last similar problem we've had was related to the 32/64 bit compat code. Are you running 32 bit userspace on a 64 bit kernel? > I can't trigger it with empty firewall rules as it relies on a DNAT to > occur. If I try it directly to the internal IP address (as I have to > without netfilter loaded) then of course nothing fails. > > It's a pain in the bum as a fault, but it's one I can easily reproduce > as long as I use the same set of circumstances. > > I'll try using 3.0-rc2 (current git) tonight, and if I can reproduce it > on that then I'll attempt to pare down the IPTABLES rules to a bare > minimum. > > It is nothing to do with ebtables as I don't compile it. I'm not really > sure about "bridging firewall" functionality. I just use a couple of > hand coded bash scripts to set the tables up. >From one of your previous mails: > # CONFIG_BRIDGE_NF_EBTABLES is not set How about CONFIG_BRIDGE_NETFILTER? -- 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
