nf_conntrack: expectation table full and other log oddities

[Vexira]

Was kinda wondering if the tcp timeout established seconds, in this case 1800, should be matched to the 'tcp timeout established' in the TCP/IP table in Tools>Other Settings. In my case 2400, which is the default

echo 1800 > /proc/sys/net/netfilter/nf_conntrack_tcp_timeout_established
service restart_conntrack

actually since you brought it up ill test it also, see what happens.

 

[Vexira]

@randomName so far looks good looks to me safe to change to 2400.

 

[Vexira]

I aslo sent a message to the script writer asking about it just waiting for his reply.

 

[randomName]

I aslo sent a message to the script writer asking about it just waiting for his reply.

Since I recently installed the beta firmware I haven't gotten around to using Fullcone. My firmware started corrupting and I've reinstalled several times since so I'm taking things slow. I just installed Skynet again using my USB2.0 port instead, this time. Something was messed up making me completely drop from my ISP.

If I were to guess I'd say both would best be equal. Let us know what he ends up saying,

Thanks!

 

[Vexira]

Since I recently installed the beta firmware I haven't gotten around to using Fullcone. My firmware started corrupting and I've reinstalled several times since so I'm taking things slow. I just installed Skynet again using my USB2.0 port instead, this time. Something was messed up making me completely drop from my ISP.

If I were to guess I'd say both would best be equal. Let us know what he ends up saying,

Thanks!

I definitely will bkee you updated, it seem that this is to some degree better, when st to 2400, also check the USB drive that you are using might possibly be the issue.

 

[Eric Lieb]

I have an AC86 running the latest firmware and started having this problem that was causing my chromebook to constantly switch off from the router to teh AI mesh node and back. Ran this and seems to have fixed the issue. created a file in /jffs/scripts called nat_start and then ran a chmod +x nat_start ... Just wanted to make sure that is the proper way to get it to run on boot.

 

[Maverickcdn]

I have an AC86 running the latest firmware and started having this problem that was causing my chromebook to constantly switch off from the router to teh AI mesh node and back. Ran this and seems to have fixed the issue. created a file in /jffs/scripts called nat_start and then ran a chmod +x nat_start ... Just wanted to make sure that is the proper way to get it to run on boot.

Yes they were still persistent for me as well on 384.15

They are unrelated to any wifi issues, use the Wireless log and the wlceventd messages in Syslog to help find the config that works the best for you, I have to run with just about everything disabled in wireless advanced to keep my old N devices happy, but still have a tablet that disconnects on the hour every hour so likely just the device itself.

#!/bin/sh
# increase nf_conntrack_expect_max
echo 352 > /proc/sys/net/netfilter/nf_conntrack_expect_max

logger -t conntrackscript "Value 352 written to nf_conntrack_expect_max, restarting conntrack"
sleep 2
service restart_conntrack

Ive been running this since I started this thread in nat-start and have had zero issues
It writes to your syslog so you can see it ran, in nat-start it'll be re-written anytime the router clears it back to the default 52, so yes thats where you want it to be

And... its 'nat-start' NOT 'nat_start' and chmod a+rx

 

[Eric Lieb]

Yes they were still persistent for me as well on 384.15

They are unrelated to any wifi issues, use the Wireless log and the wlceventd messages in Syslog to help find the config that works the best for you, I have to run with just about everything disabled in wireless advanced to keep my old N devices happy, but still have a tablet that disconnects on the hour every hour so likely just the device itself.

#!/bin/sh
# increase nf_conntrack_expect_max
echo 352 > /proc/sys/net/netfilter/nf_conntrack_expect_max

logger -t conntrackscript "Value 352 written to nf_conntrack_expect_max, restarting conntrack"
sleep 2
service restart_conntrack

Ive been running this since I started this thread in nat-start and have had zero issues
It writes to your syslog so you can see it ran, in nat-start it'll be re-written anytime the router clears it back to the default 52, so yes thats where you want it to be

And... its 'nat-start' NOT 'nat_start' and chmod a+rx

Sorry I had it as nat-start but typed it wrong in the forum. Any reason to use 352 instead of 4096?

Turns out the wifi reconnect issue i was having was from having the channel set to Auto. Apparently the router kept changing the channel which was causing the clients to momentarily lose connection.

 

[Maverickcdn]

4096 seems largely excessive. I only quoted that number as being seen in my research being used on other manufacturers.

All the nf_conntrack settings are related and calculated from one another. RMerlin recommended 128 as likely safe, I was still getting sparse messages so I just went with 352 for testing, never noticed any issues so stuck with it.

If you have time I recommend incrementally raising it till you stop seeing the messages then go with that. Or try 128. But I personally wouldn't set it to 4096 to save potentially breaking nf_conntrack

 

[Vexira]

4096 seems largely excessive. I only quoted that number as being seen in my research being used on other manufacturers.

All the nf_conntrack settings are related and calculated from one another. RMerlin recommended 128 as likely safe, I was still getting sparse messages so I just went with 352 for testing, never noticed any issues so stuck with it.

If you have time I recommend incrementally raising it till you stop seeing the messages then go with that. Or try 128. But I personally wouldn't set it to 4096 to save potentially breaking nf_conntrack

Odd why not 256 if that even makes a difference?

 

[Vexira]

Also I wish this script was baked into the firmware or Asus would hurry up and fix the issue.

 

[Maverickcdn]

Odd why not 256 if that even makes a difference?

I think as long as its an even integer anything will go in, being a multiple of 8 isnt a requirement

Also I wish this script was baked into the firmware or Asus would hurry up and fix the issue.

Send them a support message about it.

The one issue with the script is you are changing a value that is supposed to be calculated based on other nf_conntrack values for other things, for Asus to fix it they may have to adjust multiple other values to maintain the configuration properly.

 

[Maverickcdn]

Looking at the documentation again quickly, it doesnt even need to be an even number, minimum value is 1

 

[Vexira]

I think as long as its an even integer anything will go in, being a multiple of 8 isnt a requirement



Send them a support message about it.

The one issue with the script is you are changing a value that is supposed to be calculated based on other nf_conntrack values for other things, for Asus to fix it they may have to adjust multiple other values to maintain the configuration properly.

I'm still waiting on my last support request to be answered.

 

[Vexira]

I think as long as its an even integer anything will go in, being a multiple of 8 isnt a requirement



Send them a support message about it.

The one issue with the script is you are changing a value that is supposed to be calculated based on other nf_conntrack values for other things, for Asus to fix it they may have to adjust multiple other values to maintain the configuration properly.

Question which script is better to use yours or ram guys?

 

[Maverickcdn]

Question which script is better to use yours or ram guys?

Personally Id stick with mine, his appears to change a multitude of other values I dont see necessary to change to resolve the issue of the log notifications.

As mentioned, this script merely prevents the expect table from filling and generating log entries, and no one has chimed in to say they've noticed any performance issues by simply changing the nf_conntrack_expect_max value to a higher number.... changing anything else could introduce an issue.

 

[Vexira]

Personally Id stick with mine, his appears to change a multitude of other values I dont see necessary to change to resolve the issue of the log notifications.

As mentioned, this script merely prevents the expect table from filling and generating log entries, and no one has chimed in to say they've noticed any performance issues by simply changing the nf_conntrack_expect_max value to a higher number.... changing anything else could introduce an issue.

It works perfectly 358 seems to the the sweet spot.

 

[Vexira]

unfortunately its back and even 384 doesn't work not sure if its because im running skynet, i might test 512, since in theory 256 should be fine but it still gives me the message.

 

[Maverickcdn]

Ive been running 240 for quite awhile now and havent seen the messages reappear.

Next time you reflash, it might be worth connecting devices one by one to find out which one of your clients is causing the issue, it could be something misconfigured on a client that is causing the router to have such a large number of expected connections.

Either this issue doesnt affect many users (likely) or people arent posting about this issue, but it remains its a symptom of network configuration/devices and not a fault of the firmware per se

 

[Vexira]

Ive been running 240 for quite awhile now and havent seen the messages reappear.

Next time you reflash, it might be worth connecting devices one by one to find out which one of your clients is causing the issue, it could be something misconfigured on a client that is causing the router to have such a large number of expected connections.

Either this issue doesn't affect many users (likely) or people arent posting about this issue, but it remains its a symptom of network configuration/devices and not a fault of the firmware per se

im starting to think its something to do with the firmware are not not many people on the forums here have really noticed it, i suspect some of the device disconnections are related to it it should be a part of standard troubleshooting to check for it if the router is hnd based, whilst its entirely possible its device related, the issue seems to correlate with full cone nat, so that would be the first place to look.

i was using 512 with no errors but ive reset and re installed all the scripts i was using to see if it works now ill buy a new flash drive in case that the issue.