According to the community wiki, this SFP module should work Supported SFP modules [Turris wiki], but I just can’t get it working. I’ve tried changing the dtb symlink as described in forum post, but it didn’t change anything.
I see the following in dmesg:
mvneta f1034000.ethernet eth2: Using device tree mac address xx:xx:xx:xx:xx:xx
sfp sfp: Host maximum power 3.0W
sfp sfp: module FS SFP-2.5G-T rev 1.0 sn G2430099995 dc 240716
mvneta f1034000.ethernet eth2: configuring for in and/sgmii link mode
mvneta f1034000.ethernet eth2: validation with support 0000000,00000000,00000000 failed: -22
sfp sfp: sfp_add_phy failed: -22
I can’t find anything that describes what that -22 error means.
Yea im still using mine on my Turris Omnia with no issues. The original unit I had didnt work and i had to send it back to them but the second one worked fine.
IIRC it also takes some time to activate since the cable modem/ISP doesnt really like you switching the primary MAC address attached to modem often (in some cases it may even require reaching out to ISP). I think I had to leave mine connected like 10-15m before it started working, I only realized after trying to switch back to the regular WAN ethernet port instead of the SFP also took a while to come back online on revert.
@ju2wheels how could you tell the unit you received didn’t work rather than it being a configuration issue? Do you remember ever seeing the -22 error I’m seeing? I don’t think my device is loading correctly since ethtool is saying it only supports up to 1000Mbps, maybe I have a dud one like you did.
I’ll try leaving it plugged in longer to see if that changes anything. I did try rebooting the modem, but maybe the MAC check is on the ISP side.
If you could provide your dmesg | grep -i -e eth2 -e sfp and ethtool eth2 outputs so I can see what they should look like with a working device I’d appreciate it.
I do not recalll seeing the -22 error. You can try contacting FS and asking them about it, they were very responsive when I had an issue with my first unit (it was something about being old stock still on the shelves with older firmware).
Are you using a classic Turris Omnia or one of the newer Omnia boards?
First it should say link is established and then ISP figuring out part. So you are correct it is not detected for some reason. But I do not have experience with FS modules. They suppose to be super customized/compatible.
Yeah I’m in contact with them already, but because ethtool says it only goes up to 1000Mbps they’re saying my device doesn’t support it
I bought it in 2021, I’m not sure what the timelines are for it to be considered “classic”. It’s not one of the original blue ones, and it’s not one of the new WiFi 6 ones. Though I believe the main board in the WiFi 6 one is the same, it just has a new WiFi card and an extra antenna?
I’ll reach back out to the FS rep since I have better evidence that other people have it working and see what they say.
It’s at least somewhat of an explanation
I wonder if there’s any kernel modules I’m supposed to have installed? I’m on Turris OS 7.1.3, so it shouldn’t be an out-of-date software issue.
You may give a try to TOS9 in hbd make a snapshot and try. There is much newer kernel. Also sfp module is build into kernel on Turris devices not as separate module.
Settings for eth2:
Supported ports: [ MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Supported pause frame use: Symmetric
Supports auto-negotiation: Yes
Supported FEC modes: Not reported
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Advertised pause frame use: Symmetric
Advertised auto-negotiation: Yes
Advertised FEC modes: Not reported
Speed: 10Mb/s
Duplex: Half
Port: MII
PHYAD: 0
Transceiver: internal
Auto-negotiation: on
Supports Wake-on: d
Wake-on: d
Link detected: no
And yes, this is when the SFP module is plugged in and the dtb symlink is pointing at *-sfp.dtb, to me it looks suspiciously like the stats for the RJ45 port (the speeds don’t go up to 2.5Gbps for example).
Edit: For my own sanity this is the output when using the RJ45 port
Settings for eth2:
Supported ports: [ TP MII FIBRE ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Supported pause frame use: Symmetric
Supports auto-negotiation: Yes
Supported FEC modes: Not reported
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Advertised pause frame use: Symmetric
Advertised auto-negotiation: Yes
Advertised FEC modes: Not reported
Link partner advertised link modes: 100baseT/Half 100baseT/Full
1000baseT/Half 1000baseT/Full
Link partner advertised pause frame use: Symmetric Receive-only
Link partner advertised auto-negotiation: Yes
Link partner advertised FEC modes: Not reported
Speed: 1000Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 1
Transceiver: external
Auto-negotiation: on
MDI-X: Unknown
Supports Wake-on: pg
Wake-on: d
Link detected: yes
The speed is another topic I am more likely able to solve by my beloved kernel patch (based on fix for Turris branded SFP should work). Main problem is there is no link up. Maybe for some reason autoneg is failing here?
Try to put SFP in then correct link in /boot and then try:
ethtool -s eth2 speed 100 duplex full autoneg off
Or 10 or 1000 for the speed and then again ethtool eth2 and to check if the link detected is yes. The 2,5Gbps we will deal later.
Also I dont know if it will work for the Copper SFP but you could get more info probabbly using ethtool -m eth2
The rep I’m speaking to at FS says the module has been updated since @ju2wheels bought theirs, so it seems likely it’s now incompatible.
@AreYouLoco I tried the ethtool -s eth2 command with 10, 100, and 1000, the command succeeds with no output (exit code 0) but the only thing that changes in the output of ethtool eth2 is Auto-negotiation: off, the speed stays at 10Mb/s, the duplex stays at Half, and Link detected remains as no.
ethtool -m eth2 just gave a bunch of hex, so I installed ethtool-full to get the more useful info:
I will build a kernel for you to try. There is some fix for Turris SFP that maybe useful here since its similar module Copper 2,5G-T. Hang on. Will post it here in some time. If it doesnt work then you would have to try different module or solve it with FS support.
Edit:
Actually I would like to look at the hex eeprom dump first @TastyPi
I need to convert HEX to ASCI to see one thing. But you can see module is present and detected obviously, mosdef0 is 1 so good. But PHY probe fails. 0 of 0 attempts. Tx_los 0 so good tx_falult 0 good. Tx_disable 0 also good. So module is not disabled by kernel.
There are some fixes. But indeed I was lurking into good direction. So fix for Turris SFP module should work. Its just that your SFP needs to identify as OEM(SFP-2.5G-T) and yours is FS(SFP-2.5G-T) so the fixes won’t apply here. And there is a comment from R.M.K. that for FS modules the rollball fix (turris module) is not enough. Because you have to wait some spcified time for the PHY to come up. And this will be consistent with your issue here.
I might build a kernel soon with the fix for your module.
Appreciate you looking into it @AreYouLoco, unfortunately I don’t have the time or expertise to do it myself. There’s only a couple of weeks until the end of the returns window for this module, do you think you would be able to provide a kernel for me to test before then?
I also don’t want to be stuck with having to replace my kernel every time there’s an update to it, so I may return it anyway unless any patches that fix it can be properly merged quickly, I don’t know what the kernel development speed is like.
Thanks for reminder. I will build a kernel in less than 45mins. If it works then changes might be applied to Turris repo. So its included in newer releases. Hang on.
