Ok, I am ready to be ridiculed and bashed, so here goes... I know this is useless ... and dumb.. and stupid.. and idiotic.. etc.. and I apologize for not knowing everything right away.

I wanted to adjust the established TCP conneciton timeout value, but a seemingly correct entry in sysconf.ctl didn't seem to work, and I didn't like the idea of having to set the /proc/sys/net/ipv4/netfilter/ip_* file through a startup script.

If these configuration files (/proc/sys/net/ipv4/netfilter) would persist across a reboot, there'd be no issue at all, but they seem to be reset at each boot (reconfigured by netfilter?).

So I, still learning the build environment, just added a White Russian RC5 patch to:

./target/linux/linux-2.4/patches/generic

I named it next in line after the pre-existing patch, so it ended up being:

118-netfilter_TCP_EST_TIMEOUT.patch

diff -urN linux-2.4.30.old/net/ipv4/netfilter/ip_conntrack_proto_tcp.c linux-2.4.30.dev/net/ipv4/netfilter/ip_conntrack_proto_tcp.c
--- ../../buildroot-unpacked/build_mipsel/linux/net/ipv4/netfilter/ip_conntrack_proto_tcp.c    2006-06-14 23:38:56.000000000 -0400
+++ linux/net/ipv4/netfilter/ip_conntrack_proto_tcp.c    2006-06-14 23:40:19.000000000 -0400
@@ -51,7 +51,7 @@
 
 unsigned long ip_ct_tcp_timeout_syn_sent =      2 MINS;
 unsigned long ip_ct_tcp_timeout_syn_recv =     60 SECS;
-unsigned long ip_ct_tcp_timeout_established =   5 DAYS;
+unsigned long ip_ct_tcp_timeout_established =   6 HOURS;
 unsigned long ip_ct_tcp_timeout_fin_wait =      2 MINS;
 unsigned long ip_ct_tcp_timeout_close_wait =   60 SECS;
 unsigned long ip_ct_tcp_timeout_last_ack =     30 SECS;

So now I think this works out fine for me.

1.) Oh, goodie. I think I'm getting acquainted with the linux patch system.

2.) Why not reduce the default value of 5 days to something less? I know some established TCP connections could concievably go that long without traffic, but in reality there are probably other 'kills' along the line when a connection has been idle that long. Perhaps 6 hours is too little though, and 1 day is more appropriate. All I know is that my connection table would fill up after a couple days of p2p use since many connections apparently weren't being closed properly.

3.) Is there another way to configure this (other than an 'echo X > /proc/sys/net/ipv4/netfilter/...' at startup)? Why wasn't my sysctl.conf entry working, is it supposed to?

What's your problem with echo'ing to /proc entries?
Re sysctl: enabled in the kernel? Ran sysctl on startup?

You'll have to show us what you did with sysctl so we can tell you why it didn't work. The sysctl values are written at startup; chances are you didn't write a proper sysctl.conf entry.

mbm:
I hope I was doing something wrong with sysctl.conf, but I dunno what. My variables were defined in the way the directory structure is layed out (with /proc/sys as base). I tried serveral variations, that's what led me to conclude it just wasn't working. I noticed in the source code that it seems like it ought to work..

<code>
net.ipv4.netfilter.ip_conntrack_tcp_timeout_established=3600
</code>

stephen:
My problem with echo'ing to the /proc entries is because that seems to be the purpose of sysctl.conf, and it not working made me wonder if netfilter was picking up the changes to the /proc entries. And since the /proc entries weren't persisting across a reboot, I was even further wary that it was actually working. Of course, I could have went to the trouble to find out... but the whole thing seems hackish.

My argument for default to something less than 5 days, or at least allowing for configuring of this in the build would be that most users need support for the rigors of p2p networking more than do 5 day long idle connections. Of course, I understand the rationale for leaving it to the default value, especially since OpenWrt can be built for so many different platforms, including ones with much more resources available.

....

Mostly my whole post is useless.. but I was actually kinda happy to have created my first patch for OpenWrt, even if it doesn't really make any 'real' code changes . Its taken me a while to get up to speed with linux development. mbm confused me and sent me all to hell the other day, before I realized that by 'kernel' he was including kernel mode drivers. I couldn't understand why you would merge JFFS2 into the 'kernel'. To me, the file system drivers aren't part of the 'kernel'. Anyway, until having played with things myself, this jargon barrier makes it hard to be 'told' what is going on .

.....

That sysctl line works perfectly here.

Oh, it works perfectly here too. Did I say it didn't work? my bad ;p.

I don't what the hell has gone on here that prevented my first test from succeeding. This is a new install of WR RC5, but that shouldn't have affected it. I ordered them differently, but that shouldn't matter. I must have made some stupid mistake, and not being certain that sysctl.conf even worked, I did not debug properly.

Whoops. Ok, well that's that, for that. Thanks.

End.

(Last edited by db90h on 16 Jun 2006, 01:02)