Various tools are Linuxish and should thus only attempted to build on
Linux only. Some features are also Linux-only.
Also, libresolv is used on all GNU platforms, notably GNU/Hurd and
GNU/kfreeBSD.
Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
The result of looking at "grep -F -B2 '*fill*' busybox_unstripped.map"
function old new delta
.rodata 108586 108460 -126
------------------------------------------------------------------------------
(add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-126) Total: -126 bytes
text data bss dec hex filename
970412 4219 1848 976479 ee65f busybox_old
970286 4219 1848 976353 ee5e1 busybox_unstripped
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
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 <vda.linux@googlemail.com>
...and we did not error-check it, and this is the only use of it:
function old new delta
inet_addr 37 - -37
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Even though it is _meant to be_ an IP address, in the wild servers sometimes
give bogus server ids, like 1.1.1.1
function old new delta
udhcpc_main 2551 2542 -9
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
"-x vendor:VENDOR" will not be a trivial replacement of it:
(1) by default, we do send a vendor string ("udhcp BB_VER"),
will need code to preserve the default.
(2) -V '' currently disables vendor string. -x vendor:''
would not easily achieve that: it adds no option at all
(string options can't be empty), and default (1) would trigger.
To avoid that, we will need yet another hack to detect
-x vendor:'' and interpret that as "no vendor string at all".
IOW: removing -V is likely to increase code size, not decrease.
function old new delta
udhcpc_main 2563 2555 -8
.rodata 103251 103198 -53
------------------------------------------------------------------------------
(add/remove: 0/0 grow/shrink: 0/2 up/down: 0/-61) Total: -61 bytes
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
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>
This restores old behavior where we slept for 1/2 of lease, then tried renewing,
thel slept for 1/4 and tried again, etc. But now we will NOT be listening to
all packets for 1/2 of lease time, processing (rejecting) everyone else's
DHCP traffic.
We'll go back to bound state, where we have no listening socket at all.
function old new delta
udhcpc6_main 2600 2655 +55
udhcpc_main 2608 2625 +17
.rodata 103250 103249 -1
------------------------------------------------------------------------------
(add/remove: 0/0 grow/shrink: 2/1 up/down: 72/-1) Total: 71 bytes
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
client_data.vendorclass, .hostname and .fqdn probably need the same treatment:
just insert them into the list of -x opts, get rid of
if (client_data.vendorclass)
udhcp_add_binary_option(packet, client_data.vendorclass);
if (client_data.hostname)
udhcp_add_binary_option(packet, client_data.hostname);
if (client_data.fqdn)
udhcp_add_binary_option(packet, client_data.fqdn);
function old new delta
udhcp_insert_new_option - 166 +166
perform_release 171 207 +36
perform_d6_release 227 259 +32
udhcpc6_main 2558 2580 +22
init_d6_packet 103 84 -19
udhcpc_main 2585 2564 -21
attach_option 397 253 -144
------------------------------------------------------------------------------
(add/remove: 1/0 grow/shrink: 3/3 up/down: 256/-184) Total: 72 bytes
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
As reported in bug 13776, before this fix the renew never times out.
function old new delta
udhcpc_main 2541 2585 +44
udhcpc6_main 2567 2558 -9
------------------------------------------------------------------------------
(add/remove: 0/0 grow/shrink: 1/1 up/down: 44/-9) Total: 35 bytes
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
This allows to fix a problem that we wait for renew replies
for up to half the lease (!!!) if they never come.
Make it so that lease of 60 seconds is not "rounded up" to 120 seconds -
set lower "sanity limit" to 30 seconds.
After 3 failed renew attempts, switch to rebind.
After this change, we can have more flexible choice of when to do
the first renew - does not need to be equal to lease / 2.
function old new delta
udhcpc6_main 2568 2576 +8
.rodata 103339 103294 -45
udhcpc_main 2609 2550 -59
------------------------------------------------------------------------------
(add/remove: 0/0 grow/shrink: 1/2 up/down: 8/-104) Total: -96 bytes
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Discovered that the DHCP server on a TrendNet router (unknown model)
provides a zero-length option 12 (Host Name) in the DHCP ACK message. This
has the effect of causing udhcpc to drop the rest of the options, including
option 51 (IP Address Lease Time), 3 (Router), and 6 (Domain Name Server),
most importantly leaving the OpenWrt device with no default gateway.
The TrendNet behavior violates RFC 2132, which in Section 3.14 declares that
option 12 has a minimum length of 1 octet. It is perhaps not a cosmic coincidence
that I found this behavior on Pi Day.
This patch allows zero length options without bailing out, by simply skipping them.
function old new delta
udhcp_scan_options 183 172 -11
Signed-off-by: Russell Senior <russell@personaltelco.net>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
