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:
parent
b1a2762ecf
commit
5a3d3b8055
@ -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)
|
||||
|
Loading…
Reference in New Issue
Block a user