James Harper wrote:
and I suspect that some connections are timing out (or being selected for purging from the connection tracking due to other more-active connections).
So test that hypothesis? Use conntrack(8) and/or the various status files in /proc and /sys.
but certainly active connections are disappearing from /proc/net/ip_conntrack (but then they reappear again...)
That's a good enough test.
Any other suggestion appreciated too. The WRT54GL router will be replaced before too long with something with a lot more memory which should resolve those problems but I need an interim solution.
I don't see why "more RAM" would fix this unless you've already increase the conntrack table limit to the physical limits of your RAM. IME any site running off a WRT54GL will not even exceed the default conntrack table size unless you're doing something pathological.
ip_conntrack_max was defaulting to around 5500 (a default based on 16MB memory I guess).
Hm; it hadn't occurred to me that it might be based on RAM size. I had assumed that was simply a hard-coded default in the kernel. On an Ubuntu 10.04 x86_64 router with 3½GB of RAM it's 64k. On an OpenWRT backfire / TP-1043ND (32MB volatile RAM) it's 16k.
That might seem high but this router runs at a library with 4 staff windows PC's, 4 public access windows PC's, and sometimes a high number of public access wireless devices
Shrug. For comparison, I currently have 46 active hosts behind my router and conntrack -C reports 2149 connections.
and I've since dropped the limit to 1024 as it's crashing regularly which I think is due to running out of memory.
OOM is not an unreasonable assumption, but I'm not convinced a 5k conntrack table would be enough to tip it over the edge. I defer to your evidence if you have hard numbers to the contrary.