dpinger stopps with an error when the socketname exceeds over
(around) 100 characters. The dpinger will not start and not deliver
monitoring results to the WebUI.
These long socket names can get created when using link-local addresses
and long gateway names / interface scopes.
See Ticket 6505
Currently underscores are used to seperate gwifip, monitorip, etc, but
underscors are also used in vlan subinterfaces like em0_vlan10 and
therefore can't be used because the interface scope is appended to IPv6
link-local addresses.
The existing regex here is wrong, it matches 0 or more of the hex digits but then there can be other rubbish in the string, in fact anything at all! It matches "az", "z", "qwerty" and so on. So the "return false" inside this "if" never happens.
In most cases the later code catches problems, because it converts the string from hex to decimal (and things like "z" end up as decimal 0), then it does some back-conversion of the answer to hex and realizes something is different and so does not count the entry as one of the needed 8 valid segments of the IPv6 address.
This goes wrong if the user supplies a string with 8 valid IPv6 hex pieces and 1 or more extra invalid ones anywhere in the list. In that case the code finds 8 good chunks and thinks that all is well.
Try using the pfSense is_ipaddrv6() with strings like:
$ipaddr = "1:2:3:4:5:6:7:z:a";
$ret = is_ipaddrv6($ipaddr);
var_dump($ret);
That returns true - which is not good!
You can put the invalid items anywhere you like, as long as you have 8 valid items, such as:
"1:2:3:xy:4:5:6:7:8"
"gh:1:2:3:xy:4:5:6:7:8"
"1:2:3:xy:4:5:6:7:8:qw"
This change makes this initial validity check on the characters actually work, so it avoids the later code having to deal with that at all.
(cherry picked from commit 8a950b3c37)
The usage of require() and require_once() throughout the system is
inconsistent, and "bugs" come up now and then when the order of
"requires" is a bit different and some require() happens after the
include file is already included/required.
It seems to me that there is no harm at all in always using
require_once().
This is a string from a list of valid values (empty, "hostonly", "fqdn"). So it is not correct to just gather a true/false value here.
(cherry picked from commit e93242eb2a)
Apparently gettext() does not behave correctly when passed an empty string, this commit ensures gettext() is called only with non-empty strings
(cherry picked from commit 6ae99aba5c)
This fixes the GUI inconsistency reported in the referenced bug. On edit of an OpenVPN server that has tun mode, not shared key, and the gwredir checkbox checked, the local_network fields are shown, but actually they should be hidden (because that is what happens on first data entry when gwredir is checked).
At least this makes the GUI consistent. Then the other issues mentioned in Redmine feature 6483 can be addressed separately.
(cherry picked from commit fa20dac1b5)
If _POST['members'] or _POST['groups'] is not set / none selected at GUI, it would give a warning on crash reporter (dev versions)
(cherry picked from commit 9f4722022f)
Currently if you delete your own user name, then the config ends up with a blank user tag in it. Rather than fix that up, it seems dangerous to be able to delete yourself anyway, because if you are the last user with admin privs for which you know the password (i.e. if you have not recorded the password for "admin" somewhere), then you can lock yourself out. That would require console access to fix, which for some people is a pain.
It seems reasonable to me to make the person login as some other user with admin privs to delete "themselves".
Bit of boots and braces done here:
1) Don't show the trash bin icon for "yourself", and also disable the delete_check checkbox. So you can't opt to delete yourself from the ordinary front-end GUI.
2) Enhance the back-end validation to prevent deleting yourself, just in case someone mucks about in the front-end code.
3) Put error messages to tell people when something is not deleted, and why.
4) In the success message for multi-deletion, tell which user names have actually been deleted.
(cherry picked from commit d6b79c398d)
1) Function can be simplified and all "if" statements removed, using intdiv (or casting result as int for PHP < 7) and % for calcs and sprintf for padding.
2) Input validity check before trying to convert format
3) If time represented is large (eg uptime might be several months) then hours becomes unhelpful, it's clearer to show "4921:02:06" as "205d 01:02:06". (Leading "days" value not shown unless >=1 for simplicity)
(cherry picked from commit 0bde6d1057)
Useful function in some circumstances - seems no reason not to have it.
Uses IP rather than hostname since not all ARP entries have hostnames.
Probably should also have "delete all" but not done that.
(cherry picked from commit 6ea0d41e3c)
