Bug #10861
closed
net.pf.request_maxcount value set in loader.conf not respected on latest snapshot
Added by Jim Pingle about 4 years ago.
Updated about 4 years ago.
Category:
Operating System
Description
The value of net.pf.request_maxcount is 65535 at boot on the latest 2.5.0 snapshot, despite a higher value being set in loader.conf:
: pkg info -x pfSense-2.5.0
pfSense-2.5.0.a.20200902.0050
pfSense-kernel-pfSense-2.5.0.a.20200902.0050
: sysctl net.pf.request_maxcount
net.pf.request_maxcount: 65535
: grep net.pf.request_maxcount /boot/loader.conf
net.pf.request_maxcount="2000000"
But the value can be set at runtime:
: sysctl net.pf.request_maxcount=2000000
net.pf.request_maxcount: 65535 -> 2000000
: sysctl net.pf.request_maxcount
net.pf.request_maxcount: 2000000
See #10254 for some related history
Does it have something to do with r364456?
Reproduced on my firewall running latest dev snapshot. Encountered
There were error(s) loading the rules: /tmp/rules.debug:24: cannot define table bogonsv6: too many elements. - The line in question reads [24]: table <bogonsv6> persist file "/etc/bogonsv6" after upgrading, noticed that /etc/bogonsv6 is currently 113412 lines. added a tunable for net.pf.request_maxcount and set it to 200000
I can confirm that running the command fixes the filter reload symptom, though that fix doesn't persist through reboots:
sysctl net.pf.request_maxcount=2000000
Marcos Mendoza wrote:
I can confirm that running the command fixes the filter reload symptom, though that fix doesn't persist through reboots:
sysctl net.pf.request_maxcount=2000000
I added the tunable in accordance with Michael Spears prior post on the matter and it persists through reboots. Please note the last line of his item as follows: "added a tunable for net.pf.request_maxcount and set it to 200000" which is what I have done as follows:
"System > Advanced > System Tunables > New" then fill in the blanks and save.
Ted Quade
Thanks Ted, I missed the part about adding it as a tunnable.
- Status changed from New to In Progress
- Assignee set to Jim Pingle
- Status changed from In Progress to Feedback
- % Done changed from 0 to 100
- % Done changed from 100 to 0
With the fix I checked in, the value is tied to the max table size, as it was before. The value is set at boot time, and updates when the max table size is changed.
The value can also be overridden by a system tunable, provided that the new value is larger than the max table size. If a tunable change is not reflected, it's likely because it was set too small.
It should be in snapshots later today/tomorrow.
- % Done changed from 0 to 100
- Status changed from Feedback to Resolved
I've upgraded a few systems and they all came through OK. Had the wrong value before upgrade and expected value after.
Also available in: Atom
PDF
Updated by 
Updated by 
Updated by Michael Spears 
Updated by 
Updated by