On Thursday 04 August 2011 15:59, Nigel Hathaway wrote:
> Has anyone see the following behaviour on udhcpc client (v1.18.4) with regard
> to DHCP lease renewal?
>
> The data below is taken from a Wireshark trace which ran over an extended
> period of time. There was a filter turned on just to look at DHCP REQUEST and
> ACK, and the unit in question had already done a full DISCOVER/OFFER/etc
> sequence some time earlier.
>
> What it shows is that, to start with, a lease of 1 hour was given.
> A request for renewal was given after half an hour, and another lease of 1
> hour was given.
> Instead of going for another half an hour, it's like the renewal deadline was
> never updated,
> and the next renewal was half way to the original lease expiry, a quarter of
> an hour later.
This is a symptom that udhcpc did not receive the reply, of ignored it
(thought that reply is corrupted, or is not intended for it).
It's impossible to verify this scenario based on the information you gave.
Full packet dump of the udhcpc packats and server replies
would be better than the sparse table below.
> This halving went on until there was less than a minute to go, and then the
> process
> seemed to reset and start all over again. When the process reset,
> it issued a request over broadcast rather than unicast,
> which is what all the other renewals used.
>
> The numbers in the first column are the Wireshark packet numbers.
>
> 98 - broadcast, 1 hour lease from 101 @ 48.79s
> 3453 - 1 hour lease from 3456 @ 1849.22s (1800.43s later = 1/2 an hour)
> 5286 - 1 hour lease from 5289 @ 2749.37s (900.15s later = 1/4 of an hour)
> 6101 - 1 hour lease from 6104 @ 3199.49s (450.12s later = 7 1/2 minutes)
> 6499 - 1 hour lease from 6502 @ 3424.59s (225.10s later = 3 3/4 minutes)
> 6709 - 1 hour lease from 6712 @ 3536.69s (112.10s later = 1.875 minutes)
> 6813 - broadcast, 1 hour lease from 6816 @ 3592.74s (56.05s later = 0.9375
> minutes)
> 10206 - 1 hour lease from 10209 @ 5393.18s (1800.44s later = 1/2 an hour)
> ...
Here is the relevant code from dhcpc.c -
case BOUND:
/* 1/2 lease passed, enter renewing state */
state = RENEWING;
client_config.first_secs = 0; /* make secs
field count from 0 */
change_listen_mode(LISTEN_KERNEL);
log1("Entering renew state");
/* fall right through */
case RENEW_REQUESTED: /* manual (SIGUSR1) renew */
case_RENEW_REQUESTED:
case RENEWING:
if (timeout > 60) {
/* send an unicast renew request */
/* Sometimes observed to fail (EADDRNOTAVAIL) to bind
* a new UDP socket for sending inside send_renew.
* I hazard to guess existing listening socket
* is somehow conflicting with it, but why is it
* not deterministic then?! Strange.
* Anyway, it does recover by eventually failing through
* into INIT_SELECTING state.
*/
send_renew(xid, server_addr,
requested_ip);
timeout >>= 1;
continue;
}
/* Timed out, enter rebinding state */
log1("Entering rebinding state");
state = REBINDING;
/* fall right through */
case REBINDING:
/* Switch to bcast receive */
change_listen_mode(LISTEN_RAW);
/* Lease is *really* about to run out,
* try to find DHCP server using broadcast */
if (timeout > 0) {
/* send a broadcast renew request */
send_renew(xid, 0 /*INADDR_ANY*/,
requested_ip);
timeout >>= 1;
continue;
}
/* Timed out, enter init state */
bb_info_msg("Lease lost, entering init state");
udhcp_run_script(NULL, "deconfig");
state = INIT_SELECTING;
client_config.first_secs = 0; /* make secs
field count from 0 */
/*timeout = 0; - already is */
packet_num = 0;
continue;
/* case RELEASED: */
}
Another bit of useful information can be retrieved by running
udhcpc with -v[vv] so that log1("message") are emotted.
For example, this will tell whether udhcpc receives the packets
it seem to ignore...
--
vda
_______________________________________________
busybox mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/busybox
