dhcpcd-discuss

Re: Problems getting an IP address from various routers

Roy Marples

Sun Jun 14 19:29:48 2015

On Sunday 14 Jun 2015 17:33:14 Mick wrote:
> > I've added another fix where dhcpcd should now correctly fork on a IPv4LL
> > address. Let me know how that works for you!
> 
> Yes!  :-)
> 
> It now forks after allocating an IP v4ALL and when a new IP address is
> assigned, the IPv4ALL is flushed out.  All this without changing the default
> timeout of dhcpcd.

:)
So all I have to do now is fix dhcpcd spinning on NetBSD in certain conditions 
and I can make a new release.

> > I looked at the traces.
> > The timeout on address offer is just co-incidence as far as I can tell -
> > dhcpcd receives the offer just a second or two dhcpcd would have timed out
> > anyway. I can't magically make it go faster, but you could try increasing
> > the timeout from the default 30 seconds to 60.
> 
> The latest code works fine without increasing the dhcpcd timeout, although
> if I reduce it down to, say 15sec, it fails to get any address.
> 
> However, I am still at a loss why the router does not rebind the old IP
> address and ignores the first two DHCPREQUEST that the client sends to it,
> which results in the message "DHCP lease expired" on line 10 in the log
> above.
> 
> Before this the client is sending broadcast messages like so:
> 
> Request who-has 10.10.10.1 (ff:ff:ff:ff:ff:ff) tell 0.0.0.0

dhcpcd does not sent that. You can verify this by adding the debug directive 
(-d) to the dhcpcd commandline or the word debug on a line by itself in 
dhcpcd.conf

> but these are also ignored by the router.  I notice that only two such
> requests are sent out by the client at a 5 second interval.  Is there a
> timer or other mechanism that affects how many DHCPREQUEST messages are
> sent?  Is this something specified in the RFC, or is it down to the DHCP
> client implementation?

It's a timer internal to dhcpcd, the default is 5 seconds to rebind an old 
lease before starting IPv4LL and DHCP discover. You can adjust this using the 
reboot directive. You can set it to 0 to skip the reboot phase entirely and go 
straight to DISCOVER.
But as it takes time for even that to work I'm guessing your DHCP server is 
very slow. Based on the interface name I'll guess you're on a wired network, 
so it's not wireless lag, just slow.

Are other clients as slow like say dhclient?
If so, not much I can do - if not then I think the server is choking on an 
option dhcpcd sends which it fails to understand.

Roy

Attachment: signature.asc
Description: This is a digitally signed message part.


References:
Problems getting an IP address from various routersMick
Archive administrator: postmaster@marples.name