This PR takes advantage of modifications and additions to dhcp6c.
Firstly, a fix has been made to dhcp6c where the pid was being deleted
before all processes had completed; this could leave dhcp6c sending
release signals but any check for the process using the pid would return
false; thus if the server was not responding or the WAN was down then
dhcp6c could sit there for tens of seconds even though it appeared to
have exited.
The env var REASON has been updated to provide information as to why the
script has been called. These can be one of the following:
REASON=INFO
REASON=REPLY
REASON=RENEW
REASON=RELEASE
REASON=REBIND
REASON=EXIT
REASON=OTHER
The OTHER is a final catch and should never happen.
The scripts take advantage of these vars, for example a renew no longer
calls rc.newwanipv6.
The use of SIGUSR1 and SIGUSR2 to terminate dhcp6c results in different
exits. SIGUSR1 will force an exit without sending a release to the
server, this is used in the case of a WAN down event to prevent dhcp6c
from hanging on a release signal. SIGUSR2 is used to send a relase
signal overiding the no-release flag ( if set ), no code or GUI
additions have been added to make use of this signal in this PR. The
existing SIGTERM will cause dhcp6c to exit normally obeying the
no-release flag if set.
NOTE - The code for SIGUSR2 is in place in this file but as yet it is not
included in dhcp6c. In the event of SIGUSR2 being called, it will fall
through to a standard SIGTERM exit.
Debugging messages have been added to the scripts
dhcp6c_{$interface}dhcp6withoutra_script.sh and
dhcp6c{$interface}_script.sh. These debug messages only appear if the
debug setting for dhcp6c has been set in the config, they also appear in
the dhcp log rather than the main system log.
This PR is dependant on PR#5 at hrs-allbsd:freebsd or
pfsense/FreeBSD-ports #299
These changes are in response to Redmine 5993, 6944, 7145 and 7185.
Updated to match new upstream dhcp6c
changed REASON=REPLY to REASON=REQUEST.
K&R Corrections
After killing php-fpm (console opt 16) check_reload_status would sometimes hang, consuming 100% of 1 cpu core. I found a reference https://redmine.pfsense.org/issues/3884#note-4 saying that check_reload_status depends on php-fpm. This patch wraps the restart of php-fpm with a stop/start of check_reload_status. In my limited testing, this has eliminated the hangs, which were pretty easily reproducible before.
