busybox-w32/networking/udhcp/dhcpd.c, branch zstd

udhcpd: send DHCPOFFERs as unicast (unless clients specifically asks for bcast)

2025-04-07T00:46:39+00:00

RFC 2131 says we should do that. Evidently, since for so many years no one complained, sending them broadcast works too, but finally we've got someone who wants RFC-compliand behavior. function old new delta send_packet 141 179 +38 .rodata 105680 105681 +1 ------------------------------------------------------------------------------ (add/remove: 0/0 grow/shrink: 2/0 up/down: 39/0) Total: 39 bytes Signed-off-by: Denys Vlasenko

udhcpd: optional BOOTP support

2023-06-12T11:22:47+00:00

from Adam Goldman This patch makes udhcpd respond correctly to queries from BOOTP clients. It contains the following changes: The end field, or DHCP_END option, is required in DHCP requests but optional in BOOTP requests. However, we still send an end field in all replies, because some BOOTP clients expect one in replies even if they didn't send one in the request. Requests without a DHCP_MESSAGE_TYPE are recognized as BOOTP requests and handled appropriately, instead of being discarded. We still require an RFC 1048 options field, but we allow it to be empty. Since a BOOTP client will keep using the assigned IP forever, we only send a BOOTP reply if a static lease exists for that client. BOOTP replies shouldn't contain DHCP_* options, so we omit them if there was no DHCP_MESSAGE_TYPE in the request. Options other than DHCP_* options are still sent. The options field of a BOOTP reply must be exactly 64 bytes. If we construct a reply with more than 64 bytes of options, we give up and log an error instead of sending it. udhcp_send_raw_packet already pads the options field to 64 bytes if it is too short. This implementation has been tested against an HP PA-RISC client. function old new delta .rodata 105247 105321 +74 udhcpd_main 1520 1591 +71 send_offer 419 470 +51 init_packet 81 97 +16 udhcp_init_header 75 88 +13 udhcp_scan_options 192 203 +11 ------------------------------------------------------------------------------ (add/remove: 0/0 grow/shrink: 6/0 up/down: 236/0) Total: 236 bytes Signed-off-by: Denys Vlasenko

udhcpc6: fix udhcp_find_option to actually find DHCP6 options

2021-12-12T16:13:54+00:00

udhcp_insert_new_option treats code for IPv6 as follows: new->data[D6_OPT_CODE] = code >> 8; new->data[D6_OPT_CODE + 1] = code & 0xff; udhcp_find_option tests the code as follows: while (opt_list && opt_list->data[OPT_CODE] < code) ... if (opt_list && opt_list->data[OPT_CODE] == code) So yes, OPT_CODE and D6_OPT_CODE are both 0, but the D6_OPT_CLIENTID = 1 value means that the 1 is in the seconds byte, and udhcp_find_option is only looking at the first byte, So the send_d6_release can never find it the created option. function old new delta udhcp_find_option 28 53 +25 attach_option 276 284 +8 udhcpc6_main 2602 2607 +5 perform_d6_release 262 267 +5 udhcpd_main 1518 1520 +2 udhcpc_main 2542 2544 +2 add_serverid_and_clientid_options 46 48 +2 ------------------------------------------------------------------------------ (add/remove: 0/0 grow/shrink: 7/0 up/down: 49/0) Total: 49 bytes Signed-off-by: Denys Vlasenko

udhcp: clarify aspects of relay operation, add TODOs and FIXMEs, tweak --help

2021-09-02T14:24:52+00:00

function old new delta packed_usage 33891 33920 +29 dhcprelay_main 943 926 -17 ------------------------------------------------------------------------------ (add/remove: 0/0 grow/shrink: 1/1 up/down: 29/-17) Total: 12 bytes Signed-off-by: Denys Vlasenko

udhcpd: check config file for bad IP ranges (start > end)

2021-09-02T12:40:54+00:00

function old new delta .rodata 104209 104238 +29 read_config 208 225 +17 ------------------------------------------------------------------------------ (add/remove: 0/0 grow/shrink: 2/0 up/down: 46/0) Total: 46 bytes Signed-off-by: Denys Vlasenko

udhcpd: update --help to include -a MSEC

2021-09-02T12:02:23+00:00

function old new delta packed_usage 33886 33891 +5 Signed-off-by: Denys Vlasenko

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

2021-06-03T18:30:13+00:00

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 Signed-off-by: Denys Vlasenko

udhcp: reuse strings

2021-02-21T15:32:07+00:00

text data bss dec hex filename 1019916 559 5020 1025495 fa5d7 busybox_old 1019906 559 5020 1025485 fa5cd busybox_unstripped Signed-off-by: Denys Vlasenko

help text: use -P PORT form

2020-12-18T21:51:46+00:00

function old new delta packed_usage 33502 33491 -11 Signed-off-by: Denys Vlasenko

udhcp: bind to device even for ucast packets

2020-12-15T20:44:21+00:00

There are cases where binding to source IP and destination IP is insufficient to guarantee sane xmit netdev. One case where this can fail is when route-matching netdev carrier is down (cable unplugged, wifi disconnected), or the netdev is admin down. Then all the IP based bindings (bind() + connect()) will seemingly succeed but the actual packet can go out through a default gw path. Depending on the network this happens on it can create issues or false alarms. It can also leak some subnet info across networks that shouldn't be routed. As such better be safe than sorry and bind to a netdev to be sure it's used for xmit. function old new delta udhcp_send_kernel_packet 293 336 +43 send_packet 182 188 +6 bcast_or_ucast 37 43 +6 ------------------------------------------------------------------------------ (add/remove: 0/0 grow/shrink: 3/0 up/down: 55/0) Total: 55 bytes Signed-off-by: Michal Kazior Signed-off-by: Denys Vlasenko