Re: kern/51531: Recent networking regression affecting installs

[Roy Marples <roy%marples.name@localhost>]

The following reply was made to PR kern/51531; it has been noted by GNATS.

From: Roy Marples <roy%marples.name@localhost>
To: Andreas Gustafsson <gson%gson.org@localhost>
Cc: gnats-bugs%netbsd.org@localhost
Subject: Re: kern/51531: Recent networking regression affecting installs
Date: Wed, 23 Nov 2016 10:30:47 +0000

 On 23/11/2016 10:07, Andreas Gustafsson wrote:
 > Roy Marples wrote:
 >>> It waits for about 5 seconds, not 15.  Here's the relevant part
 >>> of the timestamped log (the big numbers are seconds since the epoch):
 >>
 >> OK.
 >> That tells me that the address is DETACHED during this time and not
 >> TENTATIVE.
 > 
 > Shouldn't there be a DETACHED flag in the ifconfig output, then?
 
 Maybe not.
 Addresses transition from DETACHED -> TENTATIVE when the carrier comes
 up and this triggers DaD.
 If the carrier (or interface) goes down then all addresses are marked
 DETACHED.
 As Joerg indicated earlier this could happen with wireless networking
 very easily.
 Personally I would be inclinded to remove the ping test entirely - the
 fact it passes is not a guarantee it can download sets.
 
 ifconfig -w 15 -W 5 says wait 5 seconds for DETACHED to clear and 15 for
 TENTATIVE to clear. So if it's waiting for 5 seconds as you say then the
 carrier has been down for at least 5 seconds for some reason.
 rc.d/network was modified a long time ago with this exact same change.
 
 >> In other words, the interface thinks there is no carrier.
 >>
 >> Could you try changing my commit locally from -w 15 -W 5 to -w 15 -W 15
 >> and see if that helps at all?
 > 
 > Not easily.  The testbed in case is generating public reports that are
 > supposed to reflect the true state of -current as a function of the
 > CVS source date.  To test something that is not actually -current,
 > I'd have to set up a separate instance of the testbed.
 > 
 >> If not, do other numbers help? -w 120 -W 120 is insane, but it's worth
 >> trying to see if my theory is right.
 >>
 >> If so, we just have to increase the default numbers, and maybe in
 >> rc.conf as well OR look into why the interface is taking more than 5
 >> seconds to gain a carrier as sk0 is cabled yes?
 > 
 > It is cabled to a 10baseT (sic) hub.  I could try a 100baseTX switch
 > and see if that makes a difference.
 
 Please do.
 
 Roy