summaryrefslogtreecommitdiff
path: root/coreutils/chmod.c
diff options
context:
space:
mode:
authorSeth David Schoen2021-02-03 16:19:18 -0800
committerDenys Vlasenko2021-06-03 20:30:13 +0200
commit5a3d3b8055f684539f05e00c38fdc5cefb94c883 (patch)
treed731f3ff2c74adc23121350dbcfc21522a665586 /coreutils/chmod.c
parentb1a2762ecfe3d0f7c953abe4c48eb0582303c197 (diff)
downloadbusybox-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/chmod.c')
0 files changed, 0 insertions, 0 deletions