netdev - Re: E1000E/82567LM-3: link reported up too soon

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <87pqwff2bd.fsf@small.ssi.corp>
Date:	Wed, 15 Sep 2010 17:34:30 +0200
From:	arno@...isbad.org (Arnaud Ebalard)
To:	Brian Haley <brian.haley@...com>
Cc:	Jeff Kirsher <jeffrey.t.kirsher@...el.com>,
	Jesse Brandeburg <jesse.brandeburg@...el.com>,
	e1000-devel@...ts.sourceforge.net, netdev@...r.kernel.org,
	"David S. Miller" <davem@...emloft.net>
Subject: Re: E1000E/82567LM-3: link reported up too soon

Hi Brian,

Brian Haley <brian.haley@...com> writes:

>> <snip>
>> 
>> I tested it with 2 different 100M/s switches (Cisco Catalyst 2960 and a
>> Planex FX08-Mini) so I guess the switch is not the root of the issue. I
>> came to the conclusion that the link is reported up too soon by the
>> driver.
>> 
>> Because the first packets are losts, the result is that address
>> autoconfiguration is delayed by a few seconds as can be seen on
>> following capture on the laptop:
>
> I've seen similar things on various NICs,

I remember I add the same kind of issue on a broadcom chip on a dell
D600 but had no time to investigate at that time. Did you notice the
problem for different brands? Do you think those are driver-related
issues or something in common code?
 
> posted a patch last week that unfortunately had other bad
> side-effects.  When I have time I'll work on it again, but I'd also be
> curious if there's something that can be done at the driver level to
> help out, since it seemed like part of the problem is that the link-UP
> came before the device was actually able to transmit packets, so the
> DAD was lost.

I am not familiar with e1000e code but as I said previously I'd be happy
to test patches to help determine precisely where the packet gets lost
and why.

Cheers,

a+
--
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