Bug #7493
closedInput handling/error detection is testing old data fields (which should be ignored) when user changes an interface IP in GUI
100%
Description
Summary:
I'm trying out a new pfSense install for a home lab, in which I modified the interface IPv4 settings. When I tried to save the new IPv4 settings (which should have been valid), they wouldn't save due to issues related to the old values, even though those should have been ignored and were now in hidden fields on the webUI.
Detail:
The box has about 5 NICs, which I'll call NIC 0 through NIC 4. For simplicity I'll also use NIC {N} to refer, where relevant, to the interface on NIC {N}. I had the interfaces configured with static IPs (NIC 0 = 10.0.0.1/24, NIC 1 = 10.0.1.1/24, NIC 2 = 10.0.2.1/24, etc).
I then decided to reconfigure them as a bridge, leaving one NIC for a management port, so I deleted the gateway and picked one NIC (say NIC 5) to be used for management and NIC 0 through NIC 4 as a bridge.
To do this, I used "assign interface->bridge" to bridge NIC 0 to NIC 4 and deleted the gateways they had previously used. I then connected NIC 5 to my LAN and changed its interface to get an IP via DHCP; my main router's dhcpd assigned the management interface an IP of 10.100.0.5/8. Finally I went around the setup cleaning up any settings changes needed due to the change of use.
With NIC 0 through 4 now bridged, they obviously didn't need (and shouldn't have) IPs of their own. So I tried to set their IPv4's to "none". But it wouldn't let me, instead I got a validation error: "IPv4 address 10.0.{N}.1/24 [= old IP on NIC N] is being used by or overlaps with: MANAGEMENT_PORT (10.100.0.5/8)".
The issue is, that I was trying to remove the old IP because it was no longer needed. The webUI therefore shouldn't have detected the old value as an error. Essentially it's incorrectly testing the old value for inputs such as "NONE" and "DHCP" where the old value is still submitted, but in a hidden section because it's no longer relevant and to be ignored.
I can't quite figure what should happen, so hopefully this slightly confused explanation will help someone to fix it.
Updated by Phillip Davis over 7 years ago
What version?
(I made some changes to interfaces.php "workflow" recently in 2.4 - so it would be handy to know if I broke something, or if it is a problem in 2.3.3* and maybe I even (accidentally) have fixed it in 2.4)
Updated by Phillip Davis over 7 years ago
PR https://github.com/pfsense/pfsense/pull/3705
On that PR I describe an easier way to quickly demonstrate the general "bug" in processing validation of the entered IP address, without having to go through the whole process above of making a bridge setup.
The PR ends up fixing a few IP address validation cases.
This can be fixed in 2.3.3, 2.3.4 and 2.4
Updated by Phillip Davis over 7 years ago
- Status changed from New to Feedback
- % Done changed from 0 to 100
Applied in changeset 8c6190e82f83a7907ec2757e72d9a8eac496dd61.
Updated by Jim Pingle over 7 years ago
- Category set to Interfaces
- Status changed from Feedback to Resolved
- Target version set to 2.3.4
- Affected Version set to All
- Affected Architecture All added
- Affected Architecture deleted (
)