Thise scripts were used on tarball upgrade before pkg(8). Users running
pfSense < 2.3 will need to go to 2.3 first and then to 2.4 so they will
not be necessary anymore
pprior code "converts" every icmp type - of which only 3 actually get changed (rest keep same value anyhow!). If also uses a SWITCH {} construct rather than lookup + foreach, which is longer and less efficient.
For example, WAN receives a /48 delegated from the upstream (ISP...),
e.g. "2001:470:abcd::" pfSense then uses this as a starting point to
calculate the addresses on LAN, OPT1, OPT2 etc where they have been
specified asa "track interface WAN".
Actually each local interface gets just a /64 taken out of the /48,
using the chunk specified by "IPv6 Prefix Id" for that local interface.
e.g. if "IPv6 Prefix Id" is set to "a1" on LAN, then the LAN would be:
2001:470:abcd:00a1::/64
Then when we specify a static-mapped address in LAN, or other things
that live in LAN, e.g. "::4242" we mean 4242 on from the base LAN
address, so "2001:470:abcd:00a1::4242"
i.e. we always have a CIDR of 64 when calculating this stuff. We do not
want the logic that was in this code that was using the upstream prefix
delegation size (like /48).
Note: The code in services.inc "worked" because var $ifname was not set,
and so $trackifname was blank, $trackcfg was blank, and so the attempted
calculation of $pdlen always came out as 64 anyway. That tricked me for
a while trying to understand why the use in service.inc worked.
system.inc did not work, because it actually claculated $pdlen and got a
number like 48 - which actually we do not want here.
After testing diag_dns behaviour some regressions have been noticed.
1) Looking up ipv6.google.com (it only has AAAA records) doesn't work
- gethostbyname() only supports v4, ipv6.google.com only has v6
- this bug was recently and inadvertently introduced
2) Results table will always show even when domain is not resolved
- since refactoring ages ago, $resolved is an array, bad idea to replace with a string, this will cause issues
- this piece of code was 'dead' until the recent commit has 'enabled' it again, removing it as not needed
3) Parameters for display_host_results (see: fe74228f2a for its introduction) weren't correctly updated
- mostly a dead function, doubt this is used for anything, keeping it just in case.
This commit fixes all aforementioned issues.
