| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
Partly revert b76e0baebb70775b192507ec18f523141800ce95.
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
starting before dchp6 has completed leading to problems, this occurs only on boot.
Further examination did indeed show that the problem is caused by unbound starting before the dhcp6c - RTSOLD - rc.newwanipv6 have completed, making sure that these have all run before unbound is allowed to start corrects the problem.
In order to fix this I have added a file creation of a file in tmp in rc.newwanipv6, this is the final function when the system is booting and ONLY when the system is booting.
In interfaces.inc I have added an unlink_if_exists () of this file, this is a "just in case" catch, should the file have been left behind due to some unforeseen event.
The real work is done in services.inc, a section of code has been added that can cause up-to a ten second delay before allowing unbound to start. This is achieved by waiting for the file created by rc.newwanipv6 to exist, once it does exist then the file is deleted, the sleep loop breaks and unbound is allowed to start. If the file does not exist after 10 seconds then the sleep loop exits and unbound can start.
Checks are made for the fact that WAN is using Ipv6 and dhcp6,
|
|/ |
|
|\ |
|
| |
| |
| |
| | |
A new option when setting a v6 static on the WAN to allow the connection to use the V4 interfaces i.e. PPPoE
|
|\ \ |
|
| |/ |
|
|/
|
|
|
|
| |
Currently, when using dhcp6c advanced configuration the prefix interface is WAN, this is not very useful!
The changes here allow the user to select the interface that the PD will be applied on..
|
| |
|
| |
|
|\ |
|
| |
| |
| | |
See https://redmine.pfsense.org/issues/4544#note-4
|
|\ \ |
|
| | |
| | |
| | | |
Not defined pid file on starting choparp. The pfSense may not kill the program to reconfiguration.
|
| | | |
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
- Forum thread: https://forum.pfsense.org/index.php?topic=124046.msg705100#msg705100
- related dhclient source:
https://github.com/pfsense/FreeBSD-src/blob/devel/sbin/dhclient/clparse.c#L945
**changed files:**
/usr/local/www/interfaces.php
/etc/inc/interfaces.inc
|
|\ \ \ |
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Some hardware is taking too long to set ACCEPT_RTADV on the Interface,
this results in RTSOLD exiting and this not sending RS to start the
process. Apart from adding a delay to the start of RTSOLD which did
improve but not totally fix the issue the other change is to prevent the
call to -ACCEPT_RTADV if the interface is using DHCP6.
-ACCEPT_RTADV in the case of wancfg['dhcp6usev4iface'] || $wancfg['ipaddr']==='ppp'
Cleaning up dhcp6c kill calls.
ppp-ipv6
Changed to call kill_dhcp6client_process() to make
sure the lock files are also cleared.
Interfaces.php
Changed to call kill_dhcp6client_process() to make
sure the lock files are also cleared.
|
| | |/
| |/|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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
|
| |/
|/|
| |
| | |
No functional change.
|
| | |
|
| |
| |
| |
| |
| |
| |
| | |
Use a single file for vendor MAC retention (vendor_mac).
a) Writes only one file during boot up rather than a file for each interface.
b) More efficient than numerous tiny files.
c) Friendlier to write cycle sensitive media in a RAM disk disabled system.
|
| |
| |
| |
| |
| |
| | |
Relocate the vendor MAC retention file to /var/db directory.
a) It's more at home here with other network interface stuff.
b) Friendlier to write cycle sensitive media in a RAM disk enabled system.
|
| |
| |
| |
| |
| |
| | |
Only use the vendor MAC retention file for restoring the vendor MAC when not booting.
a) During boot up the current MAC that is obtained from the system is the vendor MAC.
b) Using this eliminates the inefficient need to open the vendor MAC retention file for every interface during system boot up.
|
|/
|
|
|
|
| |
Rename 'spoof_mac' var to generic 'mac_addr'.
a) It may be the vendor MAC or a spoofed MAC.
b) Update the comment re: not reapplying an already applied MAC.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|\
| |
| |
| | |
marjohn56/RTSOLD-lock-creation,-dhcp6c-launch-&-kill-changes-#3
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Added lock file creation and check to RTSOLD script creation. This is to
prevent mutliple launches of dhcp6c, this appears to happen when
multiple RA's are received in rapid succession at the start of a
session. Once created dhcp6c cannot be launched again until the lock
file is deleted, this is done within the kill_dhcp6_client process
locking the two together.
The kill vlaue used to kill the dhcp6c client is now variable. The
value -9 causes the process to exit without sending a release if
required, and if the timing is just rignt can cause the pid file to be
left behind; -15 allows for a graceful exit and if the release flag is
not set then it sends and waits for the release confirnation, the value
now switches between those depending on the configuration option 'No
Release'. If no release is true then -9 is used as the type. Any left
behind pid is removed automatically. This change will make it possible
to stop the use of the -n flag, thus allowing the dcp6c to send a
release manually, if so required.
The launch of dhcp6c when in dhcp6withoutRA is moved to its own
function, as uch as anything this makes the code tidy around the bottom
of nterface_dhcpv6_configure().
A completely new method of implimenting dhcp6wihtoutRA is used. In
default mode RTSOLD launches dhcp6c. In dhcp6wihtoutRA mode dhcp6
aunches RTSOLD.
New scripts are created and old ones modified to handle this mode, the
dhcp6 conf file changes depending on the mode calling a different script
for each mode. In simple terms its dcp6->rtsold- lan_configure. Whenever
dhcp6 gets a response that launches its script then it will run rtsold,
the RA in turn will cause the wan6 configure script to run. This method
also means the script only ever runs once and no modified dhcp6c is
required.
The scripts are dynamic and change depending on the mode. Creation takes
into account that the domain-name-server variables created by dhcp6 and
passed to the script it calls are passed on. In default mode this is
simple as it calls the dhcp6c_*_script which calls the rc.newwanipv6
script directly, in dhcp6withoutRA its RTSOLD that calls the
dhcp6c_*_script, so in order to make this change work the variables are
echoed to the tmp folder and retreived by the dhcp6withoutRA version of
dhcp6c_*_script when that calls rc.newwanip.
|
|/ |
|
|
|
|
| |
OpenVPN to its address
|
|\ |
|
| |
| |
| |
| |
| |
| |
| | |
User may define a DUID to use in System->Advanced->Networking. The
entered DUID is validated for composition and length, if valid it is
stored in the config.xml. On call of wan_dhcp6_configure() the DUID is
written to file to be read by dhcp6c on launch.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The last interface IP is always saved in /var/db/${interface}_ip. Use that file, if it exist, to find the main interface IP.
The file is created by the same process and function that call 'ifconfig setfirst', so the presence of that file should produce a very similar behavior.
If the file does not exist, fallback to previous behavior (return the first IPv4 found on interface).
Ticket #7042
|
| |
| |
| |
| | |
to reduce nesting
|
| |
| |
| |
| |
| |
| | |
even though the interface (or gateway group) has not yet actually
received an IP address.
This is useful when setting up a new system that is currently offline.
|
|/ |
|
|
|
|
|
|
| |
Script changes to allow no-release option of dhcp6c. These changes to be
used in conjunction with pfSense/FreeBSD-ports/net/dhcp6c recent change
from PR #231
|
|
|
|
| |
prevent the backend from attempting to apply entries with insufficient information stored. Fixes #6969
|
| |
|