...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>
The $RANDOM variable may be disabled on ash compilation but we can safelly use mktemp instead.
Signed-off-by: Sergey Ponomarev <stokito@gmail.com>
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>
SRV lookups are supported since "6b4960155 nslookup: implement support
for SRV records" and should therefore be mentioned as a possible
QUERY_TYPE in the help message.
Signed-off-by: Paul Spooren <mail@aparcar.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>
For one, an attacker can try to overload us by just opening and immediately
closing tons of connections - reduce our work to the minimum for this case.
function old new delta
handle_incoming_and_exit 2172 2200 +28
.rodata 103225 103246 +21
------------------------------------------------------------------------------
(add/remove: 0/0 grow/shrink: 2/0 up/down: 49/0) Total: 49 bytes
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
This makes proxy work for any type of requests.
function old new delta
handle_incoming_and_exit 2240 2172 -68
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>
This resolves failures like
wget: server returned error: HTTP/1.1 307 Temporary Redirect
Signed-off-by: Jeremy Lin <jeremy.lin@gmail.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
