Current-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: dhcpcd [configuration] problems

On 03/26/2012 09:53 AM, Roy Marples wrote:
On 24/03/2012 19:44, Chris Ross wrote:
I have a sparc64 host running netbsd-6. [...] I have:


I would actively discourage that.
Use dhcpcd=YES instead of running separate instances of it.

Well, I can certainly do that. But this is my only interface, so it's not instances, just an instance. And, I thought that was the point of allowing "dhcp" in the ifconfig parameters, so that it would just do it for you. But, if the recommended practice is to use dhcpcd=YES, that's fine too. (I was happy with dhclient, I'm just trying to "go with the flow" here anyway. :-) )

Configuring network interfaces: bge0dhcpcd[113]: version 5.5.4 starting
dhcpcd[113]: bge0: carrier acquired
dhcpcd[113]: bge0: carrier lost
dhcpcd[113]: bge0: waiting for carrier
dhcpcd[113]: bge0: carrier acquired
dhcpcd[113]: bge0: sending IPv6 Router Solicitation
dhcpcd[113]: bge0: broadcasting for a lease
dhcpcd[113]: bge0: sending IPv6 Router Solicitation
dhcpcd[113]: bge0: sending IPv6 Router Solicitation
dhcpcd[113]: bge0: sending IPv6 Router Solicitation
dhcpcd[113]: bge0: no IPv6 Routers available
dhcpcd[113]: timed out

  And with a "-t 60", there's 40 seconds or so between the "no IPv6
Routers available", and the "timed out".  It doesn't rebroadcast for a
lease, it doesn't send another router solicitation, and if it *would*,
I suspect it would work.

This is false. You just don't see it. Try enabling debugging "-d" and
you'll see that dhcpcd re-transmits it's requests at the correct RFC
defined intervals.

Okay. Just surprised me that it said things, then didn't. I wouldn't expect a message that was reported once to not be reported again except for in the case of debugging. But I'll certainly try what you suggest. (-d)

-t 60 means timeout after 60 seconds from start. The fact that carrier
was lost, acquired, etc is irrelevant to the timeout.

Oh, I know that. It's the 40 seconds of pause between the end of reports, and the "timed out" that I thought indicated a failure. I'm sure I'll see more with -d.

If carrier is being lost and acquired like that then I'd say it's due to
either faulty cabling or driver. For reference, I use a bge(4) driver in
my i386 laptop which works just fine.

Faulty/suboptimal network switch, more likely. I've seen this sort of thing alot. But, the messages about carrier being lost and reacquired only takes a couple of seconds. Then even if it took another 10-15 seconds to autonegotiate, 60 seconds is more than enough time to be able to communicate effectively.

You could look into using the -K option which stops dhcpcd from ever
checking the driver link status and just tries to configure.

I might try that too. Thanks for the suggestions. I'll let you know how the next steps proceed.

                                             - Chris

Home | Main Index | Thread Index | Old Index