dhcpcd-discuss

On Friday 05 Jun 2015 20:51:30 you wrote:
> Hi Mick
> 
> On Friday 05 Jun 2015 19:02:42 Mick wrote:
[snip]

> Here's some history :)
> 
> No ClientID == BOOTP pretty much
> MAC based ClientID == most DHCP clients
> DUID based ClientID == dual stack DHCP and DHCPv6 clients
> 
> Some DHCP tried to ensure ClientID was MAC based and threw a wobbly if not
> .... this should no longer be a problem with modern DHCP servers.

Thanks!  Both at home and at work DUID seems to be causing problems.  At work 
I think it won't even obtain an IP address.  I have set it to ClientID now and 
it seems to work fine.

> > I changed clientid to duid and back to client id in my dhcpcd.conf, but
> > the behaviour is pretty much the same.  The router is contacted, an
> > IP4ALL address is obtained within a couple of seconds, then a minute or
> > so later I eventually get an address from the router.
> 
> This has nothing to do with the above discussion.

Yes, I understand this.  It is the case that if I disable IPv4ALL dhcpcd would 
fail to get an IP address at all, on ethernet.  It times out and eventually 
gives up.


> > dhcpcd is called from ifplug on my laptop, via an openrc network
> > interface start up script - this is on a Gentoo build.
> 
> It won't fix your problem, but you get better mileage when you add dhcpcd
> to the default or boot runlevel and stop using the net.* scripts.

I've been using the /etc/conf.d/net script so that when on my home LAN I can 
get a static IP, but elsewhere I get dhcp kicking in as a fallback.  The 
problem is that for some reason my router does not always responds to arping.  
So obtaining a static IP address often fails, then dhcpcd starts, then an 
IPv4ALL is allocated, then I have to wait for another minute or so before 
dhcpcd gets an address from the router.

Strangely enough, the wireless connection on the same router obtains a dhcp 
address within a couple of seconds.


> > Shouldn't the IP4ALL be dropped as soon as a dhcp address is obtained?
> 
> Yes it should.
> 
> This is a new bug in dhcpcd, probably introduced in dhcpcd-6.8.x and it
> stems off new code I have to work with new code only found in NetBSD which
> I have yet to decide how best to solve. I'll probably go for the best way
> of solving it, which is also sadly the slowest - but may have a more long
> term gain.

Phew!  I thought something was wrong with my system.  :-)

Thank you for your help and all the good work you've be doing on dhcpcd.

-- 
Regards,
Mick

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