Add support for the PXELINUX options 209 ("ConfigFile") and 210
("PathPrefix") in the DHCPv6 client.
See also: RFC5071, "Dynamic Host Configuration Protocol Options Used by
PXELINUX".
Signed-off-by: Samuel Mendoza-Jonas <sam@mendozajonas.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Add support for 'bootfile-url' and 'bootfile-params' as defined by
RFC5970 "DHCPv6 Options for Network Boot".
Signed-off-by: Samuel Mendoza-Jonas <sam@mendozajonas.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Add string_option_to_env() to easily generate environment variables for
known simple options.
Signed-off-by: Samuel Mendoza-Jonas <sam@mendozajonas.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
trim() modifies the string in place if needed and returns a pointer to
the end of the resulting string. Update udhcp_str2optset() so it no
longer sets the value of 'val' to the return value of trim().
Signed-off-by: Samuel Mendoza-Jonas <sam@mendozajonas.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
EINTR _should_ only happen on two signals we trap, and safe_poll
_should_ work here just fine, but there were kernel bugs where spurious EINTRs
happen (e.g. on ptrace attach). Be safe.
function old new delta
udhcpd_main 1437 1468 +31
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Fixes:
commit 52a515d187
"udhcp: use poll() instead of select()"
Feb 16 2017
udhcp_sp_read() is meant to check whether signal pipe indeed has some data to read.
In the above commit, it was changed as follows:
- if (!FD_ISSET(signal_pipe.rd, rfds))
+ if (!pfds[0].revents)
return 0;
The problem is, the check was working for select() purely by accident.
Caught signal interrupts select()/poll() syscalls, they return with EINTR
(regardless of SA_RESTART flag in sigaction). _Then_ signal handler is invoked.
IOW: they can't see any changes to fd state caused by signal haldler
(in our case, signal handler makes signal pipe ready to be read).
For select(), it means that rfds[] bit array is unmodified, bit of signal
pipe's read fd is still set, and the above check "works": it thinks select()
says there is data to read.
This accident does not work for poll(): .revents stays clear, and we do not
try reading signal pipe as we should. In udhcpd, we fall through and block
in socket read. Further SIGTERM signals simply cause socket read to be
interrupted and then restarted (since SIGTERM handler has SA_RESTART=1).
Fixing this as follows: remove the check altogether. Set signal pipe read fd
to nonblocking mode. Always read it in udhcp_sp_read().
If read fails, assume it's EAGAIN and return 0 ("no signal seen").
udhcpd avoids reading signal pipe on every recvd packet by looping if EINTR
(using safe_poll()) - thus ensuring we have correct .revents for all fds -
and calling udhcp_sp_read() only if pfds[0].revents!=0.
udhcpc performs much fewer reads (typically it sleeps >99.999% of the time),
there is no need to optimize it: can call udhcp_sp_read() after each poll
unconditionally.
To robustify socket reads, unconditionally set pfds[1].revents=0
in udhcp_sp_fd_set() (which is before poll), and check it before reading
network socket in udhcpd.
TODO:
This might still fail: if pfds[1].revents=POLLIN, socket read may still block.
There are rare cases when select/poll indicates that data can be read,
but then actual read still blocks (one such case is UDP packets with
wrong checksum). General advise is, if you use a poll/select loop,
keep all your fds nonblocking.
Maybe we should also do that to our network sockets?
function old new delta
udhcp_sp_setup 55 65 +10
udhcp_sp_fd_set 54 60 +6
udhcp_sp_read 46 36 -10
udhcpd_main 1451 1437 -14
udhcpc_main 2723 2708 -15
------------------------------------------------------------------------------
(add/remove: 0/0 grow/shrink: 2/3 up/down: 16/-39) Total: -23 bytes
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Since bb_info_msg() was eliminated type of buffering on stdout is not important
function old new delta
udhcpd_main 1463 1451 -12
udhcpc_main 2735 2723 -12
setlinebuf 19 - -19
------------------------------------------------------------------------------
(add/remove: 0/2 grow/shrink: 0/2 up/down: 0/-43) Total: -43 bytes
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
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 <vda.linux@googlemail.com>
I see random field values like sll_hatype=0x267 when I strace.
They seem to not matter, but just in case they sometimes do,
let's at least have deterministic values (via memset(0)).
function old new delta
change_listen_mode 308 322 +14
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
FEATURE_GETOPT_LONG made dependent on LONG_OPTS.
The folloving options are removed, now LONG_OPTS enables long options
for affected applets:
FEATURE_ENV_LONG_OPTIONS FEATURE_EXPAND_LONG_OPTIONS
FEATURE_UNEXPAND_LONG_OPTIONS FEATURE_MKDIR_LONG_OPTIONS
FEATURE_MV_LONG_OPTIONS FEATURE_RMDIR_LONG_OPTIONS
FEATURE_ADDGROUP_LONG_OPTIONS FEATURE_ADDUSER_LONG_OPTIONS
FEATURE_HWCLOCK_LONG_OPTIONS FEATURE_NSENTER_LONG_OPTS
FEATURE_CHCON_LONG_OPTIONS FEATURE_RUNCON_LONG_OPTIONS
They either had a small number of long options, or their long options are
essential.
Example: upstream addgroup and adduser have ONLY longopts,
we should probably go further and get rid
of non-standard short options.
To this end, make addgroup and adduser "select LONG_OPTS".
We had this breakage caused by us even in our own package!
#if ENABLE_LONG_OPTS || !ENABLE_ADDGROUP
/* We try to use --gid, not -g, because "standard" addgroup
* has no short option -g, it has only long --gid.
*/
argv[1] = (char*)"--gid";
#else
/* Breaks if system in fact does NOT use busybox addgroup */
argv[1] = (char*)"-g";
#endif
xargs: its lone longopt no longer depends on DESKTOP, only on LONG_OPTS.
hwclock TODO: get rid of incompatible -t, -l aliases to --systz, --localtime
Shorten help texts by omitting long option when short opt alternative exists.
Reduction of size comes from the fact that store of an immediate
(an address of longopts) to a fixed address (global variable)
is a longer insn than pushing that immediate or passing it in a register.
This effect is CPU-agnostic.
function old new delta
getopt32 1350 22 -1328
vgetopt32 - 1318 +1318
getopt32long - 24 +24
tftpd_main 562 567 +5
scan_recursive 376 380 +4
collect_cpu 545 546 +1
date_main 1096 1095 -1
hostname_main 262 259 -3
uname_main 259 255 -4
setpriv_main 362 358 -4
rmdir_main 191 187 -4
mv_main 562 558 -4
ipcalc_main 548 544 -4
ifenslave_main 641 637 -4
gzip_main 192 188 -4
gunzip_main 77 73 -4
fsfreeze_main 81 77 -4
flock_main 318 314 -4
deluser_main 337 333 -4
cp_main 374 370 -4
chown_main 175 171 -4
applet_long_options 4 - -4
xargs_main 894 889 -5
wget_main 2540 2535 -5
udhcpc_main 2767 2762 -5
touch_main 436 431 -5
tar_main 1014 1009 -5
start_stop_daemon_main 1033 1028 -5
sed_main 682 677 -5
script_main 1082 1077 -5
run_parts_main 330 325 -5
rtcwake_main 459 454 -5
od_main 2169 2164 -5
nl_main 201 196 -5
modprobe_main 773 768 -5
mkdir_main 160 155 -5
ls_main 568 563 -5
install_main 773 768 -5
hwclock_main 411 406 -5
getopt_main 622 617 -5
fstrim_main 256 251 -5
env_main 198 193 -5
dumpleases_main 635 630 -5
dpkg_main 3991 3986 -5
diff_main 1355 1350 -5
cryptpw_main 233 228 -5
cpio_main 593 588 -5
conspy_main 1135 1130 -5
chpasswd_main 313 308 -5
adduser_main 887 882 -5
addgroup_main 416 411 -5
ftpgetput_main 351 345 -6
get_terminal_width_height 242 234 -8
expand_main 690 680 -10
static.expand_longopts 18 - -18
static.unexpand_longopts 27 - -27
mkdir_longopts 28 - -28
env_longopts 30 - -30
static.ifenslave_longopts 34 - -34
mv_longopts 46 - -46
static.rmdir_longopts 48 - -48
packed_usage 31739 31687 -52
------------------------------------------------------------------------------
(add/remove: 2/8 grow/shrink: 3/49 up/down: 1352/-1840) Total: -488 bytes
text data bss dec hex filename
915681 485 6880 923046 e15a6 busybox_old
915428 485 6876 922789 e14a5 busybox_unstripped
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Move first two messages to log2 level:
08:46:32.23824 udhcpc: opening raw socket on ifindex 2
08:46:32.23825 udhcpc: got raw socket fd
08:46:32.26354 udhcpc: created raw socket
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Basedon patch by Bernd Holzmüller <bernd.holzmueller@tiggerswelt.net>
function old new delta
option_to_env 504 580 +76
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Patch is based on work by tiggerswelt.net. They say:
"
We wanted udhcpc6 to release its IPv6-Addresses on
quit (-R-commandline-option) which turned out to generate once again
kind of garbage on the network-link.
We tracked this down to two issues:
- udhcpc6 uses a variable called "srv6_buf" to send packets to
the dhcp6-server, but this variable is never initialized correctly
and contained kind of a garbage-address
- The address of the dhcp6-server is usually a link-local-address,
that requires an interface-index when using connect() on an AF_INET6-
socket
We added an
additional parameter for ifindex to d6_send_kernel_packet() and made
d6_recv_raw_packet() to capture the address of the dhcp6-server and
forward it to its callee.
"
Three last patches together:
function old new delta
d6_read_interface - 454 +454
d6_recv_raw_packet - 283 +283
option_to_env 249 504 +255
.rodata 165226 165371 +145
send_d6_discover 195 237 +42
send_d6_select 118 159 +41
send_d6_renew 173 186 +13
send_d6_release 162 173 +11
opt_req - 10 +10
d6_send_kernel_packet 304 312 +8
opt_fqdn_req - 6 +6
d6_mcast_from_client_config_ifindex 48 51 +3
d6_find_option 63 61 -2
udhcpc6_main 2416 2411 -5
static.d6_recv_raw_packet 266 - -266
------------------------------------------------------------------------------
(add/remove: 5/1 grow/shrink: 8/2 up/down: 1271/-273) Total: 998 bytes
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Patch is based on work by tiggerswelt.net. They say:
"
But when we tried to use dnsmasq on server-side, udhcpc6 was unable to
forward the acquired address to its setup-script although the
IPv6-Address had been assigned by the server as we could see via
tcpdump. We traced this issue down to a problem on how udhcpc6 parses
DHCPv6-Options: When moving to next option, a pointer-address is
increased and a length buffer is decreased by the length of the option.
The problem is that it is done in this order:
option += 4 + option[3];
len_m4 -= 4 + option[3];
But this has to be switched as the length is decreased by the length of
the *next* option, not the current one. This affected both - internal
checks if a required option is present and the function to expose
options to the environment of the setup-script.
There was also a bug parsing D6_OPT_STATUS_CODE Options, that made
dnsmasq not work as udhcpc6 thought it is receiving a non-positive
status-code (because it did not parse the status-code as required in RFC
3315).
In addition we introduced basic support for RFC 3646 (OPTION_DNS_SERVERS
and OPTION_DOMAIN_LIST) and RFC 4704 (OPTION_CLIENT_FQDN).
"
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Patch is based on work by tiggerswelt.net. They say:
"Using this patch it was no problem to acquire an IPv6-Address via DHCPv6
using ISC DHCPD6 on server-side."
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
