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>
Redundant help texts (one which only repeats the description)
are deleted.
Descriptions and help texts are trimmed.
Some config options are moved, even across menus.
No config option _names_ are changed.
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
All other applets are listed simply by their name, no reason why
dumpleases doesn't do that.
Group all udhcpd feature options directly after it.
Put "NOT READY" into udhcpc6 item (some users actually tried to use it,
and complained).
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
function old new delta
udhcp_get_option 215 220 +5
udhcp_run_script 802 803 +1
Signed-off-by: Brian Foley <bpfoley@google.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Added NOINLINE to two function, since my version of gcc would actualy increase
code size otherwise.
I see no size changes.
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
The udhcpc script may be used to setup fallback configuration (E.G. IPv4LL,
fixed IP address, ..) that also needs to be cleaned up on release (E.G.
when SIGUSR2 is called or on shutdown with -R), so unconditionally call
deconfig.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
The bug was seen when the following is done:
# killall 1 udhpc; killall 2 udhpc
Performing a DHCP renew
state: 2 -> 5
Sending renew...
Entering released state
state: 5 -> 6 <<<<<<<<<<<<<< not calling script!!!!
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
The result of looking at "grep -F -B2 '*fill*' busybox_unstripped.map"
text data bss dec hex filename
829901 4086 1904 835891 cc133 busybox_before
829665 4086 1904 835655 cc047 busybox
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Otherwise, "-t 0" usage may end up sending them forever
if server does not respond.
function old new delta
udhcpc_main 2846 2836 -10
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
RFC2131 paragraph 4.1 states DHCP messages broadcast by a client prior to
that client obtaining its IP address must have the source IP address
field in the header set to 0.
Request messages transmitted in renewing and rebinding state need to use
the obtained IP address as source IP address in the header; this behavior
lines up with other implementations like ISC dhcp client.
Signed-off-by: Hans Dedecker <dedeckeh@gmail.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Let udhcpd retain the information about expired leases when restarting
so that the leases are reserved until they possibly become the oldest
expired lease.
This reduces the frequency of IP address changes for example when the
DHCP server and a group of clients, who do not store and request their
previously offered IP address across restarts, are collectively restarted
and the startup order of the clients are not guaranteed.
Signed-off-by: Christian Lindeberg <christian.lindeberg@axis.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
While RFC1035 recommends a label not to start with a number, there is
actually no such limitation in dns. One may buy a domain name like
0x1.net and use it.
This commit remove this check and allow a user to use such domains.
Signed-off-by: Arthur Gautier <baloo@gandi.net>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Introduce a library routine to package the idiom:
p = xmalloc(b, n);
memcpy(p, b, n);
and use it where possible. The example in traceroute used xzalloc
but it didn't need to.
function old new delta
xmemdup - 32 +32
last_main 834 826 -8
make_device 2321 2311 -10
common_traceroute_main 3698 3685 -13
readtoken1 3182 3168 -14
procps_scan 1222 1206 -16
forkchild 655 638 -17
------------------------------------------------------------------------------
(add/remove: 1/0 grow/shrink: 0/6 up/down: 32/-78) Total: -46 bytes
Signed-off-by: Ron Yorston <rmy@frippery.org>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
We wanted to detect when tv_sec = unsigned1 - unsigned2
underflows by looking at tv_sec's sign. But if tv_sec
is long and it is wider than unsigned, we get unsigned -> long
conversion which is in this case never negative.
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Prevent nasty surprises if script runs longer than lease time / 2.
Signed-off-by: John Schroeder <jschroed@gmail.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Based on the following user report:
I ran into an issue where I was seeing a long delay in the scripts called
in udhcp_run_script. I was using an old version of OpenWrt (kamikaze)
and a satellite modem. An NTP script was being called and the modem
would sometimes take a long time to respond to the DNS lookup when
it was offline.
This delay started affecting my lease time. The lease that I would
get from my satellite modem before it was online would be short:
only 60 seconds. The delay with NTP and the modem would typically
be about 18 seconds. This would cause the first DHCP renew request
from dhcpc to be a little late. Under certain circumstances,
I could even see the first DHCP renew to occur after the lease
had expired!
function old new delta
udhcpc_main 2816 2837 +21
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Some clients have a very short timeout for sending the DHCP
DISCOVER, shorter than the arpping timeout of 2000 milliseconds
that udhcpd uses by default.
This patch allows tweaking the timeout, or disabling of arpping
altogether, at the risk of handing out addresses which are
already in use.
function old new delta
udhcpd_main 1460 1501 +41
udhcpc_main 2814 2851 +37
packed_usage 29957 29974 +17
arpping 477 493 +16
find_free_or_expired_nip 161 174 +13
send_offer 285 292 +7
nobody_responds_to_arp 85 89 +4
------------------------------------------------------------------------------
(add/remove: 0/0 grow/shrink: 7/0 up/down: 135/0) Total: 135 bytes
Signed-off-by: Michel Stam <m.stam@fugro.nl>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Like d3092c99, this change adds support for the DHCP "path-prefix"
option, as defined in RFC 5071. We use the string identifer
"pxepathprefix".
Adding this option makes string parsing in the hook scripts simpler.
function old new delta
dhcp_option_strings 255 269 +14
dhcp_optflags 72 74 +2
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
This change adds a definition for DHCP option 209. RFC 5071 defines code
209 as a configuration file for a PXE bootloader; this change uses
the string "pxeconffile" as its text identifier.
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Commit b8b72f02 removed all padding from DHCP packets
to fix operation with buggy servers which can't handle
maximum sized packets. But it introduced a regression
with buggy routers which drop DHCP packets smaller
than 300 bytes (i.e. 342 byte ethernet packets).
Add back some padding to work around.
function old new delta
udhcp_send_kernel_packet 268 292 +24
udhcp_send_raw_packet 462 473 +11
------------------------------------------------------------------------------
(add/remove: 0/0 grow/shrink: 2/0 up/down: 35/0) Total: 35 bytes
Signed-off-by: Johannes Stezenbach <js@sig21.net>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Scenario:
1. udhcpc gets lease for 86400 secs and sleeps for 43200 before renew attempt
2. PC gets physically disconnected and connected to another network
3. some phy control software sends SIGUSR1 to renew the lease, SIGUSR2 isn't
used because newly connected network could be the same as before
4. udhcpc sends unicast renew requests until lease timeout fall to 60 sec.
They are ignored by new network dhcp servers
5. udhcpc sends broadcast rebind requests for 60 seconds, which are NAKed
or ignored too
6. udhcpc deconfigs and starting from discover state, gets new lease for the
new network
So, pt.4+5 it could take up to 86400 secs without correct lease, which is
too long and not acceptable.
Second SIGUSR1 will immediately run into deconfig/discover state, which is
not preferable in case of the same subnet replugged.
This patch makes sure after SIGUSR1 timeout is no more than -A NUM
(usually 20 sec). It means that renew will be requested via broadcast,
and if no replies come back, full deconf/reconf cycle will be initiated
in 20 seconds.
Signed-off-by: Vladislav Grishenko <themiron@mail.ru>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
In theory, sending secs set to constant zero should be ok too.
But some bleeping servers can actually be configured to answer ONLY
if secs is bigger than a preset value (!!)
http://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man8/bootpd.8.html
grep for "reply_threshold_seconds"
function old new delta
udhcpc_main 2573 2623 +50
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
http://git.busybox.net/busybox/commit/?id=7d3a48a003cd645edfae2b404493688022
revealed incorrect OPTION_IP_PAIR implementation, which doesn't respect
option length and causes erroneous classful routes, composed from garbage
or first bytes from the next DHCP packet option.
Signed-off-by: Vladislav Grishenko <themiron@mail.ru>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
