On Thu, 2016-02-04 at 18:58 +0530, Saurav Babu wrote:
When connman's gdhcp client receives DHCPNAK message then it restarts DHCP
after 3sec. Is there any specific reason for this delay of 3sec?
The reasoning seems to have been that some delay is needed before
retrying. Apparently 3s seemed like a good option at the time.
In RFC 2131 "If the client receives a DHCPNAK message, it
reuse its remembered network address. It must instead request a new
address by restarting the configuration process, this time using the
(non-abbreviated) procedure described in section 3.1. This action also
corresponds to the client moving to the INIT state in the DHCP state diagram."
I didn't find any specific waiting time after receiving DHCPNAK messages in RFC.
Is it fine to reduce this waiting time?
As it so happens, systemd-networkd has seen the same kind of issue. But
here it was noted that systemd-networkd was then flooding the server
with too many requests, so it implemented a strategy to avoid that. See
systemd commit 1d1a3e0afb85478cda43670b8ed92a6db6c83f3e. From the above
it shows that the time cannot be reduced, rather that one wants to retry
by gracefully lengthen the intervals instead. So something similar
should be implemented in ConnMan if this problem is to be tackled.