| 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
| ||
|
Message-ID: <b6a4604e-55bd-4ab7-9cf2-05fb94e72500@kabelmail.de>
Date: Fri, 13 Jun 2025 11:37:30 +0200
From: Janpieter Sollie <janpieter.sollie@...elmail.de>
To: Andrew Lunn <andrew@...n.ch>
Cc: netdev@...r.kernel.org
Subject: Re: [support request]: where should I register this (apparently not
supported yet) transceiver?
Op 12/06/2025 om 14:18 schreef Andrew Lunn:
> On Thu, Jun 12, 2025 at 10:58:23AM +0200, Janpieter Sollie wrote:
>> Hi Everyone, I'm looking for support to register my trainsceiver in the phy subsystem. This
>> RJ45 transceiver (ZK-10G-TX) looks very weird in ethtool: |> Identifier : 0x03 (SFP)
>>> Extended identifier : 0x04 (GBIC/SFP defined by 2-wire interface ID) Connector : 0x07 (LC)
>>> Transceiver codes : 0x10 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 Transceiver type : 10G
>>> Ethernet: 10G Base-SR Encoding : 0x06 (64B/66B) BR Nominal : 10300MBd Rate identifier : 0x00
>>> (unspecified) Length (SMF) : 0km Length (OM2) : 80m Length (OM1) : 20m Length (Copper or
>>> Active cable) : 0m Length (OM3) : 300m Laser wavelength : 850nm Vendor name : OEM Vendor OUI
>>> : 00:1b:21 Vendor PN : ZK-10G-TX Vendor rev : 1 Option values : 0x00 0x1a Option :
>>> TX_DISABLE implemented BR margin max : 0% BR margin min : 0% Vendor SN : 2505010443 Date
>>> code : 250412 Optical diagnostics support : Yes Laser bias current : 6.000 mA Laser output
>>> power : 0.5000 mW / -3.01 dBm Receiver signal average optical power : 0.4000 mW / -3.98 dBm
>> ... I cannot read its pages with i2c tools. It has a big "AQR113C" sticker on it,
> The protocol to talk to the PHY is not defined in the standards. However, there are two main
> protocols. It could be this PHY needs rollball. Please try adding an entry to
> drivers/net/phy/sfp.c:sfp_quirk[] for this SFP, using sfp_fixup_rollball. It might work, it
> might not... Andrew
Hi Andrew,
Thank you for your support,
I added the following quirk in sfp.c:
--- a/drivers/net/phy/sfp.c
+++ b/drivers/net/phy/sfp.c
@@ -515,6 +515,7 @@
SFP_QUIRK_F("OEM", "SFP-GE-T", sfp_fixup_ignore_tx_fault),
SFP_QUIRK_F("OEM", "SFP-10G-T", sfp_fixup_rollball_cc),
+SFP_QUIRK_F("OEM", "ZK-10G-TX", sfp_fixup_rollball_cc),
SFP_QUIRK_M("OEM", "SFP-2.5G-T", sfp_quirk_oem_2_5g),
SFP_QUIRK_M("OEM", "SFP-2.5G", sfp_quirk_oem_2_5g),
SFP_QUIRK_M("OEM", "SFP-2.5G-BX10-D", sfp_quirk_2500basex),
Unfortunately, the result was not as I'd expect (on kernel 6.12.32):
> ... (booting kernel 6.12.32 with quirk) ...
> [ 37.832050] mtk_soc_eth 15100000.ethernet sfp-lan:
validation with support 00,00000000,00000000,00000000 failed: -EINVAL
> [ 37.843056] sfp sfp2: sfp_add_phy failed: -EINVAL
> ...
I tried the eepromfix of i2csfp:
> root@...ureau4:~# i2csfp sfp1 eepromfix
> [ 1141.132693] sfp sfp1: module removed
> Checksum 0x00-0x3e matched 89
> Checksum 0x40-0x5e matched 9b
> RollBall Password used: 0x63737777
> Checksum 0x00-0x3e matched 89
> Checksum 0x40-0x5e matched 9b
> root@...ureau4:~# i2csfp sfp1 restore
> [ 1154.964505] sfp sfp1: Host maximum power 3.0W
> root@...ureau4:~# [ 1155.287121] sfp sfp1: module OEM
ZK-10G-TX rev 1 sn 2505010443 dc 250412
> [ 1155.336988] hwmon hwmon1: temp1_input not attached to any thermal zone
>
> root@...ureau4:~# [ 1163.222307] mtk_soc_eth 15100000.ethernet sfp-wan:
validation with support 00,00000000,00000000,00000000 failed: -EINVAL
> [ 1163.233253] sfp sfp1: sfp_add_phy failed: -EINVAL
the link is down ... there's no traffic on this link
However, ethtool shows some positive news:
> ethtool sfp-wan
> Settings for sfp-wan:
> Supported ports: [ MII ]
> Supported link modes: 10baseT/Half 10baseT/Full
> 100baseT/Half 100baseT/Full
> 1000baseT/Half 1000baseT/Full
> 10000baseT/Full
> 2500baseX/Full
> 1000baseKX/Full
> 10000baseKX4/Full
> 10000baseKR/Full
> 10000baseR_FEC
> 1000baseX/Full
> 10000baseCR/Full
> 10000baseSR/Full
> 10000baseLR/Full
> 10000baseLRM/Full
> 10000baseER/Full
> 2500baseT/Full
> 5000baseT/Full
> 100baseT1/Full
> 1000baseT1/Full
> 100baseFX/Half 100baseFX/Full
> 10baseT1L/Full
> 10baseT1S/Full
> 10baseT1S/Half 10baseT1S_P2MP/Half
> Supported pause frame use: Symmetric Receive-only
> Supports auto-negotiation: Yes
> Supported FEC modes: Not reported
> Advertised link modes: 10000baseT/Full
> 10000baseKX4/Full
> 10000baseKR/Full
> 10000baseR_FEC
> 10000baseCR/Full
> 10000baseSR/Full
> 10000baseLR/Full
> 10000baseLRM/Full
> 10000baseER/Full
> Advertised pause frame use: Symmetric Receive-only
> Advertised auto-negotiation: Yes
> Advertised FEC modes: Not reported
> Speed: 10000Mb/s
> Duplex: Full
> Auto-negotiation: on
> Port: MII
> PHYAD: 0
> Transceiver: internal
> Current message level: 0x000000ff (255)
> drv probe link timer ifdown ifup rx_err tx_err
> Link detected: no
When playing with "ip link down / up",
I ultimately came to a point where this host and the endpoint agreed the link was up,
but no communication was possible.
Do you have a suggestion based on the error output of the sfp driver?
Thank you,
Janpieter Sollie
Powered by blists - more mailing lists