Since there’s no response in another thread, I’ll repost the question here: is there a list of SPF modules that is known to work (in both 3.x and 4.0)? [I’m considering connecting my Omnia to a managed switch sitting before it with a direct-connect SFP cable]
Given the lack of any response, I guess the answer is ‘none’.
You have to try. If it works then it means that it is compatible. If it doesn’t work then it’s not compatible. However, the fault is yours in either case.
Yeah - not sure I want to throw money at something before I know it’ll work.
It would take an investment too big to make a list of compatible connectors. Many different SFP and switch modules and lines should be available. In fact it is a lottery. Either renounce or risk.
I’d recommend SFP modules and optic cables rather than Twinax DAC cables. Yes, it’s more expensive - but based on my experience is less trouble, unless you connect devices of a single vendor.
OEM SFPs like the ones from FlexOptix (https://bit.ly/2YzGyOr) are a good choice. You can get them preconfigured for compatibility to virtually any vendor or If you have the required hardware you can program them on your own, which makes them also reusable if you swap devices.
We use them a lot at work as they are sold at a fraction of the price compared to original vedor equipment (Cisco, Juniper, …).
Thanks for the link.
What’s about TP-LINK TL-SM321B 1000Base-BX WDM Bi-Directional ?
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
With the switch from TOS3.x to TOS4+.x the kernel leverages routines from SFP.C  and on that subject I had a recent communication exchange with the developer (R. King) currently looking after SFP.C development at Linux source.
Thought to share the gist of it - still a bit to digest for the interested, perhaps with a grain of salt:
- SFP MSA conformity:
- wording, such as may or shall, in the various MSA documents is rather suggestive than obligatory and leaves quite some wiggle room
- self proclaimed by the vendor may not be necessarily a reliable statement (seems there is no certification standard yet for establishing such conformity)
- examples for conformity misses:
- takes 40-50 seconds after deasserting TX_DISABLE to initialise and deassert TX_FAULT, when the SFP MSA explicitly states a limit of 300ms (t_init) for TX_FAULT to deassert.
- EEPROM does not respond for 50 seconds after plugging in, where the SFP MSA explicitly states 300ms (t_serial) maximum.
- EEPROM contains incorrect data, such as but not limited to:
- indicating the module has a LC connector, yet it has an RJ45, or vice versa.
- indicating NRZ encoding for an ethernet SFP, where it should be 8b10b or 64b66b encoding.
- indicating a single data rate, or even the wrong data rate, when the module is documented as supporting other rates.
- indicating an extended compliance technology that it doesn’t support, presumably originally chosen when the number was unallocated by SFF-8024.
- claiming to support 1000BASE-SX, a fiber standard, when the module is actually for VDSL2 over copper.
- module manufacturers may provide own tailored drivers that are not being up-streamed to kernel source development and/or are not always being made available to the end user either
- for that purpose commercial / industrial grade network appliances often implement vendor lockin
- userland to query the SFP module
- mii-tool is not suitable for modules that do not have a PHY; the “PHY” registers are emulated, and are there just for compatibility
- ethtool is better suited
cat /sys/kernel/debug/gpiofor modules with GPIO, debugfs enabled and being mounted, or alternatively
- if the I2C GPIO expander is interrupt capable watching
cat /proc/interrupts | grep sfpcould help in debugging efforts
- state machine checks implemented by the SFP.C code
- is written to the SFP MSA and not the GBIC standard
- does not query/leverage the module’s EEPROM
- provides a check for inverted LOS for big endian arch but not for little endian
- with the aforementioned conformity issues this could lead easily to a mishap in the signal state communication with a non-conform module
- checks signal status (asserted / dessarted) for RX_LOS and TX_FAULT and acts according to the signal status received from the module
- current development of SFP.C code
- state machine code and other code has been reworked recently in commits to the Linux branches net-next | 5.5-rc5
- in general it is not clear whether/when code from the Linux mainline will be uplifted to LTS branches and arrive at downstream distros a/o uplifted directly (cherry picked) into OpenWrt | TOS stable branches
- code changes may not necessarily (and magically) remedy potential compatibility issue
In essence it is foremost the responsibility of the module manufacturer to achieve SFP MSA conformity, as opposed to GBIC MSA conformity, and if particularly quirks are implemented such to be publicly documented.
Else there is little that can be done at the Linux source development and even less so by the developers in the downstream distors such such as OpenWrt | TOS.
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!