Re: dhcpcd [configuration] problems

[Chris Ross <cross+netbsd%distal.com@localhost>]

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:
> >
> > ifconfig_bge0="dhcp"
>
> 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