TCP Timeout: Established and MAX

[RMerlin]

One question remains. The "5 day" thing could easily drive conntrack into the worse scenario.

And this was already addressed by Asus in recent betas.

 

[Calisro]

hmm. I don't buy that explanation. 300,000 tracked connections will average 74 links per bucket in the hash table. The org that WROTE conntrack recommends 4-8 MAX because when it starts to go higher than that, things CRAWL to a halt even on faster machines with faster memory/processors. These are tiny machines. It makes no sense to increase this to 300k just to have the router slow to a crawl after 32-64k so that they can say that technically it can 'handle' 300,000 active connections. If handling means that it can process them so slowly that a user would be better off carrying the data on a floppy disk from point a to point b, then sure.

Having 300,000 connections is asking for trouble. Having 300,000 connections along with a 4k hash is furthering that trouble. The "5 day" thing I am not so bothered by if the hash and max connections was set properly but I will still change it to a sane number as I can't think of a single use case for a 5 day value in my environment.

My ask would be that if Asus wants to stick to this default, at least let a sane user change it to a reasonable number rather than enforcing that a user must have 300k as a max. I wonder if asus thought about how easily it would be to DOS the router with 300k.

 

[Calisro]

However, it will still be functional.

If a dump truck can drive at 1MPH when carrying its heaviest load, then is it still 'functioning'? hahaha.

 

[john9527]

Just to add fuel to the fire....the kernel code sets the max connections to 4X the hashsize. On my 68R, ct_hashsize=3991, so ct_max=15964. This value is then overridden by the 300000 number during the factory reset.

 

[kvic]

@Calisro I think your concern is valid.

Haven't tested it in my setup. But worth giving it a try..

echo 12000 > /proc/sys/net/ipv4/netfilter/ip_conntrack_max

 

[john9527]

You can also change the value by manually setting the nvram var...

nvram set ct_max=value
service restart_conntrack

 

[kvic]

@john9527 Your way also has "Other settings" show the new value. Nice

 

[Calisro]

yes, all of these are possible. I'm actually doing John's way already. The GUI should really allow this, however... Right now if you change it hte GUI, it just keeps it at whatever ct_max is set for.....

 

[john9527]

The GUI should really allow this, however...

As Merlin said, it's a bug....I'm sure he will fix it for the next release (the ct_max var got dropped from defaults.c where it needs to be declared to be modified by the gui)

 

[Calisro]

As Merlin said, it's a bug....I'm sure he will fix it for the next release (the ct_max var got dropped from defaults.c where it needs to be declared to be modified by the gui)

ah. I mis-read that part.

 

[john9527]

One more thing just in case you weren't aware...the adjacent Sysinfo page shows the total and active connection counts in the Network section if you want to monitor it.

 

[RMerlin]

As Merlin said, it's a bug....I'm sure he will fix it for the next release (the ct_max var got dropped from defaults.c where it needs to be declared to be modified by the gui)

Asus removed that nvram value with GPL 374_5047, probably because their intention was to manually set it to a different value based on the router model. Since all the models I support would default to 300000 anyway, I've readded the nvram setting, and also set its default (globally) to 300000. It should once again be user-editable on the Other Settings page.

 

[Calisro]

Thanks. Is it also possible to make the hash size configurable? I don't mean necessarily by GUI. This is what I am finding. If I change the hash size to say 8192 and I restart conntrack for the setting to take effect, it changes it back to its 4096:

rt-ac68u:/jffs/scripts# echo "8192"  > /sys/module/nf_conntrack/parameters/hashsize
rt-ac68u:/jffs/scripts# cat /proc/sys/net/ipv4/netfilter/ip_conntrack_buckets
8192
rt-ac68u:/jffs/scripts# service restart_conntrack
Done.
rt-ac68u:/jffs/scripts# cat /proc/sys/net/ipv4/netfilter/ip_conntrack_buckets
4096

EDIT: May not be required. I believe HASH size is dynamic. As long as I don't restart conntrack that is. Still feels hacky though because I don't know when conntrack will restart.

 

[john9527]

Is it also possible to make the hash size configurable?

Can't try it right now, but try setting hashsize via nvram as well before restarting conntrack...

nvram set ct_hashsize=value

 

[Calisro]

EDIT: It worked. Disregard this post:
That would be ideal but did not work. thanks for the suggestion.

rt-ac68u:/jffs/scripts# nvram set ct_hashsize=4000
rt-ac68u:/jffs/scripts# nvram commit
rt-ac68u:/jffs/scripts# service restart_conntrack

Done.
rt-ac68u:/jffs/scripts# cat /sys/module/nf_conntrack/parameters/hashsize
4096

 

[Calisro]

Wait, it did work? Beautiful?

rt-ac68u:/jffs/scripts# nvram show | grep hash
size: 52515 bytes (13021 left)
ct_hashsize=4096
rt-ac68u:/jffs/scripts# nvram set ct_hashsize=8192
rt-ac68u:/jffs/scripts# service restart_conntrack

Done.
rt-ac68u:/jffs/scripts# nvram show | grep hash
size: 52515 bytes (13021 left)
ct_hashsize=8192
rt-ac68u:/jffs/scripts# service restart_conntrack

Done.
rt-ac68u:/jffs/scripts# cat /sys/module/nf_conntrack/parameters/hashsize
8192

EDIT:
And it appears to not get overriden with the GUI when you save new timeouts. Which is great. thx!!

rt-ac68u:/jffs/scripts# nvram show | grep ^ct_
ct_max=65536
size: 52516 bytes (13020 left)
ct_timeout=600 30
ct_tcp_timeout=0 7200 60 30 120 120 20 60 30 0
ct_hashsize=16384
ct_udp_timeout=20 300

 

[Dragon]

Just to dig thread up, I've just installed latest merlin firmware, and the tcp timeout values set in the kernel seem to bear no relationship at all to to the gui/
ct_tcp_timeout. I'm getting
cat /proc/sys/net/ipv4/tcp_keepalive_time = 1800 gui is set to 43200, other values seem to not match, either.

Any ideas? this seems weird as it's not the 'default' value as far as I can tell either.

This is with an AC3200

edit: realised I think I'm looking at the wrong value,
cat /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_established is showing correctly.

 

[kvic]

edit: realised I think I'm looking at the wrong value,
cat /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_established is showing correctly.

That's right or the global one here: /proc/sys/net/netfilter/nf_conntrack_tcp_timeout_established

I believe most of those values on Other Settings page are referring to conntrack module of Netfilter rather than TCP/IP protocol itself. I think @Calisro would be able to shed more light on this. We haven't seen him for a long while..

 

[Dragon]

That's right or the global one here: /proc/sys/net/netfilter/nf_conntrack_tcp_timeout_established

I believe most of those values on Other Settings page are referring to conntrack module of Netfilter rather than TCP/IP protocol itself. I think @Calisro would be able to shed more light on this. We haven't seen him for a long while..

Indeed. I'm basically scratching my head over why I seem to keep having ssl telnet sessions dying and having their disconnect acknowledged two hours after last data transmission that was received. It was working fine for multi hour connection idles on my last router, so I'm presuming it's something in the tcp settings of my new asus that's different. And from previous experience it should just be tcp timeout established.. but this doesn't seem to have completely eliminated issue.