Issues with SFP transceivers

[Ballmerpeaking]

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.

[anon50890781]

@Ballmerpeaking

After some digging I assume that the problem is with the SFP transceiver or the cable or the Omnia itself.

1. if it being an Omnia with hardware revision not CZ11NIC23 and TOS => 4.x then

@anon50890781

it is currently required to manually activate the SFP Device Tree from the ssh cli with ln -sf armada-385-turris-omnia-sfp.dtb /boot/dtb && reboot

2. 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.

@anon50890781

There has been a recent flurry of SFP related patches from Linux development committed in the OpenWrt Master branch, which yet have to be uplifted into the stable branches, that may improve the situation for SFP modules.

Those may (or may not) remedy your case - I am just not familiar with all the introduced code changes and potential outcome for particular SFP modules.

[Ballmerpeaking]

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?

[viktor]

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

https://git.openwrt.org/?p=openwrt%2Fopenwrt.git&a=search&h=HEAD&st=commit&s=sfp

Or one of the forks and give us feedback.

Turris Omnia: Experimental support for SFP cage

By the way what version of TOS you use?

[Ballmerpeaking]

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.

[viktor]

Move to OpenWrt:

https://openwrt.org/toh/turris/turris_omnia

Move to TOS (Re-flash router):

https://docs.turris.cz/hw/omnia/rescue_modes/

[Ballmerpeaking]

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

EDIT: Found it

[Ballmerpeaking]

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.

[Ballmerpeaking]

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.

[viktor]

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.

[anon50890781]

@Ballmerpeaking

How soon will this stuff make itself into TOS?

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

---

@Ballmerpeaking

I tried TOS 5 and it doesn’t work

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

---

@Ballmerpeaking

but it works with kkudielka ’s branch.

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

[Ballmerpeaking]

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.

[viktor]

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

[Ballmerpeaking]

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

[siska]

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

[siska]

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!

[Ballmerpeaking]

@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.