[SOLVED] 2.4.3 - /rc.filter_configure_sync: cannot define table bogonsv6
-
Zero reason for 4,000,000 there. Try 400000. Maybe you are really running out of RAM at 4,000,000.
It really is working for everyone but you.
-
Well, solved it, but don't understand.
Did at least 10 WebGUI reboots, system did really reboot, but kept having the problem.
Finally did a complete system shutdown, removed power and restarted, problem is gone.After that I changed the 4,000,000 back to 400,000 as you suggested and it still works.
(i had previously increased in increments 200K, 400K, 800K etc, did not change a thing)so, weird but solved, thanks for your help. :)
-
My buddy is having this exact same issue on a fresh 2.4.3 install on a Dell R210 II with E3-1320 v2. He has the bogons error, and when we changed it to 400,000 the error went away, but his internet speed TANKED. I'll tell him to leave it at 400,000 and to save and restart. If that doesn't work, shutdown, pull power and pop it back in. I have no idea why it would be different between the two options, except one is setting run level 6, the other run level 0.
-
I suppose it's possible there is an issue with processing the tables if the table size is increased but I have not seen it. In any case a simple reboot should fix it. That is strange.
-
My buddy was able to change the Max Table Entries to 400k and rebooted. His slowness went away. However, he still want receiving the same 250Mb down that he was getting on speedof.me. We tried a different speed test site (Comcast's as that's his ISP) and he was receiving 400Mbps. We confirmed this with the interfaces traffic graph on the dashboard.
This seems like a bad bug. Netgate should think about issueing a p1 immediately to fix this issue along with new install media. My friend nearly gave up on pfSense. I convinced him otherwise, but for a complete newbie with no one to go to, this could be a deal breaker.
-
It should be taken care of in the next release.
-
I understand that it should be, but it seems like a large bug if a fresh install kicks the error, but also causes very slow speeds. A fresh install should just work. Seems like a simple thing for Netgate to do. Not to mention it being the right thing to do.
-
Well keep in mind this isn't really an issue with the build itself. It's caused from the fact the bogons file (which gets downloaded) has now just barely exceeded the default 200k allocation.
While I agree with you that it's frustrating, and it caught me on a fresh install as well, it's not just specific to 2.4.3. It "should" be happening on all older releases as well that are downloading updated bogons and still have the default 200K value.
I assume for the dev's to come and issue a single commit to the exist 2.4.3 release branch, recompile, and then re-upload, they are likely just going to address in the next point release, which hopefully isn't too far behind. Something like a 2.4.3_p1 release.
I think it's just timing that the updated, larger bogons file came into play at the same time 2.4.3 was released.
Speed wise, I will say I have not seen a single issue as far as my bandwidth is concerned after updating to 400K (the new upcoming default), you are the first to say anything like that. I see my full 500Mbps down and 50Mbps up, consistently.
-
Confirmed - We started getting these errors in the last few weeks out of nowhere, no config changes on
2.3.2-RELEASE-p1 (amd64)
-
I still get this error:
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 <bogonsv6> persist file "/etc/bogonsv6"
@ 2018-04-29 13:12:47And I have alread set Firewall Maximum Table Entries to 400000
and do the reload filters.Why?
-
Have you rebooted?
-
@joltman:
Have you rebooted?
Yes, in addition I have found that If I go to "System/General Setup" and click save without changing anyting it appears again.
Does it make any sense?Ops it looks like there was an empty space after the 400000
