| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
(cherry picked from commit 48c4a0ea0958c0820f6caab2bf5182967114ac58)
|
|
|
|
|
|
|
| |
When Dynamic DNS entry uses a gateway group as interface,
return_gateway_groups_array() will be called and it returns real
interface instead of friendly name, as expected. Take both friendly and
real interface name into consideration.
|
|
|
|
| |
code for static map IPv6 hosts. Fixes #7324
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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,
|
| |
|
|\ |
|
| |
| |
| |
| | |
backups
|
| |
| |
| |
| |
| |
| | |
Revert "Change the way unbound is stopped when the process is being restarted, to give the old process enough time to exit cleanly. Fixes #7326"
This reverts commit 38d110824c87ff60c6289c0432d55009586ceee4.
|
| |
| |
| |
| | |
give the old process enough time to exit cleanly. Fixes #7326
|
|/
|
|
| |
re-used in a loop.
|
|\
| |
| |
| |
| | |
dyndns_dreamhost
|
| |\ |
|
| | | |
|
| | | |
|
|\ \ \
| |/ /
| | |
| | |
| | | |
dyndns_dreamhost
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| |/ |
|
|/ |
|
| |
|
|
|
|
|
|
| |
write_config. Adjust base system calls to match. Ticket #7146
Packages may still need the old behavior but need tested individually. Once all function calls are confirmed to work without the write, the write_config parameter and call can be removed from this function for good.
|
|
|
|
|
|
| |
Initialize cached IP and Time on loop for RFC2136 items, without this
the items used on last loop iteration will be used again and second
item on the same interface will not be updated
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
1) Treat the RAM disk more like a permanent storage device with content managed/restored by the system and made available at boot up, before needed by any services.
a) Handle saving and restoring RAM disk content at reboot/shutdown/boot centrally in more of a system manged fashion.
b) If it's in the RAM disk store it gets restored early in the pfSense startup so it's available for whatever needs to use it.
c) Services utilizing RAM disk don't need to be aware that their content is on a RAM disk, and handling content restore individually.
2) Has the benefit of eliminating some issues with the previous code as well. Such as...
a) Restoring RRD multiple times during boot, potentially at least 3 times, by rc.newwanip, rc.newwanipv6, and rc.boot. Some even overlapping.
b) Not removing the backups if/when not being utilized. Such as on a full install with the RAM disk option not enabled.
c) Eliminate some duplicate code.
3) Looking forward.
a) The more centrally system managed approach may crack the door open to making it easier to include some of the logs in the RAM disk store. As well as anything else that may be useful/desirable to retain in the RAM disk across reboots.
|
|
|
|
| |
have a CD/DVD Drive device. Fixes #6882
|
| |
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Included a checkbox to enable and disable this feature when CloudeFlare
type is selected.
Included proxied variable in the update script as well.
Defaults to false, as the is the current functionality
Added help text
Updated Last tested date
Hope this helps other people. I use both dynDNS and the Proxy service.
And by default without this feature, the proxy gets disabled. This
is a huge problem, as I have all traffic blocked except for CloudFlare.
And because I have certain other security features enabled, when the Proxy
goes disabled, The Site goes down hard to end users.
With this feature, I can ensure the proxy stays enabled.
|
| | |
|
| | |
|
| | |
|
|\ \ |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Exposes the underlying dhcpd configuration option "ignore-client-uids"
in the pfSense "Services / DHCP Server" GUI by adding an "Ignore client
identifiers" checkbox.
As of ISC dhcpd version 4.3.0+, there is a new configuration statement
available, "ignore-client-uids". According to the ISC's documentation,
"If the 'ignore-client-uids' statement is present and has a value of
'true' or 'on', the UID for clients will not be recorded."
While this behavior does not strictly adhere to the DHCP specification,
it can be very useful in environments where devices on the network
dual boot or PXE boot. Normally, if the network stacks in a single
device's different operating systems (including PXE firmware) make DHCP
requests with differing client identifiers, the server will treat each
request with a unique identifier as having come from a unique client,
even when they come from the same device. Thus, different operating
systems on the same device and NIC might hold different leases with
different IP addresses.
Once activated, the "ignore-client-uids" option tells the DHCP server
not to record client identifiers in new DHCP leases, which forces the
server to fall back on hardware (MAC) addresses to uniquely identify
clients. Now different operating systems on the same device and NIC
will hold the same lease (based on MAC address), which should keep
a device's IP address consistent regardless of its currently running
operating system.
Same as with most other general and pool-specific DHCP server options
in pfSense, note that turning on this option only affects new leases.
Any leases that existed prior to enabling this option will still
contain their respective client identifiers. Manually deleting older
leases or flushing the entire lease table can expedite a full
migration to the new server behavior, if desired.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
1) util.inc - add parameter to get_staticroutes() so the caller can
choose to see all static routes or only the ones that are currently
enabled.
2) filter.inc - just process enabled static routes when making direct
networks list, tonathosts etc.
3) services.inc - only include enabled static routes when making confogs
for DHCP(6) Relay.
4) unbound.inc - only include enable static routes in
unbound_acls_config
5) rc.newroutedns - only trigger if there is an enabled static route.
Note: GUI validation has been left as-is. e.g. in system_gateways we don
not allow to delete a gateway if there is a disabled static route using
it... If people want to delete "higher level" stuff, then they need to
first delete the disabled static route(s). Otherwise it will get rather
"risky" having disabled static routes in the config that refer to
gateways that no longer exist, or have a subnet range that now matches a
local interafce or...
|
|/ / |
|
| | |
|
| | |
|
|\ \ |
|
| | | |
|
| | |
| | |
| | |
| | | |
errors. Fixes #6838
|
| | | |
|
| | |
| | |
| | |
| | | |
It is relevant to the interface, not just the per-static-mapping DDNS config.
|
| | | |
|
| | | |
|
|\ \ \ |
|
| | | | |
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Reverted after upgrade dhcpd server to 4.3.5
This reverts commit 20350989db5d66ffb827beaed5ef5738cd62fc9d.
|
|/ / /
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
omits client-hostname where the cache threshold is reached. Ticket #6589"
Removed after upgrade dhcpd server to 4.3.5
This reverts commit 318e0383829daac934424879ccfce09395e80025.
|