Issues with SFP transceivers

I was unable to receive a an IP address from my ISP. After some digging I assume that the problem is with the SFP transceiver or the cable or the Omnia itself.

I noticed that tcpdump showed no traffic on the WAN interface, even if I ran udhcpc on it.

cat /sys/class/net/eth2/carrier is always 0 no matter what I plug in.
eth2 is the wan interface according to /etc/config/network.

I have two SFP transceivers and patch cables. All of them I’ve tested with my old router and internet connection.

They are SFP-31W2ASM-10-DR and Siligence, SGA 441SFPO-1Gb, 1.25G T1310nm/R1490nm 10 km DDM.

Is it possible that these are incompatible with the Turris Omnia? I’m starting to reach my wit’s end.

  1. if it being an Omnia with hardware revision not CZ11NIC23 and TOS => 4.x then
  1. it is known that some SFP modules facing trouble that is mostly caused due the SFP implementation by upstream sources (OpenWrt and/or Linux). The systemlog does provide some output in regards to SFP.

I have a CZ11NIC20, but I flashed the newest OS version. Anyway, the symlink didn’t change anything.

One transceiver produces a bunch of “sfp sfp: no PHY” messages.
With the other I get mvneta f1034000.ethernet eth2: validation of 802.3z/1000base-x with support 00000,00002440 failed: -22.

If I wanted to take advantage of the more recent SFP changes in the Kernel, would I have to compile my own kernel?

Are there any other OS which might have better hardware support? OpenWRT? FreeBSD? OpenBSD?

Welcome to the club. Try OpenWrt kernel 4.19 with backported SFP drivers or 5.4.

Or one of the forks and give us feedback.

By the way what version of TOS you use?

How hard is it to move back to move back to TOS after installing openwrt?

TOS is at 4.0.5, which should be the latest.

Move to OpenWrt:

Move to TOS (Re-flash router):

Do I need to repackage the initramfs? The only downloads I see are zimges but the guide talks about a tarball.

EDIT: Found it

I’ve gotten a hold of a Flexoptic S.B1312.10.XDL transceiver. Is it different than the S.B1312.10.XDL-TUR01 one? Do I need to configure it somehow?

This is on TOS 4
grep -iE ‘sfp|eth2|phy’ /var/log/messages gives me:

Apr  9 21:12:10 turris kernel: [    5.128163] libphy: mv88e6xxx SMI: probed
Apr  9 21:12:10 turris kernel: [    5.848369] mv88e6085 f1072004.mdio-mii:10 lan0 (uninitialized): PHY [mv88e6xxx-1:00] driver [Marvell 88E1540]
Apr  9 21:12:10 turris kernel: [    5.975430] mv88e6085 f1072004.mdio-mii:10 lan1 (uninitialized): PHY [mv88e6xxx-1:01] driver [Marvell 88E1540]
Apr  9 21:12:10 turris kernel: [    6.095429] mv88e6085 f1072004.mdio-mii:10 lan2 (uninitialized): PHY [mv88e6xxx-1:02] driver [Marvell 88E1540]
Apr  9 21:12:10 turris kernel: [    6.225428] mv88e6085 f1072004.mdio-mii:10 lan3 (uninitialized): PHY [mv88e6xxx-1:03] driver [Marvell 88E1540]
Apr  9 21:12:10 turris kernel: [    6.347677] mv88e6085 f1072004.mdio-mii:10 lan4 (uninitialized): PHY [mv88e6xxx-1:04] driver [Marvell 88E1540]
Apr  9 21:12:10 turris kernel: [   15.421538] ieee80211 phy1: Selected rate control algorithm 'minstrel_ht'
Apr  9 21:12:10 turris kernel: [   15.424274] ieee80211 phy1: Atheros AR9287 Rev:2 mem=0xf1010000, irq=79
Apr  9 21:12:10 turris kernel: [   20.800876] mv88e6085 f1072004.mdio-mii:10 lan0: configuring for phy/gmii link mode
Apr  9 21:12:10 turris kernel: [   20.906604] mv88e6085 f1072004.mdio-mii:10 lan1: configuring for phy/gmii link mode
Apr  9 21:12:10 turris kernel: [   21.000704] mv88e6085 f1072004.mdio-mii:10 lan2: configuring for phy/gmii link mode
Apr  9 21:12:10 turris kernel: [   21.112259] mv88e6085 f1072004.mdio-mii:10 lan3: configuring for phy/gmii link mode
Apr  9 21:12:10 turris kernel: [   21.264912] mv88e6085 f1072004.mdio-mii:10 lan4: configuring for phy/gmii link mode
Apr  9 21:12:10 turris kernel: [   21.462984] mvneta f1034000.ethernet eth2: PHY [f1072004.mdio-mii:01] driver [Marvell 88E1510]
Apr  9 21:12:10 turris kernel: [   21.472247] mvneta f1034000.ethernet eth2: configuring for phy/sgmii link mode
Apr  9 21:12:10 turris kernel: [   21.479933] IPv6: ADDRCONF(NETDEV_UP): eth2: link is not ready
Apr  9 21:19:19 turris kernel: [  460.421350] device eth2 entered promiscuous mode
Apr  9 21:22:30 turris kernel: [  651.917913] device eth2 left promiscuous mode

Idk what I could do to diagnose this.

How soon will this stuff make itself into TOS? I tried TOS 5 and it doesn’t work, but it works with kkudielka’s branch.

Thank you for the useful feedback. TOS 6 will use OpenWrt 20.x branch with kernel 5.4 and better SFP support. Furthermore it depends also on the received backported patches. The good news is EOL of OpenWrt 19.07 and probably also TOS 5 in January 2021.

This is a brief statement of the facts that the further elaborated @anon50890781.

as soon/late as relevant patches are backported in the respective branches of either OpenWrt or TOS

is based on OpenWrt 19.7.x and neither as of today received relevant patches

as far as I can tell the developer:

  • adapted a device tree specific/tailored to the SFP module (TP-Link TL-SM321B), which is neither generally available in OpenWrt or in TOS
  • enabled I2C MUX support for the TO target, which is enabled in TOS
  • backported support for 1000BaseBX10 SFP from mainline kernel, which:
    • is not available in OpenWrt stable branches
    • might be available in OpenWrt Master branch
    • is currently not available in any TOS branch
    • OpenWrt Master branch code is currently not available/accessible via the TOS build bots

I ordered a new SFP transceiver from my ISP, who configured it for the Turris Omnia. It’s still not recognized. Is my Omnia broken? I don’t understand this.

Your Omnia is not broken. SFP transceiver is probably not supported. But first, try:

ln -sf armada-385-turris-omnia-sfp.dtb /boot/dtb && reboot

1 Like

Haha, how embarrassing. That fixed it. Sorry, I was really starting to become frustrated :grimacing:.

Hi @Ballmerpeaking,

Thank you for the message. I am using same transceiver (from ISP Swiss Sunrise) as you had problem with (LCS SFP-31W2ASM-10-DR). It still does not work on TOS 5.1.4

In your latest post you are mentionig that you got new SFP that works now, would you mind sharing model please?

Thank you

Dear @anon50890781,

I was wondering if there is a timeline for backporting SFP support to TOS 5.x

I am suffering from same issues as described by @Ballmerpeaking.

Thank you!

@siska Sorry for the late reply. I ended up getting a new transceiver from my ISP (Init7). It worked after that. I believe I managed to get the one of the transceivers to work with the router, but I did not get the transceiver to work with the ISP. Fiber is an extremely complicated topic, I really don’t understand much about so I just opted to pay.