On 07.06.2011 16:40, Brad Campbell wrote: > On 07/06/11 21:30, Patrick McHardy wrote: >> 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? > > No, 32 bit Guest OS, but a completely 64 bit userspace on a 64 bit kernel. > > Userspace is current Debian Stable. Kernel is Vanilla and qemu-kvm is > current git > > >>> 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? >> > > It was compiled in. > > With the following table set I was able to reproduce the problem on > 3.0-rc2. Replaced my IP with xxx.xxx.xxx.xxx, but otherwise unmodified Which kernel was the last version without this problem? > root@srv:~# iptables-save > # Generated by iptables-save v1.4.10 on Tue Jun 7 22:11:30 2011 > *filter > :INPUT ACCEPT [978:107619] > :FORWARD ACCEPT [142:7068] > :OUTPUT ACCEPT [1659:291870] > -A INPUT -i ppp0 -m state --state RELATED,ESTABLISHED -j ACCEPT > -A INPUT ! -i ppp0 -m state --state NEW -j ACCEPT > -A INPUT -i ppp0 -j DROP > COMMIT > # Completed on Tue Jun 7 22:11:30 2011 > # Generated by iptables-save v1.4.10 on Tue Jun 7 22:11:30 2011 > *nat > :PREROUTING ACCEPT [813:49170] > :INPUT ACCEPT [91:7090] > :OUTPUT ACCEPT [267:20731] > :POSTROUTING ACCEPT [296:22281] > -A PREROUTING -d xxx.xxx.xxx.xxx/32 ! -i ppp0 -p tcp -m tcp --dport 443 > -j DNAT --to-destination 192.168.253.198 > COMMIT > # Completed on Tue Jun 7 22:11:30 2011 > # Generated by iptables-save v1.4.10 on Tue Jun 7 22:11:30 2011 > *mangle > :PREROUTING ACCEPT [2729:274392] > :INPUT ACCEPT [2508:262976] > :FORWARD ACCEPT [142:7068] > :OUTPUT ACCEPT [1674:293701] > :POSTROUTING ACCEPT [2131:346411] > -A FORWARD -o ppp0 -p tcp -m tcp --tcp-flags SYN,RST SYN -m tcpmss --mss > 1400:1536 -j TCPMSS --clamp-mss-to-pmtu > COMMIT > # Completed on Tue Jun 7 22:11:30 2011 The main suspects would be NAT and TCPMSS. Did you also try whether the crash occurs with only one of these these rules? > I've just compiled out CONFIG_BRIDGE_NETFILTER and can no longer access > the address the way I was doing it, so that's a no-go for me. That's really weird since you're apparently not using any bridge netfilter features. It shouldn't have any effect besides changing at which point ip_tables is invoked. How are your network devices configured (specifically any bridges)? -- 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
