busybox-w32/networking/udhcp, branch cron_changes

*: placate warnings where strchr/strstr returns constant pointer

2026-02-15T14:15:30+00:00

Newer glibc is now smarter and can propagate const-ness from those! function old new delta readtoken1 3111 3108 -3 Signed-off-by: Denys Vlasenko

networking/udhcp: fix typo in comment

2026-01-14T07:08:26+00:00

Signed-off-by: Giorgi Tchankvetadze Signed-off-by: Denys Vlasenko

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

udhcpc6: fix copy-paste error in "generate a consistent IAID" commit

2025-02-09T14:09:15+00:00

Signed-off-by: Denys Vlasenko

udhcpc6: generate a consistent IAID

2025-02-09T12:51:33+00:00

Currently, udhcpc6 does not meet the requirements for Identity Association in RFC 3315. This is a specific explanation in RFC 3315 protocol: https://datatracker.ietf.org/doc/html/rfc3315#section-10 "The IAID uniquely identifies the IA and must be chosen to be unique among the IAIDs on the client. The IAID is chosen by the client. For any given use of an IA by the client, the IAID for that IA MUST be consistent across restarts of the DHCP client." This patch makes the client generate a consistent IAID based on the MAC address. function old new delta send_d6_discover 285 270 -15 Signed-off-by: Zhou Siqi Signed-off-by: Denys Vlasenko

udhcpc6: move block comment, no code changes

2025-02-09T11:54:50+00:00

Signed-off-by: Denys Vlasenko

udhcpc6: improvements

2025-02-09T11:52:02+00:00

Several small improvements to udhcpc6. - Remove usage text for the nonexistent -B option. - Fix a segfault when renewing an IA_PD lease without IA_NA (which means the client hasn't been assigned an ip, so we cannot locally bind to it). - Fix NAK management: check the option length, and print the status code and status message - Add a -m option to always send renew requests as multicast. These last two changes are useful to deal with hopelessly broken DHCPv6 servers such as the one from the Orange Livebox (one of the main French ISPs) which I'm currently having the displeasure to have to talk to, hence the patch. function old new delta static.send_d6_renew - 126 +126 .rodata 105598 105649 +51 udhcpc6_main 2607 2650 +43 packed_usage 34933 34953 +20 d6_send_kernel_packet_from_client_data_ifindex 266 282 +16 send_d6_renew 174 - -174 ------------------------------------------------------------------------------ (add/remove: 1/1 grow/shrink: 4/0 up/down: 256/-174) Total: 82 bytes Signed-off-by: Laurent Bercot Signed-off-by: Denys Vlasenko

typo fix

2024-06-01T08:51:58+00:00

Signed-off-by: Denys Vlasenko

libbb: add bit counting function, use where appropriate

2024-05-31T14:03:23+00:00

Although "naive" counting function is not too slow and is smaller, using it on e.g. each of 1024 words of CPU mask feels wrong. function old new delta bb_popcnt_32 - 52 +52 get_prefix 323 321 -2 nproc_main 206 199 -7 d4_run_script 739 731 -8 ipcalc_main 533 507 -26 ------------------------------------------------------------------------------ (add/remove: 2/0 grow/shrink: 0/4 up/down: 52/-43) Total: 9 bytes Signed-off-by: Denys Vlasenko

udhcp: Avoid leaking uninitialized/stale data

2023-10-04T14:46:35+00:00

I noticed a commit in connman: "gdhcp: Avoid leaking stack data via unitiialized variable" [1] Since gdhcp is just BusyBox udhcp with the serial numbers filed off, I checked if BusyBox udhcp has a related issue. The issue is that the get_option logic assumes any data within the memory area of the buffer is "valid". This reduces the complexity of the function at the cost of reading past the end of the actually received data in the case of specially crafted packets. This is not a problem for the udhcp_recv_kernel_packet data path as the entire memory area is zeroed. However, d4/d6_recv_raw_packet does not zero the memory. Note that a related commit [2] is not required as we are zeroing any data that can be read by the get_option function. [1] https://git.kernel.org/pub/scm/network/connman/connman.git/commit/?id=a74524b3e3fad81b0fd1084ffdf9f2ea469cd9b1 [2] https://git.kernel.org/pub/scm/network/connman/connman.git/commit/?id=58d397ba74873384aee449690a9070bacd5676fa function old new delta d4_recv_raw_packet 484 497 +13 d6_recv_raw_packet 216 228 +12 .rodata 105390 105381 -9 ------------------------------------------------------------------------------ (add/remove: 0/0 grow/shrink: 2/1 up/down: 25/-9) Total: 16 bytes Signed-off-by: Russ Dill Cc: Colin Wee Cc: Denys Vlasenko Signed-off-by: Denys Vlasenko