Fix various files that can emit messages like:
PHP Strict Standards: Non-static method SimplePie_Misc::array_unique()
should not be called statically, assuming $this from incompatible
context in /etc/inc/simplepie/simplepie.inc on line 5508
php-fpm[16262]: /rc.newipsecdns: PHP ERROR: Type: 8192, File:
/etc/inc/shaper.inc, Line: 4365, Message: Assigning the return value of
new by reference is deprecated
Some of these style messages have been reported on the forum, e.g.
https://forum.pfsense.org/index.php?topic=86448.0
I had RSS widget on, and simplepie sent the system beserk telling about
all this stuff.
- Move redundant code to a function parse_aliases_file(). Before the max
number of items was not being respected when URL content is updated,
only when alias was saved. Same was happening with ip/subnet/port
validation and user could end up with a bad pf.conf
- Remove unused variables
These changes were based on Pull Request #1264. It should fix#4189
Submitted by:▸ PiBa-NL
A few functions such as ipcmp(), subnet_expand(), and check_subnets_overlap() are in illogical places - away from all the other ip comparison and subnet basic functions and in the middle of alias handling and interface enumeration.
No change to functional code, just moving to earlier in the file (next to other IP compare and subnet functions) for ease of future contributors.
OpenVPN create the tun/tap interface and, when set an IP address to
it, mark it as UP. In some scenarios, when TAP is set as bridge and
doesn't have an IP address set on it, it never goes up and tunnel
doesn't work.
If rc.newwanip is called for this TAP interface, UP flag is set, but,
rc.newwanip is not executed when system is booting.
Since it's always rename the interface and add it the group, make sure
it's up here.
Tightens, canonicalises and improves for IPv6, the functions
gen_subnet(), gen_subnetv6(), gen_subnet_max(), gen_subnetv6_max()
Changes are transparent to calling code.
Issues:
1) gen_subnet() and gen_subnet_max() will validate both IPv4 and IPv6 as valid args, but will then try to process an IPv6 subnet bitwise as x32 LONG without further checking, causing erroneous but apparently valid responses.
2) None of the functions properly sanitise their input: if $bits is >32 or >128, or even a non-integer, erroneous results will be passed back to the calling code as valid data without checking, again causing erroneous but apparently valid responses.
3) 3 of the 4 functions return an empty string for invalid but gen_subnetv6_max() returns a numeric value for invalid. Both responses loose-evaluate as False, but consistency is better.
Fixes and improvements:
1) The unspecified functions gen_subnet() and gen_subnet_max() now handle all args correctly, and don't mishandle if unexpectedly passed IPv6 or bad data.
2) Names are now canonical: gen_subnet(), gen_subnet_max() are now IPv4/v6 agnostic, and IPv4-only versions gen_subnetv4() and gen_subnetv4_max() are added as expected to exist, to match existing functions gen_subnetv6() and gen_subnetv6_max().
3) The return value for bad args is made consistent (empty string = False).
4) gen_subnetv6_max() now uses Net_IPv6's Ip2Bin() and Bin2Ip() functions and simple string manipulation rather than bitwise operations, so it's guaranteed 32-bit safe (compared to 128-bit bitwise operations in current code which seem less certain?)
5) Changes are transparent - the canonical functions still work exactly as before on IPv4 (only with proper bad arg validation) but also now work on IPv6 transparently, and on arbitrary IPv4/IPv6 data, similar to other functions like is_ipaddr().
Tested and handles valid but uncommon edge cases of /0, /32 (IPv4) and /128 (IPv6) correctly. Also avoids inet_ntop/pton if that's a real issue (previous PR comment had asked to avoid these functions)
The array returned by auth_get_authserver_list() has key as the fixed name of each available authentication mode - e.g. "Local Database".
The array value ["name"] has the name string translated into the selected GUI language.
Use the key do determine which items are selected, and as the value that ends up being stored in the config.
Use ["name"] for display.
Forum report: https://forum.pfsense.org/index.php?topic=86326.0
Redmine Bug #4180
The following block uses "quick" which causes that block to come into effect before the "pass in" here. The pass rule also needs to be "quick".
Problem noted by Andy Sayler on https://redmine.pfsense.org/issues/4074
Before this change, an attempt to manually do something local with IPv6 fails:
[2.2-RC][root@xxx]/root: ntpq -pn
ntpq: write to localhost failed: Operation not permitted
After this change, it works:
[2.2-RC][root@xxx]/root: ntpq -pn
remote refid st t when poll reach delay offset jitter
==============================================================================
*27.114.150.12 193.190.230.65 2 u 21 64 377 1424.66 -126.52 371.131
Note that there are other pass rules later for IPv6 necessary functions, loopback... that do not have "quick". Those are correct and help to allow various essential IPv6 stuff, but still let someone block it with user rules (which will have quick), in the case when IPv6 Allow is checked.
This one here is just for the special case of IPv6 Allow not set, and in this case this special IPv6 pass-block sequence needs to be done with "quick" so we can be sure it applies regardless of whatever other IPv6 might come later.
Issue reported here: https://forum.pfsense.org/index.php?topic=78356.msg472781#msg472781
Most unbound doc places mention setting it at up to 8m. I'm sure it would be possible to investigate more and find a way to make unbound+FreeBSD be able to go higher than 8m. But probably 8m is sufficient for everyone anyway (judging by what the unbound docs seem to assume will be a good value on a busy system).
Anyway, here is my easy fix for this. Someone else feel free to investigate more if they really need to set so-rcvbuf higher.
- Unbound advanced options may contain double quotes and it breaks the
syntax when a backup is restored because newlines are trimmed. Save it
in base64 format is a safe way to prevent it
- Bump config version to 11.5
- Provide upgrade code to encode current config or the one that came
from unbound package on 2.1.5
When an interface is waiting to get DHCP, but the cable is physically-electrically connected to the upstream device, the interface has an IPv4 address 0.0.0.0 - that was getting past here and, if the interface gateway had a monitor IP specified, that monitor IP was being put into apinger.conf and being monitored. Because the interface has not got a gateway yet, no static route is added to force the traffic for the monitor IP out the particular interface. So the traffic to the monitor IP can follow the default route and perhaps succeed in getting out another WAN to the monitor IP.
The downstream results of this were:
1) Gateway status appears up and reports real RTT and Loss statistics, even though the interface is down.
2) Generation of rules for a gateway group that has this gateway as tier1 will think it is up, and thus try to policy-route traffic to it - which then does not get anywhere.
3) DynDNS status of a gateway group that has this gateway as tier1 shows the cached IP in red - it thinks the interface/gateway is up and tries to find the public IP by trying to get to checkip.dyndns.com through the interface/gateway. That of course fails.
4) I'm sure there are other things that depend on checking gateway and gateway group status that would also be getting it wrong in this condition, because apinger is being told to monitor, and manages to successfully monitor, an interface/gateway that has not yet got DHCP.
When waiting for DHCP, ifconfig shows like this on my system (WAN is on a cable to a VLAN switch):
vr0_vlan70: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
ether 00:0d:b9:24:59:c0
inet6 fe80::20d:b9ff:fe24:59c0%vr0_vlan70 prefixlen 64 scopeid 0xf
inet 0.0.0.0 netmask 0xff000000 broadcast 255.255.255.255
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
media: Ethernet autoselect (100baseTX <full-duplex>)
status: active
vlan: 70 vlanpcp: 0 parent interface: vr0
From what I can see, this little 2-line fix ends up correcting all the downstream effects I listed above.
Should fix RedMine #4094
Reported by forum https://forum.pfsense.org/index.php?topic=86146.0
Also, if there are input validation errors, save the user-entered data and re-display it, making it easier for the user to just correct the data in error and press Test again. It was blanking out all the entered data.
