udhcpd: don't hardcode treating .0 and .255 specially

Even following current Internet standards, it can be perfectly
legitimate to issue IPv4 addresses that end in .0 or .255 via DHCP --
this can happen whenever the network is larger than /8.  For example,
10.3.4.0 and 10.3.4.255 are legitimate host addresses in 10/8 or 10.3/16.
(We also want to be able to issue .0 addresses in smaller networks
following our proposed kernel patch and standards changes.)

This behavior is already fully controllable by the user, simply by
setting start_ip and end_ip correctly.  Users who don't want to issue
.0 or .255 should set start_ip greater than .0 or end_ip less than .255
and udhcpd will already respect these bounds.  (This is also the case
for other DHCP servers -- the recommended example configurations will
default to a lower bound starting with .1 or some other value, which is
typically appropriate, but the user is still allowed to change this to
.0 -- or to a range that overlaps a .0 or .255 address -- if so desired.)

Signed-off-by: Seth David Schoen <schoen@loyalty.org>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
This commit is contained in:
Seth David Schoen 2021-02-03 16:19:18 -08:00 committed by Denys Vlasenko
parent b1a2762ecf
commit 5a3d3b8055

View File

@ -295,12 +295,11 @@ static uint32_t find_free_or_expired_nip(const uint8_t *safe_mac, unsigned arppi
uint32_t nip;
struct dyn_lease *lease;
/* ie, 192.168.55.0 */
if ((addr & 0xff) == 0)
goto next_addr;
/* ie, 192.168.55.255 */
if ((addr & 0xff) == 0xff)
goto next_addr;
/* (Addresses ending in .0 or .255 can legitimately be allocated
* in various situations, so _don't_ skip these. The user needs
* to choose start_ip and end_ip correctly for a particular
* network environment.) */
nip = htonl(addr);
/* skip our own address */
if (nip == server_data.server_nip)