| 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
| ||
|
Date: Sun, 3 Jan 2021 03:41:32 +0100
From: Pali Rohár <pali@...nel.org>
To: Thomas Schreiber <tschreibe@...il.com>
Cc: Andrew Lunn <andrew@...n.ch>,
Russell King - ARM Linux admin <linux@...linux.org.uk>,
Heiner Kallweit <hkallweit1@...il.com>,
"David S. Miller" <davem@...emloft.net>,
Jakub Kicinski <kuba@...nel.org>,
Marek Behún <kabel@...nel.org>,
netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/4] net: sfp: add workaround for Realtek RTL8672 and
RTL9601C chips
Hello!
On Sunday 03 January 2021 03:25:23 Thomas Schreiber wrote:
> Hi Pali,
> I have a CarlitoxxPro module and I reported an issue about RX_LOS pin
> to the manufacturer.
> It looks to me that the module asserts "inverted LOS" through EEPROM
> but does not implement it.
So, it is broken :-( But I'm not surprised.
Anyway, I think you could be interested in this discussion about my
patch series, but I forgot to CC you on the first patch/cover letter.
You can read whole discussion on public archive available at:
https://lore.kernel.org/netdev/20201230154755.14746-1-pali@kernel.org/t/#u
If you have any comments, let me know so I can fix it for V2.
Those RTL8672/RTL9601C SFP are extremely broken and I do not think that
"rebrander" CarlitoxxPro would do anything with it.
> Consequently, the SFP state machine of my
> host router stays in check los state and link is not set up for the
> host interface.
So link does not work at all?
> Below is a dump of the module's EEPROM:
>
> [root@...arfog-gt-8k ~]# ethtool -m eth0
> Identifier : 0x03 (SFP)
> Extended identifier : 0x04 (GBIC/SFP defined by
> 2-wire interface ID)
> Connector : 0x01 (SC)
> Transceiver codes : 0x00 0x00 0x00 0x00 0x00
> 0x00 0x00 0x00 0x00
> Encoding : 0x03 (NRZ)
> BR, Nominal : 1200MBd
> Rate identifier : 0x00 (unspecified)
> Length (SMF,km) : 20km
> Length (SMF) : 20000m
> Length (50um) : 0m
> Length (62.5um) : 0m
> Length (Copper) : 0m
> Length (OM3) : 0m
> Laser wavelength : 1310nm
> Vendor name : VSOL
> Vendor OUI : 00:00:00
> Vendor PN : V2801F
> Vendor rev : 1.0
> Option values : 0x00 0x1c
> Option : RX_LOS implemented, inverted
> Option : TX_FAULT implemented
> Option : TX_DISABLE implemented
> BR margin, max : 0%
> BR margin, min : 0%
> Vendor SN : CP202003180377
> Date code : 200408
> Optical diagnostics support : Yes
> Laser bias current : 0.000 mA
> Laser output power : 0.0000 mW / -inf dBm
> Receiver signal average optical power : 0.0000 mW / -inf dBm
> Module temperature : 31.00 degrees C / 87.80 degrees F
> Module voltage : 0.0000 V
> Alarm/warning flags implemented : Yes
> Laser bias current high alarm : Off
> Laser bias current low alarm : On
> Laser bias current high warning : Off
> Laser bias current low warning : Off
> Laser output power high alarm : Off
> Laser output power low alarm : On
> Laser output power high warning : Off
> Laser output power low warning : Off
> Module temperature high alarm : Off
> Module temperature low alarm : Off
> Module temperature high warning : Off
> Module temperature low warning : Off
> Module voltage high alarm : Off
> Module voltage low alarm : Off
> Module voltage high warning : Off
> Module voltage low warning : Off
> Laser rx power high alarm : Off
> Laser rx power low alarm : Off
> Laser rx power high warning : Off
> Laser rx power low warning : Off
> Laser bias current high alarm threshold : 74.752 mA
> Laser bias current low alarm threshold : 0.000 mA
> Laser bias current high warning threshold : 0.000 mA
> Laser bias current low warning threshold : 0.000 mA
> Laser output power high alarm threshold : 0.0000 mW / -inf dBm
> Laser output power low alarm threshold : 0.0000 mW / -inf dBm
> Laser output power high warning threshold : 0.0000 mW / -inf dBm
> Laser output power low warning threshold : 0.0000 mW / -inf dBm
> Module temperature high alarm threshold : 90.00 degrees C / 194.00 degrees F
> Module temperature low alarm threshold : 0.00 degrees C / 32.00 degrees F
> Module temperature high warning threshold : 0.00 degrees C / 32.00 degrees F
> Module temperature low warning threshold : 0.00 degrees C / 32.00 degrees F
> Module voltage high alarm threshold : 0.0000 V
> Module voltage low alarm threshold : 0.0000 V
> Module voltage high warning threshold : 0.0000 V
> Module voltage low warning threshold : 0.0000 V
> Laser rx power high alarm threshold : 0.1536 mW / -8.14 dBm
> Laser rx power low alarm threshold : 0.0000 mW / -inf dBm
> Laser rx power high warning threshold : 0.0000 mW / -inf dBm
> Laser rx power low warning threshold : 0.0000 mW / -inf dBm
>
>
> Le sam. 2 janv. 2021 à 02:49, Pali Rohár <pali@...nel.org> a écrit :
> >
> > On Thursday 31 December 2020 18:13:38 Andrew Lunn wrote:
> > > > > Looking at sfp_module_info(), adding a check for i2c_block_size < 2
> > > > > when determining what length to return. ethtool should do the right
> > > > > thing, know that the second page has not been returned to user space.
> > > >
> > > > But if we limit length of eeprom then userspace would not be able to
> > > > access those TX_DISABLE, LOS and other bits from byte 110 at address A2.
> > >
> > > Have you tested these bits to see if they actually work? If they don't
> > > work...
> >
> > On Ubiquiti module that LOS bit does not work.
> >
> > I think that on CarlitoxxPro module LOS bit worked. But I cannot test it
> > right now as I do not have access to testing OLT unit.
> >
> > Adding Thomas to loop. Can you check if CarlitoxxPro GPON ONT module
> > supports LOS or other bits at byte offset 110 at address A2?
Powered by blists - more mailing lists