Project

General

Profile

Actions
Copy link

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.

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

100%

Estimated time:
Plus Target Version:
Release Notes:
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

Actions
Copy link
 #1

Updated by Steve Harrington about 4 years ago

Does it have something to do with r364456?

Actions
Copy link
 #2

Updated by Jim Pingle about 4 years ago

Most likely

Actions
Copy link
 #3

Updated by Michael Spears about 4 years 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

Actions
Copy link
 #4

Updated by Marcos M about 4 years 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

Actions
Copy link
 #5

Updated by Ted Quade about 4 years 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

Actions
Copy link
 #6

Updated by Marcos M about 4 years ago

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

Actions
Copy link
 #7

Updated by Jim Pingle about 4 years ago

  • Status changed from New to In Progress
  • Assignee set to Jim Pingle
Actions
Copy link
 #8

Updated by Jim Pingle about 4 years ago

  • Status changed from In Progress to Feedback
  • % Done changed from 0 to 100
Actions
Copy link
 #9

Updated by Jim Pingle about 4 years 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.

Actions
Copy link
 #10

Updated by Jim Pingle about 4 years ago

  • % Done changed from 0 to 100
Actions
Copy link
 #11

Updated by Jim Pingle about 4 years 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.

Actions
Copy link

Also available in: Atom PDF