SFP HALNY HL-GSFP GPON not connecting - Turris Omnia HBS [6.2.4]

Omnia hardware Omnia HW help
#1

Cheers
I have the “black” Omnia. I’m currently using CETIN (for CZ/SK readers) FTTH connection with media convertor to copper. So I bought the HALNY SFP module. However I cannot make it work even though I went through the forum.
Because of the connection I have another device eth2.848 on which I created another WAN PPoE interface (keeping the WAN in case I need to fall back). On copper, everything is working just fine.

ethtool

[ 1.816570] mvneta f1034000.ethernet eth2: Using hardware mac address d8:58:d7:00:6a:93
[ 13.117706] mvneta f1034000.ethernet eth2: PHY [f1072004.mdio-mii:01] driver [Marvell 88E1510] (irq=POLL)
[ 13.127510] mvneta f1034000.ethernet eth2: configuring for phy/sgmii link mode
[ 16.247135] mvneta f1034000.ethernet eth2: Link is Up - 1Gbps/Full - flow control rx/tx
[ 16.256693] IPv6: ADDRCONF(NETDEV_CHANGE): eth2: link becomes ready
[ 16.266486] IPv6: ADDRCONF(NETDEV_CHANGE): eth2.848: link becomes ready

So I created symlink
root@omnia:~# readlink /boot/dtb

/boot/armada-385-turris-omnia-sfp.dtb

and rebooted
SFP seems to be recognized (?)
root@omnia:~# dmesg | grep sfp

[ 7.806825] sfp sfp: Host maximum power 3.0W
[ 8.147917] sfp sfp: module HALNy HL-GSFP rev V1.0 sn HALN10104289 dc 20150525

but eth2 is still using the MAC of copper and not MAC of SFP → link is down and connection is not working :frowning:
root@omnia:~# dmesg | grep eth

[ 1.784676] mvneta f1070000.ethernet eth0: Using device tree mac address d8:58:d7:00:6a:93
[ 1.794218] mvneta f1030000.ethernet eth1: Using hardware mac address d8:58:d7:00:6a:92
[ 1.803503] mvneta f1034000.ethernet eth2: Using hardware mac address d8:58:d7:00:6a:93
[ 8.156307] mvneta f1034000.ethernet eth2: switched to inband/1000base-x link mode
[ 12.186663] mvneta f1030000.ethernet eth1: configuring for fixed/rgmii link mode
[ 12.194611] mvneta f1030000.ethernet eth1: Link is Up - 1Gbps/Full - flow control off
[ 12.206830] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
[ 12.322665] device eth1 entered promiscuous mode
[ 13.085949] mvneta f1034000.ethernet eth2: configuring for inband/1000base-x link mode
[ 13.146811] mvneta f1034000.ethernet eth2: Link is Up - 1Gbps/Full - flow control rx/tx
[ 13.154868] IPv6: ADDRCONF(NETDEV_CHANGE): eth2: link becomes ready
[ 13.161384] IPv6: ADDRCONF(NETDEV_CHANGE): eth2.848: link becomes ready
[ 38.571629] mvneta f1034000.ethernet eth2: Link is Down
[ 38.584332] mvneta f1034000.ethernet eth2: configuring for inband/1000base-x link mode
[ 38.627455] mvneta f1034000.ethernet eth2: Link is Up - 1Gbps/Full - flow control rx/tx
[ 38.635540] IPv6: ADDRCONF(NETDEV_CHANGE): eth2: link becomes ready
[ 38.642136] IPv6: ADDRCONF(NETDEV_CHANGE): eth2.848: link becomes ready

#2

I am using Halny stick and it works. The WAN connection on eth2 is one of the two. Try disconnecting copper and rebooting. The MAC address could be the same for copper and fiber. Also try soft rebooting two times in a row to be sure. I got a problem that link was not getting up after power failures and I had to reboot again to get it to work

#3

Also try to ask your ISP to register the stick on their side. I got mine from my ISP already configured. You have to set some GPON specific parts for it to work.

#4

Im have the same SFP and its doesnt recognize it .with last uboot and turris os

#5

Thats weird. I just reflashed medkit lately HBS and it recognized it right away. Didnt even have to switch dbt to sfp. I just set VLAN to the right one. Credentials. And bam internet. All from Reforis. Is your Stick configured?

#6

yes its configured but the behavior its strange i forced to recognize the DTB but still is no recognized
(you are using last uboot too?)

#7

@backon Yes I did nor-upgrade and I am using the latest U-Boot

#8

@AreYouLoco you can access to the sfp module via SSH to check the configuration?

#9

Actually I would like to do that because there was nowhere information on HALNy website how to access console on SFP. I got mine already configured from ISP. I would have to ask them about IP address of that thing.

#10

i modified the password via uart serial and then connected via ssh port 22666 (default ip 192.168.77.154 mask 255.255.255.252) to check too if its working well with olt

Finally i got the issue. When i power cycle the router doesnt recognize it the Hanly module so i wait for 1 min and reboot manually the router starts recognizing it.

#11

I get the same issue when there is power failure then when the router comes back it doesnt recognize SFP and I have to do soft reboot for it to be seen. So there is definitely an issue here. Maybe you could report it via GitLab. And mark this topic as solved

1 Like
#12

I made a gitlab ticket finally because affects too to zisa OP151S

#13

@backon how did you access uart? Is precise soldering needed?

#14

You can access uart via 2 solder pads (are big and doesnt require solder and open anything) see the photo

you need to power 3.3v it via SFP connector. Baudrate 38400 8N1 . Enter in failsafe mode (f+enter) and mount_root and the change password, after that you can access via SSH with user root and the password that you have settled

3ca0c538193557baaf8a11e3ea6608fb05d0d2ff
3ca0c538193557baaf8a11e3ea6608fb05d0d2ff1791×978 352 KB

2 Likes
#15

Well, the issue is the SFP module itself. It does not identify itself as SFP until the internal computer fully boots up (it takes about 1 minute), so when you cold boot the Omnia, the SFP detection fails and the magnetics become active. The SFP gets active during the boot of Omnia, so when you perform the reboot, it gets successfully detected and becomes active in the TOS.

1 Like
#16

Is it possible to fix that on SFP only?

#17

in older turris os was working well(on mikrotik works well so maybe is turris omnia sfp cage configuration.? make maybe after power up turris omnia wait 30 secs before read and load the sfp interface?

Other option is disable automatic detection (make a menu from reforis to switch between cable or sfp cage and always boot from sfp to avoid this issue?)

1 Like
#18

You can try it by running fw_setenv bootdelay 30

1 Like
#19

Standard boot delay is: bootdelay=3. I will consider checking that delay to always have connectivity even if boot will take longer. For now I am testing crashlab so I don’t want to modify anything to hunt for other bug.
But thanks @hagrid

@backon did you try it out?

#20

@AreYouLoco Yes i have tried but it need to be bootdelay 60 (30 sec look too short), with 60sec works perfect. i need to adjust and lower timing for faster bootup but for now its resolved with this solution.

2 Likes