While I saw the list of recommended SFP devices, I’d also love to know whether the list can in some way be extended, as I have some modules I’d be happy to try from time to time.
So far, I’ve tried two 10G Ethernet SFP+ modules I had available, neither shows an error in the log, neither connects to other devices I have by Ethernet:
First, the Ampcom AM3A-SFP-10G-T module actually works great and the issue was discussed in detail here. TL;DR: I did not pay attention that a bridge device had not included the ports for the SFP slots. Updating a device by simply adding the necessary ports fixes the issue.
Second, I had no luck with TP-Link TL-SM510U SFP module. It is recognized, but doesn’t work either with Ten64 or a switch. Not sure if it’s broken or it’s some type of SFP I do not understand, but suffice to say I’ll stick with Ampcom / FS.com modules for now.
Nobody claimed TP-Link when I asked whether anyone would like to test it, so it’s teardown-worthy at this point. (I’m not as eager with stable Ampcoms, though. :D)
I’ll check both modules with some commands and when I have a good lens, I’ll make photos of the module’s chipset.
It might be possible to talk to the PHY inside and identify it. Some copper modules bridge the PHY MII to I2C.
Could you run i2cdetect 4 (lower slot) or i2cdetect 3 (upper slot) ?
What I am looking for is for the presence of other I2C addresses besides 0x50 (and 0x70, that’s the I2C mux):
$ i2cdetect 3
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-3.
I will probe address range 0x08-0x77.
Continue? [Y/n] y
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: 50 51 52 53 -- -- -- -- 58 59 5a 5b -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: UU -- -- -- -- -- -- --
It doesn’t work either with a Horaco switch I’m using as a reference nor Ten 64. I’ve tried several different cables, too.
Regarding this part, I won’t be buying TP-Link modules anytime soon and don’t think Ten 64 is at fault. So, it gives some info:
root@OpenWrt:~# i2cdetect 3
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-3.
I will probe address range 0x08-0x77.
Continue? [Y/n] Y
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: 50 -- -- -- 54 -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: UU -- -- -- -- -- -- --
All the modules have an extra I2C endpoint of some kind (0x54 on the TP-Link, or 0x56 on the Ampcom’s), so that looks like we can talk to the built in PHY.
I’ll check with the 10GBase-T SFPs I have and get back to you on how we can grab useful info (like the PHY ID).
I have the same module and there should be no issues.
Have a look at the troubleshooting steps in the other SFP thread and also if there are any indications from dmesg (does the module name show in dmesg? Any PHY mode validation errors)
So I appear to have nerd sniped myself! Pulling the PHY IDs out of 10GBase-T SFPs is not as easy as I thought.
If your SFP has a 0x56 endpoint, you can try this and it may return something useful. These come from a 10GTek ASF-10G-T80:
# Replace '4' with '3' for the upper SFP slot
i2ctransfer -y 4 w1@0x56 0x02 r2@0x56 w1@0x56 0x03 r2@0x56
0x35 0x90
0x50 0x81
(You may need to bring up the corresponding interface for 0x56 to appear)
0x3590 is a vendor ID used by Broadcom. 0x5081 is the identifier for the BCM84891L PHY (see this for a confirmation).
If your SFP is coded as 10GBase-T (under Transceiver Type in ethtool -m), then Linux will try and communicate with the PHY via 0x56, but many SFPs don’t implement the C45 protocol that Linux expects.
Instead there is a ‘Rollball’ protocol (named after a SFP OEM) which does the accesses via a passworded-interface on 0x51. The original patchseries explains that 0x56 on these SFPs presents as the older Clause 22 protocol.
One of the OpenWrt developers took apart a related model (TL-SM410U, 2.5G only), it has the same 0x54 endpoint and uses a Realtek PHY.
It doesn’t look like anyone has figured out the 0x54 “protocol” yet.
