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: <acd4d7e4-7f8e-d578-c9c9-b45f062f4fe2@gmx.net>
Date:   Thu, 9 Jan 2020 19:01:10 +0000
From:   ѽ҉ᶬḳ℠ <vtol@....net>
To:     Russell King - ARM Linux admin <linux@...linux.org.uk>
Cc:     Andrew Lunn <andrew@...n.ch>, netdev@...r.kernel.org
Subject: Re: [drivers/net/phy/sfp] intermittent failure in state machine
 checks

On 09/01/2020 17:43, Russell King - ARM Linux admin wrote:
> On Thu, Jan 09, 2020 at 05:35:23PM +0000, ѽ҉ᶬḳ℠ wrote:
>> Thank you for the extensive feedback and explanation.
>>
>> Pardon for having mixed up the semantics on module specifications vs. EEPROM
>> dump...
>>
>> The module (chipset) been designed by Metanoia, not sure who is the actual
>> manufacturer, and probably just been branded Allnet.
>> The designer provides some proprietary management software (called EBM) to
>> their wholesale buyers only
> I have one of their early MT-V5311 modules, but it has no accessible
> EEPROM, and even if it did, it would be of no use to me being
> unapproved for connection to the BT Openreach network.  (BT SIN 498
> specifies non-standard power profile to avoid crosstalk issues with
> existing ADSL infrastructure, and I believe they regularly check the
> connected modem type and firmware versions against an approved list.)
>
> I haven't noticed the module I have asserting its TX_FAULT signal,
> but then its RJ45 has never been connected to anything.
>

The curious (and sort of inexplicable) thing is that the module in 
general works, i.e. at some point it must pass the sm checks or 
connectivity would be failing constantly and thus the module being 
generally unusable.

The reported issues however are intermittent, usually reliably 
reproducible with

ifdown <iface> && ifup <iface>

or rebooting the router that hosts the module.

If some times passes, not sure but seems in excess of 3 minutes, between 
ifdown and ifup the sm checks mostly are not failing.
It somehow "feels" that the module is storing some link signal 
information in a register which does not suit the sm check routine and 
only when that register clears the sm check routine passes and 
connectivity is restored.
____

Since there are probably other such SFP modules, xDSL and g.fast, out 
there that do not provide laser safety circuitry by design (since not 
providing connectivity over fibre) would it perhaps not make sense to 
try checking for the existence of laser safety circuitry first prior 
getting to the sm checks?
____

Sometime in the past sfp.c was not available in the distro and the issue 
never exhibited. Back then the module's operations mode been set through 
a py script - see bottom - but it would appear that it did not implement 
any sm checks.

---py script

class SFP:
     def __init__(self, i2cbus):
         self.i2cbus = i2cbus

     @staticmethod
     def detect_metanoia_xdsl(eeprom):
         return ['X', 'C', 'V', 'R', '-', '0', '8', '0', 'Y', '5',
             '5',] == eeprom[40:51]

     @staticmethod
     def detect_zisa_gpon(eeprom):
         return ['T', 'W', '2', '3', '6', '2', 'H'] == eeprom[40:47]

     @staticmethod
     def detect_sgmii(eeprom):
         if ord(eeprom[6]) & 0x08:
             d("Mode selected: generic SGMII")
             return True
         else:
             d("Mode selected: generic 1000BASE-X")

         return False


     def decide_sfpmode(self):
         ec = []
         try:
             ec = list(EEPROM(self.i2cbus).read_eeprom())
             d("SFP EEPROM: %s" % str(ec))
         except Exception as e:
             l("EEPROM read error: " + str(e))
             return 'phy-sfp'

         # special case: Metanoia xDSL SFP, 1000BASE-X, no link 
autonegotiation
         if self.detect_metanoia_xdsl(ec):
             l("Metanoia DSL SFP detected. Switching to phy-sfp-noneg 
mode.")
             return 'phy-sfp-noneg'

         # special case: Zisa GPON SFP, SGMII
         if self.detect_zisa_gpon(ec):
             l("Zisa GPON SFP detected. Switching to phy-sfp-sgmii mode.")
             return 'phy-sfp-sgmii'

         # SGMII detection
         if self.detect_sgmii(ec):
             return 'phy-sfp-sgmii'

         # default 1000BASE-X
         return 'phy-sfp'



Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ