[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20091218114123.GA8310@ff.dom.local>
Date: Fri, 18 Dec 2009 11:41:23 +0000
From: Jarek Poplawski <jarkao2@...il.com>
To: Roland Dreier <rdreier@...co.com>
Cc: Németh Márton <nm127@...email.hu>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
Andrew Morton <akpm@...ux-foundation.org>,
Mike Galbraith <efault@....de>, Ingo Molnar <mingo@...e.hu>,
netdev@...r.kernel.org, bugzilla-daemon@...zilla.kernel.org,
bugme-daemon@...zilla.kernel.org
Subject: Re: [Bugme-new] [Bug 14794] New: IP address assigned by DHCP is
dropped after ~40 seconds
On Fri, Dec 18, 2009 at 12:16:13AM -0800, Roland Dreier wrote:
>
> > Unfortunately reverting the commit 61cbe54d9479ad98283b2dda686deae4c34b2d59 on
> > top of 2.6.32 does not solve the problem.
>
> Is there any possibility that one of the steps of the bisection was
> wrong? Could you possibly have accidentally marked a "bad" kernel as
> "good"?
>
> Addresses like 169.254.123.251 are RFC 3297 zeroconf link-local
> addresses. I think network manager will assign one of those if it
> thinks the DHCP negotiation failed.
>
> It might be informative to compare the network manager and dhclient log
> output (maybe in /var/log/daemon.log?) in the good and bad cases.
Btw, I'm not sure if it matters, but your dmesg doesn't mirror what
you described. You mentioned one unplug only, while there are a few
link down / link up events visible. So I wonder if bad contact didn't
happen here. Then dhcp client might hit some limit of tries. On the
other hand, such an effect could be amplified by changes in 2.6.32
too (e.g. with different timing). Could you attach 2.6.31 dmesg after
this test?
Jarek P.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists