Solved Weird bug with executing nat start scripts

[Vexira]

i was trying to banish the kernel: nf_conntrack: expectation table full, which appeared again out of nowhere despite me using the nf Contrack scripts of Maverickcdn and RamGuy.
the issue I've discovered is that for some reason the nat start script did not work when executed via SH, using the command cat /proc/sys/net/netfilter/nf_conntrack_expect_max yielded the default result of 150 on my AX88U, even though the log stated it was waiting for nat start to finish, so i decided to reboot, upon the completion of reboot it worked, but then instantly on subsequent runs of cat /proc/sys/net/netfilter/nf_conntrack_expect_max the value had reverted from the experimental value of 750 i set back to 150 the original value, which brings me to the concern that the ntp merlin scripts re direction feature may not be working exactly or the issue only affects the contrack scripts execution.

 

[ColinTaylor]

Post your complete nat-start script. Without seeing it we can't help you.

 

[Vexira]

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

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

/jffs/scripts/ntpmerlin ntpredirect # ntpMerlin

 

[dave14305]

There is an nvram variable ct_expect_max that sets that during a conntrack restart. Never used it, but mine is set to 150.

asuswrt-merlin.ng/release/src/router/rc/common.c at a138e8504381d878ca59342054ba0cb90d168291 · RMerl/asuswrt-merlin.ng

Third party firmware for Asus routers (newer codebase) - RMerl/asuswrt-merlin.ng

github.com

 

[ColinTaylor]

There is an nvram variable ct_expect_max that sets that during a conntrack restart. Never used it, but mine is set to 150.

Yes I was just looking at that. It's new code that was added on 5th March (GPL 386_42095).

 

[ColinTaylor]

My guess is that the first time that code is run the variable doesn't exist so it creates it using the current kernel value. Subsequent runs of setup_conntrack use the nvram value.

So the solution to @Vexira's problem would appear to be to replace
echo 750 > /proc/sys/net/netfilter/nf_conntrack_expect_max
with
nvram set ct_expect_max=750

Note that this only applies to non-HND routers. See post #7.

 

[dave14305]

Note that this only applies to non-HND routers.

I thought this too, but left room for doubt when looking at the make files.

https://github.com/RMerl/asuswrt-merlin.ng/blob/6b60627c8c9c5c0271e956c914afb5277f81f9c4/release/src-rt/Makefile#L181

 

[Vexira]

My guess is that the first time that code is run the variable doesn't exist so it creates it using the current kernel value. Subsequent runs of setup_conntrack use the nvram value.

So the solution to @Vexira's problem would appear to be to replace
echo 750 > /proc/sys/net/netfilter/nf_conntrack_expect_max
with
nvram set ct_expect_max=750

Note that this only applies to non-HND routers.

it works both you and @dave14305 are absolutely brilliant its now sticking 750 actually sticks, thank you guys so much i deeply appreciate it.

The modified script as follows:

#!/bin/sh
# increase nf_conntrack_expect_max
nvram set ct_expect_max=750

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

 

[Vexira]

vexira@RT-AX88U-C528:/tmp/home/root# cat /proc/sys/net/netfilter/nf_conntrack_expect_max
750
vexira@RT-AX88U-C528:/tmp/home/root# cat /proc/sys/net/netfilter/nf_conntrack_expect_max
750
vexira@RT-AX88U-C528:/tmp/home/root# cat /proc/sys/net/netfilter/nf_conntrack_expect_max
750
vexira@RT-AX88U-C528:/tmp/home/root# cat /proc/sys/net/netfilter/nf_conntrack_expect_max
750

that's after a reboot to its holding well now.

 

[dave14305]

I would think you only need to set nvram once outside the script.

nvram set ct_expect_max=750
nvram commit

 

[Vexira]

I would think you only need to set nvram once outside the script.

nvram set ct_expect_max=750
nvram commit

And that would survive a reboot?

 

[dave14305]

And that would survive a reboot?

As long as nvram is non-volatile.

 

[Vexira]

As long as nvram is non-volatile.

Ahh as long as it's in nvram I understand, thank you.

 

[Xrsenal]

Can merlin fix this in the next update?

 

[RMerlin]

This has already been addressed upstream by Asus.

 

[Xrsenal]

This has already been addressed upstream by Asus.

Hey Merlin thanks for replying. I have about 372/300000 - 100 active ;

Would that have triggered the conntrack syslog issue? Everytime I fac reset the FW, gameplay feels great ; Then after a an hour or so, I get those conntrack syslog failures then the game feels like crap... Is it dropped packets or full NAT Table?

I apologize for the random questions ; I did follow the steps above for increasing it to the 750.

Also, could you possibly explain the coding behind the "gaming port"

Others says it doesn't do anything but that's 100% false, Ive done numerous tests and it definitely does something. Exactly what type of qos does it us?

 

[Xrsenal]

and for the conntrack -L result = 21 expectations and for the other conntack -E command, its an endless cycle of connections so idk

 

[Xrsenal]

My log is filled w this?

Should i be concerned or is this normal

 

[RMerlin]

Hey Merlin thanks for replying. I have about 372/300000 - 100 active ;

Tracked connections does not necessarily match the content of the expect table. I don't know the difference, you will have to do some research on it.

Also, could you possibly explain the coding behind the "gaming port"

No idea what it does, sounds like marketing smoke to me.

 

[Vexira]

The gaming port is probably the 2.5gb port with QoS priority