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

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

udhcp: add a few comments, no code changes

2022-12-15T12:34:52+00:00

Signed-off-by: Denys Vlasenko

udhcpc: improve logs - show offer as it is received

2021-06-02T17:51:52+00:00

function old new delta udhcpc_main 2566 2608 +42 .rodata 103248 103272 +24 udhcp_recv_raw_packet 559 562 +3 d6_recv_raw_packet 254 255 +1 ------------------------------------------------------------------------------ (add/remove: 0/0 grow/shrink: 4/0 up/down: 70/0) Total: 70 bytes 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

gcc-9.x warning fixes

2020-10-01T01:07:22+00:00

Signed-off-by: Denys Vlasenko

libbb: reduce the overhead of single parameter bb_error_msg() calls

2019-07-02T09:35:03+00:00

Back in 2007, commit 0c97c9d43707 ("'simple' error message functions by Loic Grenie") introduced bb_simple_perror_msg() to allow for a lower overhead call to bb_perror_msg() when only a string was being printed with no parameters. This saves space for some CPU architectures because it avoids the overhead of a call to a variadic function. However there has never been a simple version of bb_error_msg(), and since 2007 many new calls to bb_perror_msg() have been added that only take a single parameter and so could have been using bb_simple_perror_message(). This changeset introduces 'simple' versions of bb_info_msg(), bb_error_msg(), bb_error_msg_and_die(), bb_herror_msg() and bb_herror_msg_and_die(), and replaces all calls that only take a single parameter, or use something like ("%s", arg), with calls to the corresponding 'simple' version. Since it is likely that single parameter calls to the variadic functions may be accidentally reintroduced in the future a new debugging config option WARN_SIMPLE_MSG has been introduced. This uses some macro magic which will cause any such calls to generate a warning, but this is turned off by default to avoid use of the unpleasant macros in normal circumstances. This is a large changeset due to the number of calls that have been replaced. The only files that contain changes other than simple substitution of function calls are libbb.h, libbb/herror_msg.c, libbb/verror_msg.c and libbb/xfuncs_printf.c. In miscutils/devfsd.c, networking/udhcp/common.h and util-linux/mdev.c additonal macros have been added for logging so that single parameter and multiple parameter logging variants exist. The amount of space saved varies considerably by architecture, and was found to be as follows (for 'defconfig' using GCC 7.4): Arm: -92 bytes MIPS: -52 bytes PPC: -1836 bytes x86_64: -938 bytes Note that for the MIPS architecture only an exception had to be made disabling the 'simple' calls for 'udhcp' (in networking/udhcp/common.h) because it made these files larger on MIPS. Signed-off-by: James Byrne Signed-off-by: Denys Vlasenko

Optionally re-introduce bb_info_msg()

2019-04-30T08:51:27+00:00

Between Busybox 1.24.2 and 1.25.0 the bb_info_msg() function was eliminated and calls to it changed to be bb_error_msg(). The downside of this is that daemons now log all messages to syslog at the LOG_ERR level which makes it hard to filter errors from informational messages. This change optionally re-introduces bb_info_msg(), controlled by a new option FEATURE_SYSLOG_INFO, restores all the calls to bb_info_msg() that were removed (only in applets that set logmode to LOGMODE_SYSLOG or LOGMODE_BOTH), and also changes informational messages in ifplugd and ntpd. The code size change of this is as follows (using 'defconfig' on x86_64 with gcc 7.3.0-27ubuntu1~18.04) function old new delta bb_info_msg - 182 +182 bb_vinfo_msg - 27 +27 static.log7 194 198 +4 log8 190 191 +1 log5 190 191 +1 crondlog 45 - -45 ------------------------------------------------------------------------------ (add/remove: 2/1 grow/shrink: 3/0 up/down: 215/-45) Total: 170 bytes If you don't care about everything being logged at LOG_ERR level then when FEATURE_SYSLOG_INFO is disabled Busybox actually gets smaller: function old new delta static.log7 194 200 +6 log8 190 193 +3 log5 190 193 +3 syslog_level 1 - -1 bb_verror_msg 583 581 -2 crondlog 45 - -45 ------------------------------------------------------------------------------ (add/remove: 0/2 grow/shrink: 3/1 up/down: 12/-48) Total: -36 bytes Signed-off-by: James Byrne Signed-off-by: Denys Vlasenko

udhcpc: remove code which requires server ID to be on local network

2018-06-21T15:38:14+00:00

This reverts "udhcpc: paranoia when using kernel UDP mode for sending renew: server ID may be bogus". Users complain that they do have servers behind routers (with DHCP relays). function old new delta send_packet 168 166 -2 bcast_or_ucast 25 23 -2 udhcp_send_kernel_packet 301 295 -6 ------------------------------------------------------------------------------ (add/remove: 0/0 grow/shrink: 0/3 up/down: 0/-10) Total: -10 bytes Signed-off-by: Denys Vlasenko

udhcpc[6]: make log2 messages for chaddr field indented like the rest

2017-09-29T16:02:01+00:00

Signed-off-by: Denys Vlasenko

udhcpc: paranoia when using kernel UDP mode for sending renew: server ID may be bogus

2017-09-29T14:02:11+00:00

With new code, we request that target IP (server ID) must be directly reachable. If it's not, this happens: udhcpc: waiting 2000 seconds udhcpc: entering listen mode: kernel udhcpc: opening listen socket on *:68 wlan0 udhcpc: entering renew state udhcpc: sending renew to 1.1.1.1 udhcpc: send: Network is unreachable ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 1.1.1.1 needs routing, this is fishy! udhcpc: entering rebinding state udhcpc: entering listen mode: raw udhcpc: created raw socket udhcpc: sending renew to 0.0.0.0 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ going to use broadcast which is the desired behavior. Before the patch, packet to 1.1.1.1 was routed over eth0 (!) and maybe even into Internet (!!!). function old new delta udhcpc_main 2752 2763 +11 udhcp_send_kernel_packet 295 301 +6 send_renew 82 84 +2 send_packet 166 168 +2 bcast_or_ucast 23 25 +2 ------------------------------------------------------------------------------ (add/remove: 0/0 grow/shrink: 5/0 up/down: 23/0) Total: 23 bytes Signed-off-by: Denys Vlasenko