I think this issue has been solved:
- issue was errors similar to:
---
[ There were error(s) loading the rules: pfctl: DIOCADDRULE: Invalid argument -
The line in question reads [0]: ]
---
and/or an error indicating that it can't allocate memory (but there's over 50%
of the memory reported as being available via the dashboard widget) -- this is
accompanied by repeating errors like:
---
pfi_table_update cannot set <x> new addresses into table <blah>: <x>
---
and regular "I'm completely blocked" delays on the web configurator.
- Chris Buechler suggested trying 64-bit, but my machines are not 64-bit capable
- I can't yet test on pfSense 2.2 because it has a broken cas driver (time to
replace my ol' workhorse Sun 4-port/Gig-e boards)
- when I was writing back to Chris, off-list, I realized that my "System ->
Advanced -> Firewall/Nat" settings for the max firewall tables/entries
(250/2500000) were more than I needed so I reduced them to 150/150000 (actual
items about 100/880K):
+ that caused a more complete failure, causing the 2 "loading firewall rules"
during the boot-up sequence to "show dots" but no "done" and, upon boot-up
completion, there were errors like:
---
02-17-15 23:51:33 [ There were error(s) loading the rules:
/tmp/rules.debug:180: cannot define table NotLAN2lans: Cannot allocate memory -
The line in question reads [180]: table { 172.24.16.0/24 172.24.18.0/24
172.24.32.0/24 172.24.64.0/29 172.24.48.0/29 172.24.48.32/29 172.24.48.64/29
172.24.48.96/29 172.24.48.128/29 } ]
---
and none of the tables were created (and I suspect no rules were actually
loaded, but didn't check).
- given that reducing the max tables/entries values made things worse, it
seemed obvious that I should try increasing them
... and setting max tables/entries to 300/3500000 appears to have worked around
the issue.
My guess is that there's some static memory allocation that's calculated based
upon the max tables/entries sizes (and other criteria) but that my mix of
tables, with 10 of them having about 70K entries each, isn't anticipated by
that memory-allocation calculation. A static type of allocation wouldn't
surprise me as I'd assume the rules are very performance-critical.
I've subsequently been able to complete the set of alias/rule changes I was
making when things broke so, until it fails again, I'll consider this to be an
OK work-around and hope this write-up will save someone else some
troubleshooting.
Warning: Thus far, I also have found that:
- one port alias was changed to be a duplicate of the port alias just before it
in the list and that new name was propagated where it was used within other
aliases and rules
- one of the URL alias was missing, entirely (and pfSense nicely notified me
about the affected rules)
... so it should be expected that running out of memory for rules/tables is
likely to cause some corruption in the configuration if you don't revert to a
previous config and cause additional memory to be allocated (i.e., don't save
any config changes after experiencing this kind of memory error).
_______________________________________________
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold
