netdev - RE: [PATCH] ixgbe: Manual AN-37 for troublesome link partners for X550 SFI

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] [day] [month] [year] [list]

Message-ID:
 <VI1PR04MB550131951D89CA1F6D93C828EA9A2@VI1PR04MB5501.eurprd04.prod.outlook.com>
Date: Tue, 10 Sep 2024 17:51:07 +0000
From: Jeff Daly <jeffd@...icom-usa.com>
To: Andrew Lunn <andrew@...n.ch>
CC: "anthony.l.nguyen@...el.com" <anthony.l.nguyen@...el.com>,
	"przemyslaw.kitszel@...el.com" <przemyslaw.kitszel@...el.com>,
	"davem@...emloft.net" <davem@...emloft.net>, "edumazet@...gle.com"
	<edumazet@...gle.com>, "kuba@...nel.org" <kuba@...nel.org>,
	"pabeni@...hat.com" <pabeni@...hat.com>, "intel-wired-lan@...ts.osuosl.org"
	<intel-wired-lan@...ts.osuosl.org>, "netdev@...r.kernel.org"
	<netdev@...r.kernel.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>
Subject: RE: [PATCH] ixgbe: Manual AN-37 for troublesome link partners for
 X550 SFI


> > This was originally worked out by Doug Boom at Intel.  It had to do
> > with autonegotiation not being the part of the SFP optics when the
> > Denverton X550 Si was released and was thus not POR for DNV.  The
> > Juniper switches however won't exit their AN sequence unless an AN37
> > transaction is seen.
> 
> I wounder what 802.3 says about this. I suspect the Juniper switch is within the
> standard here, and the x550 is broken.
>

Paraphrasing Doug: X550 on DNV lacks the AN37 to SFI like the other ixgbe devices so AN37 SFI doesn't work with DNV unless both sides force autonegotiation.
The Juniper switch won't exit AN until it sees an AN37 transaction, on stock DNV this won't occur.  There's no timeout with AN37 in the spec so Juniper 
implements the protocol according to spec, but this means with no AN37 coming from DNV it loops forever.  Other vendors (and probably Juniper too) saw the
hole in the spec and have a timeout and some recovery where it locks correctly (not via AN37), which make other switches work ok with DNV, but these still
have the endless loop. 
 
> > Other switch vendors recover gracefully when the right encoding is
> > discovered, not using AN37 transactions, but not Juniper.
> 

Snip

> LOS from the from the SFP cage will tell you there is something on the other end
> of the link. It is not a particularly reliable signal, since it just means there is light.
> Is there any indication the link is not usable? You could wait 10 seconds after
> LOS is inactive, and if there is no usable link kick off the workaround. If after 10
> seconds the link is still not usable, turn the workaround off again. Flip flop every
> 10 seconds.
> 
> Hopefully the initial 10 seconds delay means you won't upset switches which
> currently work, and after 10 seconds, you gain a link to switches that really do
> expect AN37.
> 
>         Andrew

I'll look into this.