Turris Omnia NG SFP+ cage: which third-party RJ-45 copper modules actually link
I run a Turris Omnia NG at home and the last thing sitting on the metallic WAN port is a two metre hop to the ISP router. I would like to move that hop into the SFP+ cage and free the copper port for the lab side. The official Turris SFP+ copper module (RTROM01-RTSF-10G) costs about what a small switch costs and is awkward to get hold of at all.
Setup:
- Turris Omnia NG, stock firmware, SFP+ cage currently empty
- short RJ-45 run to the ISP router, 1G on that side
- two 10G hosts on the lab side I would eventually like to reach faster than 1G
- no spare copper SFP+ modules in the drawer to test with
Everything I have to judge a module by once it arrives:
dmesg | grep -i sfp
ethtool -m eth2What I have done so far: looked for an official compatibility list for the cage and found nothing, and asked one seller whether they take a module back if it does not come up.
So the question is simple - which 10G or 2.5G copper RJ-45 modules are people actually running in the NG cage, and which ones are known not to link? I would rather buy something that is in service somewhere than roll the dice three times.
Comments 4
There is no vendor compatibility list for that cage and there is not going to be one - the number of module and firmware combinations makes it impractical to maintain, so what you get instead is owner reports. From what people run in the NG: a 10Gtek RJ-45 SFP+ of the 1.25/2.5/5/10GBASE-T kind is the one that comes up most often, an ipolex 10GBASE-T module works, a MikroTik S+RJ10 works, and a cheap Xicom 2.5G copper SFP has been reported fine too. If the hop is short enough, 10Gtek DAC cables are also in the working column. On the other side of the ledger, a Solarflare SFM10G-TX was reported not to work.
Two practical points. Buy from a seller that accepts returns - host support here is narrow, so you may end up swapping brands rather than debugging anything. And expect a 10GBASE-T module in an SFP+ shell to run hot, which matters if the router sits in a closed cupboard.
When it arrives, check
dmesg | grep -i sfpimmediately after insertion and readethtool -m eth2. If the kernel does not identify the module there, no amount of interface configuration is going to rescue it.Worth adding for anyone who lands here with a classic Omnia rather than the NG. On that box the cage buys you no extra interface at all. The cage and the metallic WAN socket both sit behind one MAC, eth2, and only one of them is wired to it at any given moment - which one depends on the device tree blob the router loads at boot. So a perfectly healthy copper module looks stone dead: nothing new turns up in the interface list, and the metallic WAN even drops its address for as long as the module stays in. Point /boot/dtb at the SFP variant, reboot, and the picture changes:
Did exactly that on TurrisOS 6.2.3 with an FS 2.5GBASE-T copper module and the WAN came up at 2.5Gbps right after the reboot. I have no idea whether the NG needs anything comparable, but check the host before you write off a module as faulty.
Thanks, that is the list I was after. Ordering the 10Gtek, and from somewhere that takes it bck.
One thing I should have put in the question, since the official module comes up in every one of these threads: I did have the RTROM01-RTSF-10G in that cage earlier. It worked for a while, then after about a month it started throwing connection errors, and I gave up and moved the link back to a regular ethernet port. So the expensive option is not automatically the safe one here - which is exactly why I asked for modules people have in service rather than for a recommendation.
Different corner of the same problem, same conclusion. On the classic Omnia the only module I can vouch for is a TP-Link TL-SM321B - 1000Base-BX bidirectional, 1310 nm, LC. The kernel picks it up without any coaxing and I get roughly 920 Mbit/s of real payload through it. Nobody needs to go hunting for the missing 80 Mbit/s eiher: the line itself runs at 1.25 Gbit/s, and between 8b10b encoding and Ethernet framing that is exactly where the usable rate lands.
Counterexample from the same router: a CTS SFP-31W2ASM10-DR ran fine under Turris OS 3.x and went dead once the box moved to 4.0 - and the culprit there was the reworked VLAN and switch configuration model, not the module. And remember where the fixes come from: SFP work geos into OpenWrt master long before any of it turns up in the stable Turris branch, so something that refuses to link today can quietly come alive a couple of releases later.