nf_conntrack: expectation table full and other log oddities

[Maverickcdn]

have you noticed this happening when 5ghz drops clients?

I have serious issues with 5G clients dropping connection, especially when starting a streamed video. But havent correlated anything to conntrack_max issues myself. I notice it gets induced by my ethernet clients as much as my wifi ones.

352 is the highest value? I still start to get the "Apr 27 12:37:06 kernel: nf_conntrack: expectation table full" messages in the system log even with the nf_conntrack_expect_max set to 352 after about 12 hours+

I have tried to limit the maximum amount of connections allowed on my torrentserver down from unlimited to 1000 but it doesn't seem to help much. Are these messages something that one should really care / worry about? What effect does this actually have on network performance and stability?

352 is just a random number I tried out in the beginning. You could likely try 1352 and not 'brick' anything. Just take a backup of your router settings before experimenting changing the conntrack_max.

As I mentioned, other manufacturers vary wildly in their values.... Ive seen specs on some consumer Ubiquiti Edge routers that have their conntrack_max @ 4096

Id recommend maybe trying to disconnect your torrent server and see if the messages persist, then from there you can confirm it is the culprit and adjust router values and torrent settings till you can suppress the messages

For me, I only did this to have the logs cleaner, Ive never noticed any connection issues at default or my altered values.

 

[RamGuy]

Okay, I will just try with larger values, changed my script to;

#!/bin/sh
# Purpose: Increase nf_conntrack_expect_max to maximum value
# Author: RamGuy
# ------------------------------------------------------------
echo 4096 > /proc/sys/net/netfilter/nf_conntrack_expect_max
echo 300000 > /proc/sys/net/netfilter/nf_conntrack_max
echo 120 > /proc/sys/net/netfilter/nf_conntrack_generic_timeout
echo 1800 > /proc/sys/net/netfilter/nf_conntrack_tcp_timeout_established
service restart_conntrack

 

[lilstone87]

Well since I added the AX88U as my main router last friday, my router log gets spammed filled with the these two errors.

nf_conntrack: Expectation table full
kernel: net_ratelimit: callbacks suppressed

I wanted to use "WAN Aggregation" feature on my AX88U, however this issue becomes really bad when enabled. I was using a RT-AC3100 before, with my same home setup, and this wasn't an issue. So I don't know what kind of "Values" are set on it, but for me at least, it seemed to work fine on that router.

So at this point... I'm honestly annoyed with this spam filling my router log, and I would love to change whatever is mentioned in this thread to settle this down. However I currently don't know how to go about doing this. To be honest, I would love to create a script if possible, and have this modified on boot. So if a router reboot is needed, this change will re-apply itself. So I'm all ears on trying to get something to work for myself, as it seems this will be an issue, till Asus decides this setting needs to be changed. Which we all know that might be awhile, if ever.

 

[lilstone87]

Well it has been almost 12 hours since I used the code @RamGuy posted above. No signs of any router related issue, and my router log has been clean of this error since I used the code he posted above. So I have zero clue as to why Asus would decide it's smart to lower this setting on a newer, and better overall router. But they did... as I didn't have this issue on my RT-AC3100 I used as my main router, before replacing it with the AX88U. Here's my router log since I applied the change close to 12 hours ago.

May  9 23:40:50 dropbear[5625]: Exit (***): Exited normally
May 10 02:45:02 dnsmasq-dhcp[1085]: DHCPREQUEST(br0) 192.168.1.22 
May 10 02:45:02 dnsmasq-dhcp[1085]: DHCPACK(br0) 192.168.1.22 
May 10 03:20:27 dnsmasq-dhcp[1085]: DHCPREQUEST(br0) 192.168.1.157 
May 10 03:20:27 dnsmasq-dhcp[1085]: DHCPACK(br0) 192.168.1.157
May 10 03:30:00 adaptive QOS: Scheduled Persistence Check -> No modifications necessary
May 10 03:54:16 dnsmasq-dhcp[1085]: DHCPREQUEST(br0) 192.168.1.89 
May 10 03:54:16 dnsmasq-dhcp[1085]: DHCPACK(br0) 192.168.1.89 
May 10 04:12:04 dnsmasq-dhcp[1085]: DHCPREQUEST(br0) 192.168.1.94 
May 10 04:12:04 dnsmasq-dhcp[1085]: DHCPACK(br0) 192.168.1.94 
May 10 04:13:07 dnsmasq-dhcp[1085]: DHCPREQUEST(br0) 192.168.1.46 
May 10 04:13:07 dnsmasq-dhcp[1085]: DHCPACK(br0) 192.168.1.46 
May 10 04:22:13 dnsmasq-dhcp[1085]: DHCPREQUEST(br0) 192.168.1.213 
May 10 04:22:13 dnsmasq-dhcp[1085]: DHCPACK(br0) 192.168.1.213 
May 10 04:22:20 dnsmasq-dhcp[1085]: DHCPREQUEST(br0) 192.168.1.219 
May 10 04:22:20 dnsmasq-dhcp[1085]: DHCPACK(br0) 192.168.1.219 
May 10 04:38:58 dnsmasq-dhcp[1085]: DHCPREQUEST(br0) 192.168.1.201 
May 10 04:38:58 dnsmasq-dhcp[1085]: DHCPACK(br0) 192.168.1.201 
May 10 04:39:59 dnsmasq-dhcp[1085]: DHCPREQUEST(br0) 192.168.1.74 
May 10 04:39:59 dnsmasq-dhcp[1085]: DHCPACK(br0) 192.168.1.74 
May 10 06:56:25 dnsmasq-dhcp[1085]: DHCPDISCOVER(br0) 
May 10 06:56:25 dnsmasq-dhcp[1085]: DHCPOFFER(br0) 192.168.1.67
May 10 06:56:25 dnsmasq-dhcp[1085]: DHCPREQUEST(br0) 192.168.1.67 
May 10 06:56:25 dnsmasq-dhcp[1085]: DHCPACK(br0) 192.168.1.67 
May 10 07:29:01 dnsmasq-dhcp[1085]: DHCPREQUEST(br0) 192.168.1.153 
May 10 07:29:01 dnsmasq-dhcp[1085]: DHCPACK(br0) 192.168.1.153 
May 10 08:20:02 dnsmasq-dhcp[1085]: DHCPREQUEST(br0) 192.168.1.103 
May 10 08:20:02 dnsmasq-dhcp[1085]: DHCPACK(br0) 192.168.1.103 
May 10 11:06:48 dnsmasq-dhcp[1085]: DHCPREQUEST(br0) 192.168.1.199 
May 10 11:06:48 dnsmasq-dhcp[1085]: DHCPACK(br0) 192.168.1.199

 

[Vexira]

Does the script still work or is it not worth using?

 

[Vexira]

So far the script is working I wonder if it fixed the htb errors form QoS.

 

[randomName]

Ramguy's script is working?

I just had to reinitialize my router (384.13) and I'm now getting these in my log. I did change a few things like I switched to Fullcone NAT, and reinstalled Skynet and FreshJR

 

[Vexira]

It is I'm using it at the moment I reckon I should be pinned.

 

[randomName]

Since this is beyond me I'll ask before I run what I copied. Is this the correct script to run in putty?

"echo 4096 > /proc/sys/net/netfilter/nf_conntrack_expect_max
echo 300000 > /proc/sys/net/netfilter/nf_conntrack_max
echo 120 > /proc/sys/net/netfilter/nf_conntrack_generic_timeout
echo 1800 > /proc/sys/net/netfilter/nf_conntrack_tcp_timeout_established
service restart_conntrack"

Is that what I copy and paste? Just don't want to brick my router..

 

[Vexira]

Since this is beyond me I'll ask before I run what I copied. Is this the correct script to run in putty?

"echo 4096 > /proc/sys/net/netfilter/nf_conntrack_expect_max
echo 300000 > /proc/sys/net/netfilter/nf_conntrack_max
echo 120 > /proc/sys/net/netfilter/nf_conntrack_generic_timeout
echo 1800 > /proc/sys/net/netfilter/nf_conntrack_tcp_timeout_established
service restart_conntrack"

Is that what I copy and paste? Just don't want to brick my router..

It won't brick your router I ran win SCP logged in and created a new Nat start script then copied and pasted the script code into it, I can help if needed be.

 

[randomName]

It won't brick your router I ran win SCP logged in and created a new Nat start script then copied and pasted the script code into it, I can help if needed be.

Sure, that might be interesting to learn. Otherwise I can just copy and paste that right into putty and it should work, right?

EDIT: Kinda curious why it just started appearing for me.

 

[Vexira]

Sure, that might be interesting to learn. Otherwise I can just copy and paste that right into putty and it should work, right?

EDIT: Kinda curious why it just started appearing for me.

Well in PuTTY you navigate to the jfs scrips folder you should see the fresh jr script there, if you do you are in the right spot, right click new script Nat start then copy and paste the code.

 

[randomName]

Well in PuTTY you navigate to the jfs scrips folder you should see the fresh jr script there, if you do you are in the right spot, right click new script Nat start then copy and paste the code.

I'm not sure how to get to that folder. I've never navigated my router's folders with putty besides just following directions with Skynet and FreshJR. I will take a guess at it and to simply get to FreshJR it's just "/jffs/scripts/FreshJR_QOS" ?

 

[Vexira]

I'm not sure how to get to that folder. I've never navigated my router's folders with putty besides just following directions with Skynet and FreshJR. I will take a guess at it and to simply get to FreshJR it's just "/jffs/scripts/FreshJR_QOS" ?

It's jffs/scripts you might have navigate to the root directory

 

[randomName]

It's jffs/scripts you might have navigate to the root directory

No it needs to have the forward slash, I just tried it. "/jffs/scripts" While doing so the message "Permission denied" came up. What's up with that?

Side note: typing "jffs/scripts" returns "not found"

 

[Vexira]

No it needs to have the forward slash, I just tried it. "/jffs/scripts" While doing so the message "Permission denied" came up. What's up with that?

Side note: typing "jffs/scripts" returns "not found"

You needed to navigate there manually, rather than using an address

I think it's root or jfs then scripts, I'll check later on when I get home

 

[randomName]

You needed to navigate there manually, rather than using an address

I think it's root or jfs then scripts, I'll check later on when I get home

I completely don't understand what to do.

 

[Vexira]

I completely don't understand what to do.

So you want to find the jffs folder first, with winscp, then in jfs you look for the scripts folder, after that you should see a folder call scripts in that folder right click and in that menu look for new script option then make one call it nat-start then open it then copy and paste the script code into it then hit save in all editors.

If you get stuck pm me and I'll help you with it if you need me to I can do it via team viewer and a Skype call.

 

[randomName]

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

 

[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

You could test it by adjusting it see if it make a difference the. Set it back after.