Supported SFP modules

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.


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

little late but better then never, I’m using the CTS INC. SFP-31W2ASM10-DR module. it works w/ TOS 3 but not w/ TOS 4 (VLAN issues as described on many pages in this forum - however it seems to be an issue of TOS rather then the hw).

Is it just a VLAN issue? If so you may have a look at [4] since it is unrelated to SFP or caused by TOS.

Also, unless you got a CZ11NIC23 board revision (retails as Omnia 2019), 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

If none of the above is applicable perhaps you could elaborate on the matter?


[4] DSA and 802.1Q tagging

1 Like

Google Photos
This is not the case, if the module is incompatible, it will continue to not automatically switch to SFP. This at least is what happens to me. Much does not work anyway, but if I switch to SFP at least in dmesg I see mentioned the module, the model etc. If I let Turris OS 4.x do it, it simply goes to the WAN port even with the SFP module inserted.
Maybe mine is also a counterfeit version, because from Discomp it was sent to me with Turris OS 3.x, while in the official documentation it is written that this revision already mounts 4.x natively.

@anon50890781, thank you for the reference documentation you created.

The current device i’m working with has the revision CZ11NIC13.
My ISP (Sunrise in Switzerland) requires me to set the VLAN ID to 10 (tagged) on the WAN port (in TOS v4.0.6 eth2) and use DHCP to get connectivity - works with TOS3 (based on eth1) like a charm.

I have activated correctly linked the /boot/dtb (based on your input in other threads) and can see that the SFP is recognized in dmesg:

[    5.302596] sfp sfp: module CTS INC.         SFP-31W2ASM10-DR rev 1.0  sn <serial-nr>  dc 27-01-16
[    5.311932] sfp sfp:   LC connector, encoding 8b10b, nominal bitrate 1.3Gbps +0% -0%
[    5.319694] sfp sfp:   1000BaseSX- 1000BaseLX+ 1000BaseCX- 1000BaseT- 100BaseTLX+ 1000BaseFX- BaseBX10- BasePX-
[    5.329809] sfp sfp:   10GBaseSR- 10GBaseLR- 10GBaseLRM- 10GBaseER-
[    5.336093] sfp sfp:   Wavelength 1310nm, fiber lengths:
[    5.341420] sfp sfp:     9µm SM    : 10000m
[    5.345698] sfp sfp:  62.5µm MM OM1: unsupported/unspecified
[    5.351459] sfp sfp:    50µm MM OM2: unsupported/unspecified
[    5.357217] sfp sfp:    50µm MM OM3: unsupported/unspecified
[    5.362977] sfp sfp:    50µm MM OM4: unsupported/unspecified
[    5.368736] sfp sfp:   Options: txdisable, txfault, los+
[    5.374062] sfp sfp:   Diagnostics: ddm, intcal, rxpwravg

so it looks good, but dmesg gets also flooded with:

[ 1295.171830] sfp sfp: no PHY detected
[ 1295.351764] sfp sfp: no PHY detected
[ 1295.531768] sfp sfp: no PHY detected

Something seems to be wrong with the recognition of the connection, why i don’t get an IP addr on WAN (eth2.10) either.

In /etc/config/network it is set as following:

config interface 'wan'
        option proto 'dhcp'
        option ifname 'eth2.10'
        option ipv6 '0'

I would appreciate any hint…

that is where the issue lies as being printed by SFC.C [4]

As far I understand phy_probe fails and thus the link state will be probably showing down a/o NO CARRIER - check with ip l sh dev eth2

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.


[4] https://github.com/torvalds/linux/blob/master/drivers/net/phy/sfp.c#L1977

Kernel 5.4 is coming.

I have a few SFP modules I tried, and the one which works and connects is this:
Fiberstore SFP-1G31-10
This seems to be an older out of sale module, and not available any more, my guess is the newer module will work too: https://www.fs.com/products/12622.html But it’s only a 1Gig module, not a 2.5Gig.

These ones I tried and they don’t work:

  • Fiberstore DSFP-10G31-10 10G: This is understandable, this is a 10G only module, and Omnia/MOX supports 2.5G max. Older out of sale model, the new model is https://www.fs.com/products/11555.html
  • Fiberstore 10GSFP-PC-30-0.5 10G: This is a 10G DAC cable. Out of sale older version of https://www.fs.com/products/40109.html I’m pretty sure the newer version I linked won’t work either.
  • OCLARO TRF5916AVLB643 2.5G: I bought this to connect my Omnia with my MOX on 2.5G so disappointed it doesn’t work. https://ebay.us/a0Zcun
  • Compufox AGC761 1G/2.5G: Disappointed again, hoped it would work at least at 1G speed, but it does not connect at all. https://www.amazon.com/dp/B00GUM7R2G/

Please note that seeing messages in dmesg about the SFP module being detected does NOT mean it will work. All modules I tested were detected in dmesg, but only 1 was actually be able to bring up the link.

I still haven’t found any SFP module which would work at 2.5G speed.

All of these were tested with the default Here Be Snails (Stable) branch. And as suggested above the HBD branch with the newer kernel might work. But I don’t want to switch my Omnia to the HBD branch because I depend on it, so I’ve ordered another MOX and after it arrives I can test between two MOX devices with the HBD branch. I’ll update when it arrives.

2 Likes

Hi @bugrasan

I am facing the same issue with Sunrise SFP after Turris OS update to 5.1.4

I was wondering if you were able to solve it.

Thank you

Hi @siska unfortunately last year i couldn’t get it working. I was hoping to try it again with the new 5.x in couple of weeks - still on my to do list.
I will update this thread as soon as i have found a solution - if i don’t forget :worried:
in case you find a solution earlier than me, i would appreciate a hint :slight_smile:

Hi @bugrasan,

Unfortunately, I was not able to make it work on TOS 5.1.4 neither. Quite a pity.

In the end, I just purchased Tp-Link MC220L so I can move forward and keep using Turris Omnia.

This is not great help but at least one additional work-around.

Have a nice day

1 Like

I’ve managed to get a pair of Generic Compatible 1000BASE-LX/LH SFP 1310nm 10km DOM Transceiver Module 1Gbit SFPs to work between two Omnias, one is a CZ11NIC13 the other is a CZ11NIC23.

FS part number: SFP1G-LX-31

kernel: [   12.092553] sfp sfp: module FS               SFP1G-LX-31      rev A0   sn G2036046479      dc 07-08-20
kernel: [   12.101902] sfp sfp:   LC connector, encoding 8b10b, nominal bitrate 1.3Gbps +0% -0%
kernel: [   12.109665] sfp sfp:   1000BaseSX- 1000BaseLX+ 1000BaseCX- 1000BaseT- 100BaseTLX- 1000BaseFX- BaseBX10- BasePX-
kernel: [   12.119809] sfp sfp:   10GBaseSR- 10GBaseLR- 10GBaseLRM- 10GBaseER-
kernel: [   12.126108] sfp sfp:   Wavelength 1310nm, fiber lengths:
kernel: [   12.131445] sfp sfp:     9µm SM    : 10000m
kernel: [   12.135731] sfp sfp:  62.5µm MM OM1: unsupported/unspecified
kernel: [   12.141504] sfp sfp:    50µm MM OM2: unsupported/unspecified
kernel: [   12.147264] sfp sfp:    50µm MM OM3: unsupported/unspecified
kernel: [   12.153034] sfp sfp:    50µm MM OM4: unsupported/unspecified
kernel: [   12.158802] sfp sfp:   Options: txdisable, txfault, los+
kernel: [   12.164150] sfp sfp:   Diagnostics: ddm, intcal, rxpwravg
kernel: [   12.169584] mvneta f1034000.ethernet eth2: switched to 802.3z/1000base-x link mode

Seems to be working fine so far.

2 Likes

@siska I just tried to get it working without any luck. the same error occurs also with the TOS v5.1.5. To rule out that it is the SFP module, could you tell me if you have the same SFP module?
thanks for the link to TP media converter - i will keep in mind; but will try other SFP modules first before adding another power supply :wink:

@carwyn thanks, i just ordered the module that you linked. will try again as soon as i have it.

ps: it seems that TOS v5.1.5 still runs still with kernel v4.14. so the linked improvements linked by @viktor with kernel v5.4 and up are still missing.

@bugrasan my SFP module is the one from Swisscom, LCS SFP-31W2ASM-10-DR. I wanted to avoid more power supplies but also needed my internet to work again :slight_smile:

@carwyn what TOS version have you managed to get it working with? Is it also working if you include VLAN configuration?

Thank you both

TOS 5.1.4 but I don’t have any vlans on there yet.

I have hit a bit of a snag but I don’t think it’s anything to do with the SFPs, my initial throughput testing was showing 97-101MB/s (using netcat on a PC and Omnia to the bridge interface) but now a few days later it’s more like 14-15MB/s.

Almost certainly something CPU bound as it crosses to the bridge as it’s also doing this to the bridge interface from the copper LAN switch ports. I’m not sure what I’ve done :slight_smile:

SFPs themselves are not showing any errors though and behaving well.

Sigh, false alarm, my own fault. I was using this method to measure the throughput:

On the Omnia:

nc -l -p 2222

On my PC:

dd if=/dev/zero bs=1024K count=512 | nc -v 192.168.1.1 2222

The issue was uncovered when I changed the source to /dev/random … which then spewed out garbage on the Omnia. The bottleneck was the rendering of received zero chars on the SSH session (doh!). When I reverted to this on the Omnia:

nc -l -p 2222 > /dev/null

We’re back to the ~90MB/s I was getting before:

$ dd if=/dev/zero bs=1024K count=512 | nc -v 192.168.1.3 2222
Ncat: Version 7.80 ( https://nmap.org/ncat )
Ncat: Connected to 192.168.1.3:2222.
512+0 records in
512+0 records out
536870912 bytes (537 MB, 512 MiB) copied, 5.7366 s, 93.6 MB/s
Ncat: 536870912 bytes sent, 0 bytes received in 5.75 seconds.

For those interested I still get around 90MB/s end to end through this config of Omnias:

PC <- Cat5e -> Omnia1 <- SM Fibre -> Omnia2 <- Cat5e -> Omnia3

With Omnia1 to Omnia2 having to pass through the CPU bound bridge.

short update on my progress:

the ordered Generic Compatible 1000BASE-LX/LH SFP 1310nm 10km DOM Transceiver Module came yesterday, unfortunately they are LC-Duplex, and my wall plug is LC-Simplex therefore i need Bi-Directional module - it seems i wasn’t paying attention while ordering :man_facepalming: so another dead end there.

in another thread regarding init7 compatibility, i found this link: flexoptic - 1G SFP BiDi LX that can be delivered with Turris compatibility. I asked support for TOS v5.x compatibility and waiting for feedback.

@yorik could you please inform/confirm that your TP-LINK TL-SM321B still works with TOS v5.1.x ?

@bugrasan it works, I think, since v3.*. Do not forget to enable SFP: https://docs.turris.cz/geek/tos3-migration/#turris-omnia-specifics

Current info:
TurrisOS 5.1.4

[   13.852045] libphy: SFP I2C Bus: probed
[   14.191151] sfp sfp: module TP-LINK          TL-SM321B        rev 1.1  sn 35506106580385   dc 17-06-15
[   14.200547] sfp sfp:   LC connector, encoding 8b10b, nominal bitrate 1.3Gbps +0% -0%
[   14.208333] sfp sfp:   1000BaseSX- 1000BaseLX+ 1000BaseCX- 1000BaseT- 100BaseTLX- 1000BaseFX- BaseBX10- BasePX-
[   14.218465] sfp sfp:   10GBaseSR- 10GBaseLR- 10GBaseLRM- 10GBaseER-
[   14.224761] sfp sfp:   Wavelength 1310nm, fiber lengths:
[   14.230091] sfp sfp:     9µm SM    : 20000m
[   14.234384] sfp sfp:  62.5µm MM OM1: unsupported/unspecified
[   14.240152] sfp sfp:    50µm MM OM2: unsupported/unspecified
[   14.245928] sfp sfp:    50µm MM OM3: unsupported/unspecified
[   14.251704] sfp sfp:    50µm MM OM4: unsupported/unspecified
[   14.257473] sfp sfp:   Options: txdisable, txfault, los+
[   14.262813] sfp sfp:   Diagnostics: 
1 Like

@yorik thank you! I just received mine (TP-LINK TL-SM321B) today, and works flawless :smiley:

I also updated the Supported SFP modules accordingly.

1 Like

I am also interested in finding a way to make my fiber work with a compatible SFP. Are you on fiber or xDSL? Did you have to configure the SFP module? Unfortunately the form provided by my ISP is not compatible with Omnia.