On Sun, Jan 28, 2007 at 03:57:48PM +0100, Ralph Passgang wrote: > I think it could be the conntrack table.
I think that, too. > On my asus WL500gP conntrack gets loaded with this output: > -> ip_conntrack version 2.1 (5953 buckets, 5953 max) - 360 bytes per conntrack > > This means that it can handle 5953 connections, and after this the table is > full and new connections will be dropped. This "max" value can be manipulated > via /proc/sys/net/ipv4/ip_conntrack_max, but be aware that you need some free > memory if you increase the amount of connections that conntrack can handle. > You might try to double the amount of connections, but please don't try to > get a million connections working on a embedded device :) I'd (also) recommend setting the timeout lower, because the default is quite high (5 days). Look at /proc/sys/net/ipv4/netfilter/*, especially ip_conntrack_tcp_timeout_established. I guess 3600 (one hour) solves this problem even if you do not increase the ip_conntrack_max value. Unfortunatelly, P2P tends to leave a lot of hanging (not properly closed) connections over, and having them remembered for 5 days might not be a good idea. Maybe we should even make this an menuconfig/wib option, otherwise a lot of people will encounter stalled routers while using P2P (which is quite common theese days). A too low value might violate TCP specs, though ... i don't know them. Bye, Lothar _______________________________________________ freewrt-users mailing list [email protected] https://www.freewrt.org/lists/listinfo/freewrt-users
