The simplest thing is to try. If you run the WAN to SFP switch command, see that the connection is not going, then it is incompatible. I hope you’re lucky. 70% of Omnia’s choice was for the SFP port. Now I have learned to appreciate the remaining 30%.
Finally checked: TP-LINK TL-SM321B is supported by Turris 4.0.3:
dmesg | grep sfp
[ 5.282570] sfp sfp: module TP-LINK TL-SM321B rev 1.1 sn 35506106580385 dc 17-06-15
[ 5.291907] sfp sfp: LC connector, encoding 8b10b, nominal bitrate 1.3Gbps +0% -0%
[ 5.299674] sfp sfp: 1000BaseSX- 1000BaseLX+ 1000BaseCX- 1000BaseT- 100BaseTLX- 1000BaseFX- BaseBX10- BasePX-
[ 5.309788] sfp sfp: 10GBaseSR- 10GBaseLR- 10GBaseLRM- 10GBaseER-
[ 5.316072] sfp sfp: Wavelength 1310nm, fiber lengths:
[ 5.321397] sfp sfp: 9µm SM : 20000m
[ 5.325675] sfp sfp: 62.5µm MM OM1: unsupported/unspecified
[ 5.331436] sfp sfp: 50µm MM OM2: unsupported/unspecified
[ 5.337195] sfp sfp: 50µm MM OM3: unsupported/unspecified
[ 5.342956] sfp sfp: 50µm MM OM4: unsupported/unspecified
[ 5.348716] sfp sfp: Options: txdisable, txfault, los+
[ 5.354042] sfp sfp: Diagnostics:
I think it would be better to have armada-385-turris-omnia-sfp.dtb by default.
Can you connect? Mine is also recognized. All fantastic, but then it doesn’t work.
I can. Also I think that speed is slightly better: it’s 920Mb/s now, before it was something like 880Mb/s.
Automatic detection and switching would be best - as already implemented in the more recent
uboot version that ships for the CZ11NIC23 hardware revision.
The one that is currently provided for earlier hardware revisions is rather outdated and supposedly been worked on but has not been introduced.
3 posts were split to a new topic: How to flash a new u-boot
n8v8r, thanks for sharing!
BTW, I have a question: https://www.tp-link.com/us/business-networking/accessory/tl-sm321b/#specifications says that data rate is 1.25Gbps.
dmesg says both 1.3Gbps and 1Gbps in different places
# dmesg | egrep sfp\|eth2 [ 4.465349] mvneta f1034000.ethernet eth2: Using hardware mac address d8:58:d7:00:50:a4 [ 5.302567] sfp sfp: module TP-LINK TL-SM321B rev 1.1 sn 35506106580385 dc 17-06-15 [ 5.311904] sfp sfp: LC connector, encoding 8b10b, nominal bitrate 1.3Gbps +0% -0% [ 5.319665] sfp sfp: 1000BaseSX- 1000BaseLX+ 1000BaseCX- 1000BaseT- 100BaseTLX- 1000BaseFX- BaseBX10- BasePX- [ 5.329779] sfp sfp: 10GBaseSR- 10GBaseLR- 10GBaseLRM- 10GBaseER- [ 5.336062] sfp sfp: Wavelength 1310nm, fiber lengths: [ 5.341388] sfp sfp: 9µm SM : 20000m [ 5.345666] sfp sfp: 62.5µm MM OM1: unsupported/unspecified [ 5.351426] sfp sfp: 50µm MM OM2: unsupported/unspecified [ 5.357184] sfp sfp: 50µm MM OM3: unsupported/unspecified [ 5.362944] sfp sfp: 50µm MM OM4: unsupported/unspecified [ 5.368704] sfp sfp: Options: txdisable, txfault, los+ [ 5.374029] sfp sfp: Diagnostics: [ 5.377616] mvneta f1034000.ethernet eth2: switched to 802.3z/1000base-x link mode [ 21.657946] mvneta f1034000.ethernet eth2: configuring for 802.3z/1000base-x link mode [ 21.972393] mvneta f1034000.ethernet eth2: Link is Up - 1Gbps/Full - flow control off
# 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: yes # mii-tool eth2 eth2: 1000 Mbit, full duplex, link ok
So is it 1.3Gbps or 1Gbps or 1000Mbps ? Also are there a way to get link quality measurements (if they available at all)?
Which is a bit off topic. @Pepe perhaps split from this thread?
There is a difference in between what the module can provide and what the eth port (eth2) that connects the SFP can. Plus
is likely the nominal bitrate which I trust is commonly perceived as the maximum achievable in whatever environment that figure has been conceived.
Notwithstanding the output is generated by different code sources and for different devices:
and may present nominal bitrate vs. actual bitrate.
1 Gbps = 1000 Mbps
The 1.3 is a rounded version of 1.25*, and 1250 Mbps comes from giving the gross rate on which a 8/10 encoding is performed:
1250 * 8/10 = 1000
and this then is the gross ethernet rate. Please note that all packets on etthernet carry (>=) 38 bytes of ethernet overhead, so with a typical MTU of 1500 bytes this link will give you an ethernet payload rate of:
1000 * 1500/1538 = 975.29 Mbps
any further protocol like IPv4 and TCP will add more overhead per packet resulting in even lower payload rates. What on-line speedtests typicall measure is a IPv4/TCP/HTML payload rate (or goodput) and for a pure ethernet link without any further encapsulations/options (like a VLAN tag or a PPPoE header, or TCP options, or IP options, or …) you will at best see:
1000 * (1500-20-20)/1538 = 949.28 Mbps
*) IMHO the ethernet standards did the right thing by specifying the nominal speed after the 8/10 encoding (or what ever encoding a specific ethernet type uses), the 1.25 Gbps really are only of interest for people trying to implement the standard and not at all for folks simply using ethernet for data transfers
Please note that in networking people have been using proper SI units for a long time (if not forever), so this is all base 10 and not base 2^10.
Sidenote: the [K|M|G|T|…]i prefixes like Ki or Mi denote base 2^10 numbers, so 1GiB = 1 * 1000^3/(2^10)^3) = 0.931 GB
Thank you guys for the explanation!
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.
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  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?
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
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
[ 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.
/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 
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.
Kernel 5.4 is coming.
I have a few SFP modules I tried, and the one which works and connects is this:
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
- 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.
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.