pfSense

I have done this to myself when braindead! It also allows x.x.x.255/24 - it should prohibit the 1st and last address of a subnet, unless a 31 or 32 mask is given. Needs to make sure to handle all unusual subnets - e.g. 192.168.2.16/28 and 192.168.2.31/28 are the beginning and end of a /28.

Applied in changeset 21d74c8e79948cd05c11f0ab79a463aea4bff2ce.

I did GitSync and tried this on the console. Here is some sample output:
@Enter an option: 2

Available interfaces:

1 - WAN (vr2 - dhcp, dhcp6)
2 - LAN (vr0 - static)

Enter the number of the interface you wish to configure: 2

Enter the new LAN IPv4 address. Press <ENTER> for none:

192.168.48.0

Subnet masks are entered as bit counts (as in CIDR notation) in pfSense.
e.g. 255.255.255.0 = 24
255.255.0.0 = 16
255.0.0.0 = 8

Enter the new LAN IPv4 subnet bit count:

24

You cannot set network address to an interface
Enter the new LAN IPv4 subnet bit count:

20

You cannot set network address to an interface
Enter the new LAN IPv4 subnet bit count:

19

Enter the new LAN IPv4 gateway address. Press <ENTER> for none:

Enter the new LAN IPv6 address. Press <ENTER> for none:

Do you want to enable the DHCP server on LAN? [y|n] y
Enter the start address of the IPv4 client address range: 10.30.20.0
Enter the end address of the IPv4 client address range: 10.30.20.99
Disabling DHCPD...Done!

Do you want to revert to HTTP as the webConfigurator protocol? (y/n) n

Please wait while the changes are saved to LAN... Reloading filter...
DHCPD...

The IPv4 LAN address has been set to 192.168.48.0/19
You can now access the webConfigurator by opening the following URL in your web browser:
https://192.168.48.0/

Press <ENTER> to continue.
@
After putting in the bad data (192.168.48.0/24) it gives the error message, but just prompts again for the subnet bit count. There is no easy or obvious way to get back to the IPv4 address prompt to correct the real problem. I faked it by purring a bigger subnet bit count until 192.168.48.0 was no longer the bottom end network address. Of course the user can also press ctrl-C.
Might be easier to ask for the network and mask all in 1 prompt - I think users are quite used to entering syntax like 192.168.48.1/24 all in 1 prompt these days. Then it can be validated straight away and easily re-prompt if the input is invalid.

As a side-issue, I purposely put in dodgy values for the DHCP - outside of the subnet I had specified - and was surprised that it did not complain. Should the DHCP range also be validated and forced to be inside the specified subnet? Or is there some use case here with DHCP-relay where the user might have a real need at the console to set a DHCP range outside the subnet?

Latest changes for the console work nicely - it re-prompts for the IPv4 address when the address and netmask combination are invalid. One little cut-paste bug in validating the DHCP range, fixed by https://github.com/pfsense/pfsense/pull/861

I can't break it now - the console interface is validating lots of IP subnet and DHCP range stuff... Since I did the latest couple of code changes, maybe someone else should give it a spin for an independent test.