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 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) ... Nigel Hathaway _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
