netdev - Re: [drivers/net/phy/sfp] intermittent failure in state machine checks

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: <20200110102607.GY25745@shell.armlinux.org.uk>
Date:   Fri, 10 Jan 2020 10:26:07 +0000
From:   Russell King - ARM Linux admin <linux@...linux.org.uk>
To:     ѽ҉ᶬḳ℠ <vtol@....net>
Cc:     Andrew Lunn <andrew@...n.ch>, netdev@...r.kernel.org
Subject: Re: [drivers/net/phy/sfp] intermittent failure in state machine
 checks

On Fri, Jan 10, 2020 at 12:18:41AM +0000, ѽ҉ᶬḳ℠ wrote:
> On 09/01/2020 23:50, ѽ҉ᶬḳ℠ wrote:
> > Maybe I should just try finding a module that is declared SPF MSA
> > conform...
> 
> Actually, the vendors declares
> (https://www.allnet.de/en/allnet-brand/produkte/neuheiten/p/-0c35cc9ea9/):
> 
> *ALLNET ALL4781-VDSL2-SFP* is a VDSL2 SFP modem that interconnects with
> Gateway Processor by using a MSA (MultiSource Agreement) compliant hot
> pluggable electrical interface.
> 
> Ok, "a MSA" does not explicitly state/imply SFP MSA but what other MSA could
> that be?
> If it is indeed SFP MSA conform the issue should not happen. Unless it is
> just marketing speak and does not hold true.

Everyone claims that their SFP is MSA compliant, even when the module:

1) takes 40-50 seconds after deasserting TX_DISABLE to initialise and
   deassert TX_FAULT, when the SFP MSA explicitly states a limit of
   300ms (t_init) for TX_FAULT to deassert.

2) EEPROM does not respond for 50 seconds after plugging in, where the
   SFP MSA explicitly states 300ms (t_serial) maximum.

3) EEPROM contains incorrect data, for example:
   - indicating the module has a LC connector, yet it has an RJ45, or
     vice versa.
   - indicating NRZ encoding for an ethernet SFP, where it should be
     8b10b or 64b66b encoding.
   - indicating a single data rate, or even the wrong data rate, when
     the module is documented as supporting other rates.
   - indicating an extended compliance technology that it doesn't
     support, presumably originally chosen when the number was
     unallocated by SFF-8024.
   - claiming to support 1000BASE-SX, a fiber standard, when the
     module is actually for VDSL2 over copper.

... etc ...

So, I tend to ignore "SFP MSA compliant" whenever I see it; it is
mostly meaningless.  Yes, there are modules out there which are
compliant, but those that claim compliance but aren't make the
claim meaningless for everyone.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up