Few problems/question after upgrade to 2.1
-
Hi.
I'm using FS Futro S400 (http://uk.ts.fujitsu.com/rl/servicesupport/techsupport/professionalpc/thinclients/futrosxx/futros400.htm) and pfSense is installed on the CF card.
After upgrade to 2.1 from 2.0.3 (4g-i386-nanobsd_vga) i have a few problems:1. Memory usage increased from 55/56% to 85/92% (now it's 65% because i disabled Log packets blocked by 'Block Bogon Networks' rules and Log packets blocked by 'Block Private Networks' rules in settings.
2. Auth test doesn't work (diag_authentication.php), i have this error:
Fatal error: Cannot redeclare getNasIP() (previously declared in /usr/local/captiveportal/radius_authentication.inc:53) in /etc/inc/captiveportal.inc on line 1576
Can I fix it somehow ?
3. In system logs sometimes i see this massage:
System logs: php: /diag_nanobsd.php: Could not open shared memory for read 1000
With the exception of the problems that I mentioned above my router is working fine - I'm using Snort and FreeRadius2 packages.
-
1. If you have "IPv6 Allow" on and check "Block Bogon Networks" on any interface, then the bogonsv6 table will be loaded into pf. That table is big and sucks up memory - not good news for low-memory systems (<=256MB). I have stopped using "Block Bogon Networks".
2. getNasIP() routine is duplicated in both those files, but only 1 of them has a function_exists() check. I wonder why nobody else has reported this yet?
You should be able to fix it by editing captiveportal.inc and putting a check around function getNasIP():[b]if (!function_exists('getNasIP')) {[/b] function getNasIP() { global $config, $cpzone; if (empty($config['captiveportal'][$cpzone]['radiussrcip_attribute'])) { $nasIp = get_interface_ip(); } else { if (is_ipaddr($config['captiveportal'][$cpzone]['radiussrcip_attribute'])) $nasIp = $config['captiveportal'][$cpzone]['radiussrcip_attribute']; else $nasIp = get_interface_ip($config['captiveportal'][$cpzone]['radiussrcip_attribute']); } if(!is_ipaddr($nasIp)) $nasIp = "0.0.0.0"; return $nasIp; } [b]}[/b]
If that works, post back.
There might also be a nicer fix to put this routine in a common include file and not duplicate the code.3. That is trying to read the shared-memory that keeps a count of how many things have currently got the file system mounted for write. When it goes back to zero on nanoBSD the file system is mounted read-only again. Strange - I don't see that error.
In Diagnostics->Command Prompt, PHP Execute, run this:var_dump(refcount_read(1000));
It should display:
string(10) "1"
or some number >1 (it will be at least 1 because the PHP Execute code does 1 read-write mount automagically.
If it comes up with "-1" then somehow on your system it is having trouble finding the shared memory section. -
2. It works - thanks. :D
3. I have:
int(-1)
Is that a huge problem ?
-
3. I have:
int(-1)
Is that a huge problem ?
It is surprising. I am not sure how that -1 can really happen. It is in the code, but the condition should really be theorectical! I'll think about it.
-
If there is nothing on your system that needs to mount the CF card for write during the bootup, then that shared memory section never gets created. refcount_read() does not do anything to create the shared memory section, so if it does not exist this message is logged.
Go to Diagnostics->NanoBSD. Click "Switch to read/write" then switch back to read-only. That should force the shared memory section to be created. Then do again the:var_dump(refcount_read(1000));
Now it should be happy and return "1".
That will confirm that it is just that the section never got created in the first place.
Then the code can be fixed to cover this case - it won't be causing any real problem.I guess you are using a pretty much base firewall/router system, that is able to put all its startup stuff in /tmp and /var and has no need to rewrite/rebuild any configs on the CF card file system at bootup. It will be interesting to know what minimal set of features in use causes this. Can you give some general idea of the things you are using this installation for?
-
If there is nothing on your system that needs to mount the CF card for write during the bootup, then that shared memory section never gets created. refcount_read() does not do anything to create the shared memory section, so if it does not exist this message is logged.
Go to Diagnostics->NanoBSD. Click "Switch to read/write" then switch back to read-only. That should force the shared memory section to be created. Then do again the:var_dump(refcount_read(1000));
Now it should be happy and return "1".
That will confirm that it is just that the section never got created in the first place.
Then the code can be fixed to cover this case - it won't be causing any real problem.I guess you are using a pretty much base firewall/router system, that is able to put all its startup stuff in /tmp and /var and has no need to rewrite/rebuild any configs on the CF card file system at bootup. It will be interesting to know what minimal set of features in use causes this. Can you give some general idea of the things you are using this installation for?
Well now is```
string(10) "1"php: /diag_nanobsd.php: Reference 1000 is going negative, not doing unreference.
But also I noticed option "Keep media mounted read/write at all times." was checked (i didn't turn it on before). ??? - and maybe this was a reason ?
-
"Keep media mounted read/write at all times." - if I check this and reboot on a pretty-much default system (no packages, no VPNs,…) I can reproduce the symptoms/problem - the shared memory section never gets created.
It is probably best that it does get created and the reference count is maintained anyway, even in this case. Then if the checkbox is unchecked, the reference count will already be correct and the nanoBSD system can correctly switch over to managing the read/write state of the CF card on-the-fly.
I'll propose some changes in GitHub...
Note: It is not a critical issue, nothing actually breaks, so no rush to "fix" on any live system.
Pull request against pfsense master: https://github.com/pfsense/pfsense/pull/805
Note: the files in this pull request are diff against master. There are other diffs between master and 2.1 for util.inc, so it can't just be pasted in to a 2.1 system. -
About problem 2:
I encountered the same issue after upgrading 2.0.2 to 2.1-RELEASE. The fix you suggested (editing captiveportal.inc) worked okay.
This issue did not occur on fresh installs of 2.1 or when upgrading 2.1 BETA/RC to 2.1-RELEASE, only for 2.0 to 2.1.