openvpn, allow for entering client user credentials in the WebGUI
Tighten is_numeric()

Improvements:

1) avoids 'expensive' preg_match() and is a more exact test
2) fixes logic whereby an empty string or anything converted to an empty string, is deemed a valid 'numeric' value

(If an empty string can validate as numeric, it's possible that in some cases a number is expected and missing in a string, but not detected, causing malformed rules or subnet bitcounts, and unexpected issues or vulnerabilities)

 -- also moved code to a more logical place in the .inc while doing this, not mixed in between IP handling functions
Fix gateway quality RRD to have the correct granularity and be consistent with the pfSense graphs set.

Create gateway quality RRD with settings suitable for pfSense graph set,  since apinger uses default step (300) and other settings that are not so  good/consistent with the pfSense graphs set.

Originally Submitted as Pull Request #672.
Resubmitting to Master.
Make a good copy of PHP_errors.log for crash reporter

Forum report https://forum.pfsense.org/index.php/topic,72877.0.html
Merge pull request #954 from phil-davis/master

Make a good copy of PHP_errors.log for crash reporter
Merge pull request #951 from stilez/patch-1

Tighten is_numeric()
silence any errors
Do some more error checking and put secondary radius attributes only if configured. Probably radius configuration should be merged with central server for logins!
Use env var provided by openvpn to determine if it's tun or tap, it should fix #3475
Add the missing global $g
Use the default bw specification if configured even for allowed ip and hostname.
If set use the default bandwidth setting on the CP even for mac passthrough. Reported-by: https://forum.pfsense.org/index.php/topic,72761.0.html
Update IPV6.inc to latest 1.2.1 version
Actually take latest one from github. It has some more checks and more execution time penalities but catches more errors
s/PEAR.php/PEAR.inc/
Correct obvious bug in IPv6.inc
Update list of mobile service providers
Update tzdata to 2013i
Rather than having issues with not started radvd try to start radvd to discover by itself the prefix on the interface by using the special directive :: on the prefix declaration. Related to many tickets and forum posts
Tighten is_subnet() functions

The is_subnet(), is_subnetv4() and is_subnetv6() functions have significant issues in their coding logic.

Issues:

1) Functions use is_numeric(), so they validate invalid bitcount parts such as '1.1.1.1/6.5' or '::8000/94.7' as valid subnet strings

2) Validation explodes to a list of 2 variables rather than testing the whole string, so it's possible to craft a malicious string or mis-enter text such as "::8000/24/;\nARBITRARYTEXT;", or any valid subnet followed by a third '/' character followed by arbitrary text, which always validates as permitted data. In v2.x this allows arbitrary or malformed text placement into core config files such as pf.conf, f/w tables, and probably exec() strings, from the GUI (reported previously)

3) is_subnet() and is_subnetv6() return false for the valid subnet /0 as a CIDR, although technically this is allowed and valid as a subnet (it may have unambiguous and useful meaning in a router or security context).

The existing code is easier to rewrite than fix. It's a lot shorter too. A single preg_match() does all the separating of valid subnet parts and identifies which if either type of subnet the string could be, by exactly matching EITHER (7-15 char string containing only 0-9.) OR (2-39 char string containing only 0-9a-f:) followed by '/' and (1-3 numeric digits). Depending which of the first two matches is non-empty, it then checks the "ip" part" and "numeric" part are each valid, and exits. Efficient and robust.

NOTE: - these functions returned a True/false value ( is_subnet() or !is_subnet() ). As any positive number evaluates in a Boolean sense to True, I have taken advantage of this to have "success" return 4 or 6 (not just "true") to say the type of subnet matched.  It's no extra effort or cost, and turns out to allow a lot of efficiency and code simplification elsewhere, since calling code that needs to validate a subnet *and* test if it's IPv4 or IPv6, a common situation, can now do this reliably with a single is_subnet() call:

  if (($sn = is_subnet($data)) {
      if ($sn == 4) 
         IPv4 handler code...
      else
         IPv6 handler code...
  } else
      error handler code...

I've used it here to write is_subnetv4() and is_subnetv6() to be single line near-aliases of is_subnet(), that just check the return value is indeed 4 or 6.