[lwip-devel] [bug #19927] DHCP NACK problem

[Jonathan Larmour]

Follow-up Comment #13, bug #19927 (project lwip):

Yes, since Cui says it works for him/her this should be fine.

I've done more research into answering my question at the end of comment #8,
and looking at the RFC I believe it is safe to just start discovery
immediately, rather than waiting for the 10 second timeout.

RFC2131 does talk about using exponential backoffs, but only for
retransmission, and this wouldn't be one. Theoretically this could also be
part of an attempt to introduce a random delay, but then we don't try and
introduce that delay at the first request at all, and that's when it's needed
most, so that couldn't really have been the rationale (and the delay is fixed
at 10secs, not random anyway). I've also looked at a different open source
implementation of DHCP, and it doesn't have any introduced delay (not that
that implementation is necessarily correct!).

So in the patch I've made dhcp_handle_nak() now call dhcp_discover()
directly, and no longer wait 10 seconds, which is what I'll now check in.


(file #14757)
    _______________________________________________________

Additional Item Attachment:

File name: dhcp.nak.patch                 Size:1 KB


    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/bugs/?19927>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/