On Tue, May 13, 2014 at 01:45:35PM +0200, Martin Kraus wrote: > On Mon, May 12, 2014 at 06:35:38PM +0200, Pablo Neira Ayuso wrote: > > > current kernel is 3.13.7. > > > > > > we already hit a bug in the official 3.2 kernel packaged with wheezy where > > > our scan for heartbleed vulnerability would cause conntrackd to kernel panic > > > the router. > > > > Please, provide more information on how to reproduce the problem that > > you're noticing. Thank you. > > regarding the kernel panic on 3.2 a colleague of mine was using nmap with it's > heartbleed plugin > > nmap --script ssl-heartbleed -sT -oX logfile.log 10.0.0.0/20 > > http://nmap.org/nsedoc/scripts/ssl-heartbleed.html > > it took about 30 minutes to trigger the problem. Did you annotate the kernel oops backtrace? Without that information, this is pretty much like looking for the needle in the stack. > regarding the internal cache fill up. we have two routers and some vlans using > one and some vlans using the other router as the default gateway. > > this is the conntrackd config on both routers. > > Sync { > Mode FTFW { > ResendQueueSize 131072 > ACKWindowSize 300 > DisableExternalCache On > } > UDP { > IPv4_address 192.168.100.200 > IPv4_Destination_Address 192.168.100.100 > Port 3780 > Interface eth0 > Checksum on > } > Options { > TCPWindowTracking On > } > } > > General { > Nice -20 > > HashSize 65536 > HashLimit 262144 > > Syslog on > LockFile /var/lock/conntrack.lock > UNIX { > Path /var/run/conntrackd.ctl > Backlog 20 > } > > NetlinkBufferSize 2097152 > NetlinkBufferSizeMaxGrowth 8388608 > NetlinkEventsReliable On > NetlinkOverrunResync Off > > Filter From Kernelspace { > Address Ignore { > IPv4_address 127.0.0.1 # loopback > } > } > } > > We have about 80 users, some of them running window or macs, so there is > plenty of multicasts and broadcasts that fill the conntrack table. some of > these then get stuck in the conntrackd internal cache. We can see the > LAST_ACK tcp states stuck in the internal cache as well, but I think these are > related to TCPWindowTracking On. Did you retry with lastest conntrack-tools version? If so, please collect as much information as you can via all -s options, moreover check the logs. If you didn't retry with lastest, please upgrade. -- 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