The existing code only includes a v6 name server IP in the
automatically generated dhcpdv6 configuration for tracking interfaces if
there are additional prefixes that can be delegated on to the next
router (i.e., if PD length > 2). The correct behavior is for this option
to be included regardless of the PD length, as implemented in this
change.
When computing the start IP for the 'available range' field,
services_dhcpv6.php attempts to increment a colon-formatted v6 address.
Since this always fails, so the value that's printed is not actually
incremented, so remove the bogus addition.
Note that this is actually matches the behavior of the range checks that
services_dhcpv6.php performs: The actual check uses the range
[gen_subnetv6()..gen_subnetv6_max()], which does include the first
(= all-zeroes host part) v6 address in the prefix.
Currently if the user is clicking around while they are setting up an OpenVPN server, they can do stuff like this:
a) Select Server Mode - Remote Access (SSL/TLS + User Auth)
b) Select something in Backend for authentication
c) Change their mind and select Server Mode - Peer to Peer (SSL/TLS)
d) Enter the other settings and Save
Now the OpenVPN server config has an 'authmode' key in it.
Probably does no harm, I suspect it will simply not be used when building the server.conf for Peer to Peer, but it looks a bit odd when analysing/diagnosing a config for problems.
Other fields that are mode-specific have tests to only save the values at the end if the appropriate mode is the one finally selected.
While I am here, I also constantly forget to click on "Local Database" authmode when setting up a new server. It gives the validation error message, then I click on "Local Database" again and save. Seems unnecessary - when defining a new OpenVPN server why not default this to have the first entry in the list be the one selected? So I did that. What do you think? 1 place less for many users to need to click.
IMHO it can be confusing on the DHCP edit page for static mapped entries to know which interface the entry is being edited/added for. Specially if the user comes from the Status DHCP Leases page, the lease they are editing/adding could be for 1 of many LAN-style interfaces.
This also made it easier for me to see which interface entry I was editing when I was testing https://github.com/pfsense/pfsense/pull/1504
The edit button for static entries always has an index id=0 and thus pressing the edit button goes to (mostly) edit the wrong entry.
It was easier and made the code cleaner to get rid of the looping through the staticmap array every time trying to matach IP, MAC address... That data ('if' and 'staticmap_array_index') is easily gathered further up, the first time the staticmap array for each DHCP interface is traversed. I think this should also be more efficient when there are many static mapping entries.
Forum: https://forum.pfsense.org/index.php?topic=89072.msg493241#msg493241
in send_smtp_message()
Other packages like arpwatch sm.php and cron job output as reported in forum https://forum.pfsense.org/index.php?topic=88347.0 call send_smtp_message() directly, currently bypassing notification disabled checks. I think those packages [are intended to | should be] respecting the notifications disabled setting. People in the forum certainly expect them to respect this setting.
If we add the $force parameter here, passing it through from notify_via_smtp() then the default behavior of send_smtp_message() can be to respect the "disable" setting. That should stop other package callers from spamming people who have disabled SMTP notifications.
If a package really wants/needs to send regardless, then it can set $force, just like the "Test SMTP" button does.
