linux-kernel - 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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID:
 <VI1PR04MB5501658A227BFC1A832B2627EA992@VI1PR04MB5501.eurprd04.prod.outlook.com>
Date: Mon, 9 Sep 2024 15:46:05 +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

> 
> > It turns out that the patch works fine for the specific issue it's
> > trying to address (Juniper switch), but for (seemingly all) other devices it breaks
> the autonegotiation.
> 
> So it sounds like you need to figure out the nitty-gritty details of what is going
> on with the Juniper switch. Once you understand that, you might be able to find
> a workaround which works for all systems.
> 
>     Andrew

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.  Other switch vendors recover gracefully when the right encoding is discovered, not using AN37 transactions, but not Juniper.  Since DNV doesn't do AN37 in SFP auto mode, there's an endless loop.   (Technically, the switches *could* be updated to new firmware that should have this capability, but apparently a logistical issue for at least one of our customers.)  

Going back through my emails, Doug did mention that it would possibly cause issues with other switches, but it wasn't anything we, or (until just recently) anyone else had observed.  A quote from Doug:  

"that AN37 fix pretty much only works with the Juniper switches, and can cause problems with other switches."

Initially I wanted to have this patch wrapped in a module parameter to avoid any potential issues, but that was shot down for the same reasons you initially commented about.  The unwrapped patch was accepted however.  It was a couple years before the potential other switch issue actually showed up and the patch was reverted.  Our customer still wants the code in the mainline kernel driver, maintaining a separate patch was not something that was acceptable to them, so we are.  This was all gone around with Intel a couple of years before and the solution for a non-updated Juniper MX5T switch is orthogonal to other switch support, thus the patch with the module parameter.