[HBL] TurrisOS 6.0-alpha2 Halny HL-GSFP SFP GPON Stick problems

Hi,

I just tried to use HALNy HL-GSFP SFP GPON Stick with Turris Omnia.

Here is what I get from module:

root@router:~# dmesg | grep sfp
[    9.283268] sfp sfp: Host maximum power 3.0W
[    9.607535] sfp sfp: module HALNy HL-GSFP          rev V1.0 sn HALN1010493c     dc 20150525
[   18.767300] sfp sfp: module transmit fault indicated
[   27.276284] sfp sfp: module persistently indicates fault, disabling
root@router:~# dmesg | grep mvneta | grep eth2
[    1.465925] mvneta f1034000.ethernet eth2: Using hardware mac address d8:58:d7:00:3d:9f
[    9.615929] mvneta f1034000.ethernet eth2: switched to inband/1000base-x link mode
[   18.413422] mvneta f1034000.ethernet eth2: configuring for inband/1000base-x link mode
[   43.857674] mvneta f1034000.ethernet eth2: configuring for inband/1000base-x link mode
root@router:~# ethtool -m eth2
	Identifier                                : 0x03 (SFP)
	Extended identifier                       : 0x04 (GBIC/SFP defined by 2-wire interface ID)
	Connector                                 : 0x01 (SC)
	Transceiver codes                         : 0x00 0x00 0x00 0x02 0x00 0x00 0x00 0x00 0x00
	Transceiver type                          : Ethernet: 1000BASE-LX
	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                               : HALNy___________
	Vendor OUI                                : 00:00:00
	Vendor PN                                 : HL-GSFP
	Vendor rev                                : V1.0
	Option values                             : 0x00 0x1a
	Option                                    : RX_LOS implemented
	Option                                    : TX_FAULT implemented
	Option                                    : TX_DISABLE implemented
	BR margin, max                            : 0%
	BR margin, min                            : 0%
	Vendor SN                                 : HALN1010493c
	Date code                                 : 20150525
	Optical diagnostics support               : Yes
	Laser bias current                        : 23.346 mA
	Laser output power                        : 1.9932 mW / 3.00 dBm
	Receiver signal average optical power     : 0.0044 mW / -23.57 dBm
	Module temperature                        : 62.85 degrees C / 145.13 degrees F
	Module voltage                            : 3.2999 V
	Alarm/warning flags implemented           : Yes
	Laser bias current high alarm             : Off
	Laser bias current low alarm              : Off
	Laser bias current high warning           : Off
	Laser bias current low warning            : Off
	Laser output power high alarm             : Off
	Laser output power low alarm              : Off
	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   : 60.000 mA
	Laser bias current low alarm threshold    : 0.000 mA
	Laser bias current high warning threshold : 50.000 mA
	Laser bias current low warning threshold  : 0.000 mA
	Laser output power high alarm threshold   : 2.0000 mW / 3.01 dBm
	Laser output power low alarm threshold    : 0.5000 mW / -3.01 dBm
	Laser output power high warning threshold : 2.0000 mW / 3.01 dBm
	Laser output power low warning threshold  : 0.5000 mW / -3.01 dBm
	Module temperature high alarm threshold   : 85.00 degrees C / 185.00 degrees F
	Module temperature low alarm threshold    : -40.00 degrees C / -40.00 degrees F
	Module temperature high warning threshold : 75.00 degrees C / 167.00 degrees F
	Module temperature low warning threshold  : -20.00 degrees C / -4.00 degrees F
	Module voltage high alarm threshold       : 3.6300 V
	Module voltage low alarm threshold        : 2.9700 V
	Module voltage high warning threshold     : 3.4650 V
	Module voltage low warning threshold      : 3.1350 V
	Laser rx power high alarm threshold       : 0.1995 mW / -7.00 dBm
	Laser rx power low alarm threshold        : 0.0010 mW / -30.00 dBm
	Laser rx power high warning threshold     : 0.1000 mW / -10.00 dBm
	Laser rx power low warning threshold      : 0.0020 mW / -26.99 dBm
root@router:~# ethtool -m eth2 raw on | hexdump -C
00000000  03 04 01 00 00 00 02 00  00 00 00 03 0c 00 14 c8  |................|
00000010  00 00 00 00 48 41 4c 4e  79 00 00 00 00 00 00 00  |....HALNy.......|
00000020  00 00 00 00 00 00 00 00  48 4c 2d 47 53 46 50 20  |........HL-GSFP |
00000030  20 20 20 20 20 20 20 20  56 31 2e 30 05 1e 00 aa  |        V1.0....|
00000040  00 1a 00 00 48 41 4c 4e  31 30 31 30 34 39 33 63  |....HALN1010493c|
00000050  20 20 20 20 32 30 31 35  30 35 32 35 68 f0 01 6f  |    20150525h..o|
00000060  00 00 00 01 28 81 25 99  3e fe fa 9f 53 ac d0 e3  |....(.%.>...S...|
00000070  95 b6 5c 00 00 00 00 00  00 00 00 00 29 1f 70 27  |..\.........).p'|
00000080  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000100  55 00 d8 00 4b 00 ec 00  8d cc 74 04 87 5a 7a 76  |U...K.....t..Zzv|
00000110  75 30 00 00 61 a8 00 00  4e 20 13 88 4e 20 13 88  |u0..a...N ..N ..|
00000120  07 cb 00 0a 03 e8 00 14  00 00 00 00 00 00 00 00  |................|
00000130  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000150  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 a1  |................|
00000160  3e d9 80 e7 2d 99 4d dc  00 2b 00 00 00 00 00 00  |>...-.M..+......|
00000170  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000200

I observed that there is no link on the interface. I tried to force link in LUCI but still no wan led on.

When I connect the fiber to ONU from my ISP it detects link almost instantly so the fiber (physically) is fine.

Any ideas how to make it work?

I am on kernel 5.15.62

OLT Profile from ISP
----------------------------------------------------------
 OLT : 1, ONU : 13
---------------------------------------------------------------
 Activation Status                : Active
 Last Activation Fail Reason      : -
 Deactivation Reason              : Admin control(ONU reset)
 Latest Restart Reason            : Not support
 Serial Number                    : HALN1010493c
 Serial Number(Hex)               : 48414c4e1010493c
 Password (R-ID)                  : #REDACTED
 Description                      :
 Learning Method                  : Manual
 Model Name                       : HL-GSFP
 MAC Address                      : 54:db:a2:10:49:3c
 EqD / RTD                        : 240560 / 1331043 bit
 Response Time                    : 34995
 Fiber Distance                   : 672m
 ONU RX Power                     : - 23.8 dBm
 MAX T-CONT                       : 8
 MAX US Priority Queue per T-CONT : 8 (8/8/8/8/8/8/8/8/)
 T-CONT Scheduling Policy         : SPQ
 Activated Time                   :   0:00:08:50
 MIB Upload Count                 : 216 / 216
 MIB Sync Number                  : 31
 SysUpTime                        :   0:00:09:04
 InactiveTime                     :   0:00:00:00
 Vendor Product Code              : 0x0000
 Host Name                        :
 Encryption Key                   : #REDACTED
 OMCC Version                     : 0xa0
 onu-profile                      : GPD-#REDACTED-HL-GSFP-SFU
 VoIP Available signal protocol   : None, VoIP not supported
 VoIP Available config method     : -
 Power over Ethernet Control      : Not support
 Remote Debug                     : Support
 Remote Debug Format              : ASCII
 us-fec-mode                      : Disable

EDIT:
The module was tested in DASAN OLT by my ISP and it worked.
So the SFP module is not faulty.

I updated recently to 5.15 by re-activating updater and my Turris 2,5 GBE SFP+ -module was suddenly not working anymore. Unfortunately I didn’t have the time to troubleshoot (and don’t have at the moment either), so went back to my working config via schnapps.
This might be related.

It is not as Turris SFP+ module does not currently work with kernel 5.15. We are aware of it.

2 Likes

I will revert to previous kernel when I have time and check if it helps. Thanks for the idea!

I checked on previous (5.4.203) kernel and the result is the same.

@Stepan I will contact producer then…

Edit:

This SFP module clearly has a bug in its firmware. I suggest you contact the manufacturer and let him know about fixing it or returning this SFP module.

From the given output, as you can see, the SFP module indicates a laser fault (TX_FAULT). It is pin number 2.

[   18.767300] sfp sfp: module transmit fault indicated
[   27.276284] sfp sfp: module persistently indicates fault, disabling

This SFP module always has this pin set to HIGH (1), and it should use LOW (0) when everything is alright, which is not happening now.

In this case, we made a one-time exception, we managed to introduce hacks together with Linux kernel developers, but we can not support or fix things that are not implemented correctly as our free support can not cover this. Could you let us know if the recent HBL branch works with the SFP module, which you have? Most likely, the kernel needs to be reinstalled.

3 Likes

Wow I am amazed how fast it went and that you as Turris Team got interested. I will test it when I have possibility and report back.

Where can I look at the code that changed?
Edit: patches/openwrt: 5.15: add support for HALny GPON SFP (3cd00f59) · Commits · Turris / Turris OS / Turris Build · GitLab

1 Like

As you can see from the source code, it is a pure hack, bypassing the pin’s wrong usage. We would like to know if you reached the manufacturer and if you got a response from them already. Also, it would be interesting to others with which ISP you are trying to use this module.

Yes, I’ve contacted manufacturer and linked this topic as well.
But they didn’t answer yet.
And I tried the patch but it makes no difference at all:

root@router:~# uname -r
5.15.63
root@router:~# ethtool eth2
Settings for eth2:
	Supported ports: [ FIBRE ]
	Supported link modes:   1000baseX/Full 
	Supported pause frame use: Symmetric
	Supports auto-negotiation: Yes
	Supported FEC modes: Not reported
	Advertised link modes:  1000baseX/Full 
	Advertised pause frame use: Symmetric
	Advertised auto-negotiation: Yes
	Advertised FEC modes: Not reported
	Speed: 1000Mb/s
	Duplex: Full
	Port: FIBRE
	PHYAD: 0
	Transceiver: internal
	Auto-negotiation: on
	Supports Wake-on: d
	Wake-on: d
	Link detected: no
root@router:~# dmesg | grep eth2
[    1.616071] mvneta f1034000.ethernet eth2: Using hardware mac address d8:58:d7:00:3d:9f
[    9.816179] mvneta f1034000.ethernet eth2: switched to inband/1000base-x link mode
[   18.958108] mvneta f1034000.ethernet eth2: configuring for inband/1000base-x link mode
root@router:~# dmesg | grep sfp
[    9.468447] sfp sfp: Host maximum power 3.0W
[    9.807784] sfp sfp: module HALNy HL-GSFP          rev V1.0 sn HALN1010493c     dc 20150525
[   19.286521] sfp sfp: module transmit fault indicated
[   27.516533] sfp sfp: module persistently indicates fault, disabling

Can you tell us who is your ISP?

New local polish fiber provider

There is no english version of the website yet…
ASN: AS210866 Ab-engineering

Yes, I know, I am so sorry. That’s my fault. During rebasing patch series for kernel 5.15, I forgot to modify one file. I will fix it.

1 Like

So I tried today with your fixes and the module still “indicates fault, disabling”. So I am waiting for the answer of the producer. What they might say about their faulty module.?

Just to confirm, did you test with the “patches/openwrt: fix naming of HALNy SFP module” fix in place? Thanks.

Most likely the patch was done by @Pepe 15 hours ago and I tried just an hour ago.

root@router:~# cat /etc/openwrt_release                                     
DISTRIB_ID='TurrisOS'
DISTRIB_RELEASE='6.0-alpha2'
DISTRIB_REVISION='r16627+120-b93327c469'
DISTRIB_TARGET='mvebu/cortexa9'
DISTRIB_ARCH='arm_cortex-a9_vfpv3-d16'
DISTRIB_DESCRIPTION='TurrisOS 6.0-alpha2 b93327c4692e605649ff1afade98899a9c4a
a1ca'
DISTRIB_TAINTS='busybox'

Owww its you Russell the author. Yeah seems like there is no change. I am willing to test further.

We do have this SFP module in our office, so we will try it on our end as well to rule out any misconfiguration. But first we need to prepare the GPON OLT, right @hagrid?

2 Likes

Again luck, thanks! Waiting patiently.

We know that the tx fault work works, because it’s used with the Huawei module. I’ve just hacked up a userspace program to test, grabbed your hexdump, converted it to binary, and tested against that, and the quirk matching works. So I’m suspicious about the code that has been tested.

I’m not up to speed with the build system, so I don’t know how the git hashes correspond. Are we absolutely sure that:

DISTRIB_REVISION='r16627+120-b93327c469'
DISTRIB_DESCRIPTION='TurrisOS 6.0-alpha2 b93327c4692e605649ff1afade98899a9c4aa1ca'

corresponds with a kernel built from:

?

I am not sure. What I did is I reverted to snapshot with previous kernel (quite older) and I did pkgupdate so it should pick the latest changes from HBL branch. But I dont really know how to check if it builded already.

Edit: According to the date here:
https://repo.turris.cz/hbl/omnia/packages/
Build is at 13:58 and I tested it before. So I will try again