On 2022-07-13 17:23 -06, "Theo de Raadt" <dera...@openbsd.org> wrote: > Christer Solskogen <christer.solsko...@gmail.com> wrote: > >> This happens every time with dhcpleased and my ISP and it didn't with >> dhclient, and what I do see now, that I didn't see with dhclient, >> is that during the negotiation ifconfig says that the interface has >> "status: no carrier" for 2-3 seconds. Which explains why I don't get a >> DHCPACK within 1 second. > > Is this specific to a particular network driver? > > I am suggesting some drivers may have shitty / sloppy coming-up behaviour. > Or, that dhcpleased is going to need to be more forgiving. Or maybe > as a
both dhcpleased and dhclient start working when LINK_STATE_IS_UP is true (defined in net/if.h). I actually got this wrong at first and then checked what dhclient is doing. So if it takes 2-3 seconds for the link to come up it will take 2-3 seconds to get a lease, nothing we can do about that. > result of the timeout policy it practices, it works different than dhclient > did, and maybe that is not surprising? > Now, if the driver reports the link is up but it doesn't pass any traffic we hit a different timeout behaviour. IIRC dhclient sends the first 10 packets with a timeout of 1 second. I considered that a bit anti-social on wifi where we have seen dhcp servers taking a few seconds to respond. There is no need to blast the network. dhcpleased does an exponetial backoff, i.e. timeout of 1, 2, 4, 8... seconds. -- I'm not entirely sure you are real.
