diff options
author | Seth David Schoen | 2021-02-03 16:19:18 -0800 |
---|---|---|
committer | Denys Vlasenko | 2021-06-03 20:30:13 +0200 |
commit | 5a3d3b8055f684539f05e00c38fdc5cefb94c883 (patch) | |
tree | d731f3ff2c74adc23121350dbcfc21522a665586 /coreutils/readlink.c | |
parent | b1a2762ecfe3d0f7c953abe4c48eb0582303c197 (diff) | |
download | busybox-5a3d3b8055f684539f05e00c38fdc5cefb94c883.zip busybox-5a3d3b8055f684539f05e00c38fdc5cefb94c883.tar.gz |
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>
Diffstat (limited to 'coreutils/readlink.c')
0 files changed, 0 insertions, 0 deletions