netdev - Re: [PATCH net-next 2/2] net: sfp: relax bitrate-derived mode check

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] [day] [month] [year] [list]
Date:   Fri, 4 Dec 2020 15:51:59 +0000
From:   Russell King - ARM Linux admin <linux@...linux.org.uk>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     Heiner Kallweit <hkallweit1@...il.com>,
        Pali Rohár <pali@...nel.org>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>, netdev@...r.kernel.org
Subject: Re: [PATCH net-next 2/2] net: sfp: relax bitrate-derived mode check

On Fri, Dec 04, 2020 at 04:38:50PM +0100, Andrew Lunn wrote:
> On Fri, Dec 04, 2020 at 02:35:27PM +0000, Russell King wrote:
> > Do not check the encoding when deriving 1000BASE-X from the bitrate
> > when no other modes are discovered. Some GPON modules (VSOL V2801F
> > and CarlitoxxPro CPGOS03-0490 v2.0) indicate NRZ encoding with a
> > 1200Mbaud bitrate, but should be driven with 1000BASE-X on the host
> > side.
> 
> Seems like somebody could make a nice side line writing SFP EEPROM
> validation tools. There obviously are none in widespread use!

Definitely. Here's an example of another module:

  Identifier                                : 0x02 (module soldered to motherboard)

This is incorrect, it's a plug-in module.

  Transceiver codes                         : 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0x00
  Transceiver type                          : 10G Ethernet: 10G Base-ER [SFF-8472 rev10.4 onwards]
  Transceiver type                          : 10G Ethernet: 10G Base-LRM
  Transceiver type                          : 10G Ethernet: 10G Base-LR
  Transceiver type                          : 10G Ethernet: 10G Base-SR
  Transceiver type                          : Infiniband: 1X SX
  Transceiver type                          : Infiniband: 1X LX
  Transceiver type                          : Infiniband: 1X Copper Active        Transceiver type                          : Infiniband: 1X Copper Passive
  Transceiver type                          : ESCON: ESCON MMF, 1310nm LED        Transceiver type                          : ESCON: ESCON SMF, 1310nm Laser
  Transceiver type                          : SONET: OC-192, short reach
  Transceiver type                          : SONET: SONET reach specifier bit 1
  Transceiver type                          : SONET: SONET reach specifier        Transceiver type                          : SONET: SONET reach specifier bit 2
  Transceiver type                          : SONET: OC-48, long reach
  Transceiver type                          : SONET: OC-48, intermediate reach
  Transceiver type                          : SONET: OC-48, short reach
  Transceiver type                          : SONET: OC-12, single mode, long reach
  Transceiver type                          : SONET: OC-12, single mode, inter. reach
  Transceiver type                          : SONET: OC-12, short reach
  Transceiver type                          : SONET: OC-3, single mode, long reach
  Transceiver type                          : SONET: OC-3, single mode, inter. reach
  Transceiver type                          : SONET: OC-3, short reach
  Transceiver type                          : Ethernet: BASE-PX
  Transceiver type                          : Ethernet: BASE-BX10
  Transceiver type                          : Ethernet: 100BASE-FX
  Transceiver type                          : Ethernet: 100BASE-LX/LX10
  Transceiver type                          : Ethernet: 1000BASE-T
  Transceiver type                          : Ethernet: 1000BASE-CX
  Transceiver type                          : Ethernet: 1000BASE-LX
  Transceiver type                          : Ethernet: 1000BASE-SX
  Transceiver type                          : FC: very long distance (V)
  Transceiver type                          : FC: short distance (S)
  Transceiver type                          : FC: intermediate distance (I)
  Transceiver type                          : FC: long distance (L)
  Transceiver type                          : FC: medium distance (M)
  Transceiver type                          : FC: Shortwave laser, linear
Rx (SA)
  Transceiver type                          : FC: Longwave laser (LC)
  Transceiver type                          : FC: Electrical inter-enclosure (EL)
  Transceiver type                          : FC: Electrical intra-enclosure (EL)
  Transceiver type                          : FC: Shortwave laser w/o OFC
(SN)
  Transceiver type                          : FC: Shortwave laser with OFC (SL)
  Transceiver type                          : FC: Longwave laser (LL)
  Transceiver type                          : Active Cable
  Transceiver type                          : Passive Cable
  Transceiver type                          : FC: Copper FC-BaseT
  Transceiver type                          : FC: Twin Axial Pair (TW)
  Transceiver type                          : FC: Twisted Pair (TP)
  Transceiver type                          : FC: Miniature Coax (MI)
  Transceiver type                          : FC: Video Coax (TV)
  Transceiver type                          : FC: Multimode, 62.5um (M6)
  Transceiver type                          : FC: Multimode, 50um (M5)
  Transceiver type                          : FC: Single Mode (SM)
  Transceiver type                          : FC: 1200 MBytes/sec
  Transceiver type                          : FC: 800 MBytes/sec
  Transceiver type                          : FC: 400 MBytes/sec
  Transceiver type                          : FC: 200 MBytes/sec
  Transceiver type                          : FC: 100 MBytes/sec

This, of course, _really_ messes up our current EEPROM parsing code.
I can only think that this SFP module is very very large externally
to support all those different connectors for all those capabilities!

I think it's safe to assume all SFP GPON modules are broken in one
way or another, and sadly no manufacturer cares one iota what they
stuff into their EEPROM. So far, every GPON module I've heard of has
had some problem or another. This is a really sad state of affairs.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!