| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
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.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
On dc61252ae the code used to restore dhcp6 leases when platform was
nanobsd was removed, but this code is supposed to run on full install
when it's configured to use MFS /tmp. Restored it, adjusting indent,
and add the correct conditional to run on MFS /tmp
Spotted-by: @phil-davis
|
| | | | |
|
| | | | |
|
| |/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| |/ |
|
| |\ |
|
| | |
| |
| |
| | |
This way kill and respawn will behave as they should for the dhcpd processes
|
| |\ \ |
|
| | |/ |
|
| |\ \ |
|
| | | | |
|
| | | |
| | |
| | |
| | | |
It is a little bit tricky having to generate the unique "option custom-if-n-m code ..." lines at first where n = pool index and m = item index in the items of the pool. Then make sure to reference that later, getting the same pool index into the array of pools. The $all_pools array as the "overall" or "base" pool first (at index 0), followed by the user-specified pools at index 1, 2, 3,... - which are actually at indexes 0, 1, 2,... in the ordinary array of pools in the config. So the -1 at line 910 has to happen.
But it works for me.
|
| |\ \ \
| |_|/
|/| | |
|
| | |/
| |
| |
| |
| | |
Add a pool and specify something in 1 or more of the DNS servers boxes for the pool.
The "option domain-name-servers 1.2.3.4" line appears twice in dhcpd.conf
The first bit of code to do it is at lines 787-799. I have deleted this 2nd time that it is done at lines 854-856.
|
| |/
|
|
| |
default config which would override our command line parameters. Fixes #6730
|
| |
|
|
| |
If you specify DDNS Domain in a DHCP static map entry, it does not make its way through to dhcpd.conf
This is because the var name $pdnscfg is wrong from an old copy-paste that first made this code.
|
