Upgrade to 2.4.5 > 2.4.4-p3 SG-3100 ipv6 bogon list issue

bigsy

@jimp Latest snapshots (Feb 28th) seem to have this sorted on the SG-1000.
Great work!

jimp

Yeah, we're getting closer. Still some issues yet, though.

bigsy

@jimp SG-1000 2.4.5-RC (arm) built on Fri Mar 13 00:05:30 EDT 2020

The error message has returned on this build.

There were error(s) loading the rules: /tmp/rules.debug:18: cannot define table bogonsv6: Cannot allocate memory - The line in question reads [18]: table &lt;bogonsv6&gt; persist file &quot;/etc/bogonsv6&quot;
@ 2020-03-13 06:02:21

jimp

@bigsy said in Upgrade to 2.4.5 > 2.4.4-p3 SG-3100 ipv6 bogon list issue:

@jimp SG-1000 2.4.5-RC (arm) built on Fri Mar 13 00:05:30 EDT 2020

The error message has returned on this build.
There were error(s) loading the rules: /tmp/rules.debug:18: cannot define table bogonsv6: Cannot allocate memory - The line in question reads [18]: table &lt;bogonsv6&gt; persist file &quot;/etc/bogonsv6&quot;
@ 2020-03-13 06:02:21

That's not the same problem. That's due to the low amount of RAM + the packages you have installed. That shouldn't be fatal like the other one, the tables do load by the time everything else is done.

See https://redmine.pfsense.org/issues/10310

bigsy

@jimp OK thanks, my confusion came from the error message being the same as that which opens this particular thread.

This little SG-1000 is purely for testing. I've been updating 2.4.5-RC builds on a daily basis, haven't changed any packages, and that was the only time the error appeared. A later build from today (Fri Mar 13 03:05:27 EDT 2020) doesn't show the error.

jimp

If you look closely the error is not the same :-)

The one that was a problem in the builds says too many elements compared to your latest one which is Cannot allocate memory.

bigsy

@jimp Yep. Presbyopia. Spectacles on now!

ngnym

When I upgraded to 2.4.5-RELEASE (arm) on my SG-3100 through the web interface, I started getting e-mail notifications with the bogon error. I didn't find this post, but I found older ones where, IIRC, it was recommended to set "Firewall Maximum Table Entries" to 400,000 or higher to resolve the error. It sounds like I probably encountered this issue and a reboot may have resolved my problem, but (again, IIRC) I eventually set the entry to 500,000 and rebooted. While troubleshooting a separate issue that I thought could be related to this, I checked and it was still set to 500,000 and it said 500,000 was the default, so I cleared that out and hit save. Shortly thereafter, without rebooting, I got an e-mail notification that said this:

To block bogon IPv6 networks the Firewall Maximum Table Entries value in System / Advanced / Firewall must be increased at least to 400,000

I logged back in to the web interface and the setting was showing 200,000 as the default, so I set it to 400,000 again. I left the page and went back, and it says the default is 400,000. So, two questions:

Do I need to reboot again now (to make it use 400,000 vs 200,00) or is it still using 500,000?
Presumably listing the wrong default is a bug, where should I report it?

jimp

@ngnym said in Upgrade to 2.4.5 > 2.4.4-p3 SG-3100 ipv6 bogon list issue:

Do I need to reboot again now (to make it use 400,000 vs 200,00) or is it still using 500,000?

On 2.4.5 there are two separate issues here. The pf table limit can be set immediately and it will use whatever value you put in there after the next filter reload. There is also a pf request limit which must be set and that only takes effect at boot time.

Presumably listing the wrong default is a bug, where should I report it

It's reporting the size as it was when the page was loaded, apparently, and not what the calculated default for the system would be. That may be a bug, though it should probably report both.

ngnym

@jimp said in Upgrade to 2.4.5 > 2.4.4-p3 SG-3100 ipv6 bogon list issue:

It's reporting the size as it was when the page was loaded, apparently, and not what the calculated default for the system would be. That may be a bug, though it should probably report both.

Well, it technically does report both in that it appropriately shows the value that was set when the page was loaded in the field where you can change the value. The bug would be that the display for the "default value" stated under the field is actually showing the currently set value.