Project

General

Profile

Bug #10861

net.pf.request_maxcount value set in loader.conf not respected on latest snapshot

Added by Jim Pingle about 2 months ago. Updated about 1 month ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
Operating System
Target version:
Start date:
09/02/2020
Due date:
% Done:

100%

Estimated time:
Affected Version:
2.5.0
Affected Architecture:

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

Associated revisions

Revision 8f4b8ff2 (diff)
Added by Jim Pingle about 1 month ago

Handle net.pf.request_maxcount via sysctl. Fixes #10861

History

#1 Updated by Steve Harrington about 2 months ago

Does it have something to do with r364456?

#2 Updated by Jim Pingle about 2 months ago

Most likely

#3 Updated by Michael Spears about 2 months ago

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

#4 Updated by Marcos Mendoza about 2 months ago

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

#5 Updated by Ted Quade about 2 months ago

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

#6 Updated by Marcos Mendoza about 2 months ago

Thanks Ted, I missed the part about adding it as a tunnable.

#7 Updated by Jim Pingle about 1 month ago

  • Status changed from New to In Progress
  • Assignee set to Jim Pingle

#8 Updated by Jim Pingle about 1 month ago

  • Status changed from In Progress to Feedback
  • % Done changed from 0 to 100

#9 Updated by Jim Pingle about 1 month ago

  • % 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.

#10 Updated by Jim Pingle about 1 month ago

  • % Done changed from 0 to 100

#11 Updated by Jim Pingle about 1 month ago

  • 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