| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
an additional pool
|
| |
|
| |
|
|
|
|
| |
disabling DHCP server
|
| |
|
| |
|
| |
|
| |
|
| |
|
|\ |
|
| | |
|
|/
|
|
|
|
|
| |
1) Strictly keep track of the accumulating $retval from calls to various
functions that apply changes.
2) Use new function print_apply_result_box() to print a suitable message
in a suitable severity based on $retval
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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) Add alias and host types to Form_IpAddress with the appropriate hover
text.
2) Remove the patterns - the UI of those is not so effective anyway, so
leave the validation of input to the back end.
3) Update uses of Form_IpAddress to use the appropriate Alias or Host
type as needed.
4) Remove explicit setPattern() from those uses of Form_IpAddress.
|
| | | |
|
| | | |
|
| | | |
|
| |/
|/| |
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Part of Redmine #6997
1) Display the DHCP Server settings even when DHCP Relay is enabled, but
disable the "enable" checkbox in this case - so the user cannot enable
DHCP Server when DHCP Relay is enabled, but can view and modify the DHCP
Server parameters (ready for the day they want to use it).
2) Actually validate the POSTed DHCP Server parameters, even if it is
disabled. Previously you could put rubbish values in fields and they
would be "happily" saved when DHCP Server was disabled. We want users to
be able to setup DHCP Server ready-to-enable and knowing that they have
put validated stuff in.
3) When DHCP Server is disabled, allow Range From and Range To to be
left empty. When first setting up parameters (e.g. with the UI page up
for the first time) it is OK for the user to be able to just press
"Save". e.g. they are just pressing Save as a way to get out (as if it
is a Cancel button). We do not need to force them to enter range from/to
IP addresses.
|
| |
|
| |
|
| |
|
|
|
|
| |
The input pattern that goes with Form_IpAddress by default allows for IPv4 and IPv6 valid characters. The back-end validation here is checking for IPv4 addresses, so it seems reasonable that the front-end input pattern checks might as well be restricted to the IPv4 valid characters. Unneeded setPattern have also been removed.
The exception is Gateway, where the special string "none" is allowed, so I just left the setPattern as it is (yes, it could be modified to only allow the letters "n" "o" and "e").
|
|\ |
|
| |
| |
| |
| |
| |
| |
| | |
Also removes the ability to have underscores `_` in ntp server
FQDNs.
Closes #6806
|
| | |
|
|/
|
|
| |
mapping entries. Fixes #6821
|
| |
|
|\ |
|
| |
| |
| | |
The setPattern() thing ain't usable for this and just causes regressions.
|
| | |
|
| |
| |
| | |
is_URL() from util.inc is way too limited for this purpose.
|
|/
|
|
|
|
|
|
|
| |
BOOTP leases do not have a maximum lease time by default, this could
potentially lead to a DHCP address pool exhaustion.
This commit adds an option to ignore BOOTP queries.
Redmine #4351
|
| |
|
| |
|
| |
|
|
|
| |
This one moves the "Network Booting" above the "Additional BOOTP/DHCP Options". That allows "Network Booting" to be a Display/Hide Advanced group of buttons just like TFTP, LDAP etc. (without a special section header) and for "Additional BOOTP/DHCP Options" to come last on the page.
|
|
|
|
|
|
|
|
|
| |
The usage of require() and require_once() throughout the system is
inconsistent, and "bugs" come up now and then when the order of
"requires" is a bit different and some require() happens after the
include file is already included/required.
It seems to me that there is no harm at all in always using
require_once().
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Clean up some services menu punctuation.
|
|
|
|
| |
It reads as though the interfaces IP address is to be entered. Removing "use" makes it a little clearer.
|
|
|
|
| |
Remove "you" personalizations.
|
|
|
|
|
|
| |
As per what was done for https://github.com/pfsense/pfsense/pull/2765 -
do it to the rest of them.
Seems to work OK.
|
|
|
|
| |
Error: The align attribute on the td element is obsolete. Use CSS instead.
|