[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: kern/51531: Recent networking regression affecting installs
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>
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):
>> That tells me that the address is DETACHED during this time and not
> Shouldn't there be a DETACHED flag in the ifconfig output, then?
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
As Joerg indicated earlier this could happen with wireless networking
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.
Main Index |
Thread Index |