I am working on a tool to use on sfp modules via i2c. You can tryout all different protocols directly from commandline. I will add extracting the password and setting the vendor info to this tool. This will make it easier to change only that and minimize the chances of making an error.
It is compiled statically, so you can run it from anywhere.
I expect to have it online within a week or so.
I have written similar tools but not quite ready for upload. I try out C22, C45, C45overC22, ROLLBALL from a userland app, as its easier to discover stuff that way, rather than rebuilding linux kernels. I have not looked into how to do i2c bus lock from userland yet. Is there a IOCTL for that, that automatically unlocks on device close? I also have written a SFP password scanning tool and was doing that in the hope it might help with 0x56 write access. Fortunately, I found the “csww” password just looking at me from the bottom of 0x51 page 3, so that saved me a few days scanning.
Me too, brute force attack is in the tool. But I was running 0x0 to 0xff, where I should have limited to readable characters, then I would have found it already.
The tool is practically finished, but I just try it out first thoroughly, before setting the repo public.
The functions so far are:
Usage: i2csfp I2CBUS command ...
I2CBUS is i2c bus device name (/dev/i2c-x)
Command one of:
eeprom
byte
c22m Clause 22 MARVELL
c22r Clause 22 ROLLBALL at 0x56 (read-only?)
c45 Clause 45
rollball Rollball protocol (Clause 45)
rollball22 Rollball protocol (Clause 22) NOT FUNCTIONAL!!!
rbpassword Extract Rollball eeprom password
bruteforce
i2csfp I2CBUS eeprom [-p PASSWORD] [-e EXTCC] [-v VDNAME] [-n VDPN]
-p PASSWORD specify password, without this option uses rbpassword
-V VDNAME specify vendor name
-N VDPN specify vendor pn
-E EXTCC specify extended cc
i2csfp I2CBUS byte read|write [-v] BUS-ADDRESS REGISTER [VALUE]
-v verify write
BUS-ADDRESS is an integer 0x00 - 0x7f
REGISTER is an integer 0x00 - 0x7f
VALUE is an integer 0x00 - 0xff
i2csfp I2CBUS c22m read|write BUS-ADDRESS REGISTER [VALUE]
BUS-ADDRESS is an integer 0x00 - 0x7f
REGISTER is an integer 0x00 - 0x1f
VALUE is an integer 0x00 - 0xffff
i2csfp I2CBUS c22r read|write BUS-ADDRESS REGISTER [VALUE]
BUS-ADDRESS is an integer 0x00 - 0x7f
REGISTER is an integer 0x00 - 0x1f
VALUE is an integer 0x00 - 0xffff
i2csfp I2CBUS c45 read|write BUS-ADDRESS DEVAD REGISTER [VALUE]
BUS-ADDRESS is an integer 0x00 - 0x7f
DEVAD is an integer 0x00 - 0x1f
REGISTER is an integer 0x00 - 0xffff
VALUE is an integer 0x00 - 0xffff
i2csfp I2CBUS rollball read|write DEVAD REGISTER [VALUE]
DEVAD is an integer 0x00 - 0x1f
REGISTER is an integer 0x00 - 0xffff
VALUE is an integer 0x00 - 0xffff
i2csfp I2CBUS rbpassword
i2csfp I2CBUS bruteforce [-p] [MIN] [MAX]
Runs brute force attack on sfp module
-p specify password to start with (last 2 bytes zeroed)
-E specify which attack: 1 (09x50) or 2 (0x56), default 1
MIN is the first byte to try 0x00 - 0xff, default 0x00
MAX is the last byte to try 0x00 - 0xff, default 0xff
There seems no way to lock it from userland.
I use a devicetree overlay, to disable the sfp-cage. I set the compatible string of &sfp1 and/or &sfp2 to skip
For the “i2csfp eeprom” command, does it redo the checksum and also the Vendor specific checksum, like Cisco use?
I calculate and fix 2 chacksums: at device 0x50 registers 0x3f and 0x5f.
Hi,
I have tried contacting the seller on aliexpress. They don’t even read messages sent to them. So they are probably totally unaware of the problem we are having with all the SFP units they sell. I was thinking that if they at least knew of the problem, they could maybe fix it in future units. I guess not.
Kind Regards
James
I guess, because, as long as the phy is not being attached by the kernel, there is no problem…
Because all vendors can change these values, this will become a more common problem with these OEM modules I think.
@ericwoud Maybe in the detection code in the kernel, have it detect Read Only 0x56, and treat all transceivers like that the same, ignoring the name fields. We could add module parameters to the sfp.ko module, so that a user could statically configure the quirk/fixup to use for each slot, bypassing any sfp auto-detect logic.
E,g, modprobe sfp type=0,1
0 meaning first sfp slot, use auto-detect
1 meaning second sfp slot, use quirk 1 etc.
Then users could select quirks without even needing to recompile the kernel.
We use that approach for the Linux Sound ALSA because new variants are arriving all the time, and it allows us to get the user sound working, until the permanent quirk is added for that specific motherboard.
Why do you need to lock the i2c bus? Just unbind the SFP device in /sys/bus/platform/drivers/sfp/. For example if your device is called sfp-1, you do
echo sfp-1 >/sys/bus/platform/drivers/sfp/unbind
You can list bound devices by listing the symlinks in that folder.
This is cool! Is this tool available for experiments?
The tool does just that now 
Any news about this?
I have no news on the yt8821 nor the sfp module.
I noticed that some modules seems to fail to work without rollball quirk on current openwrt snapshot, any idea about it? @ericwoud
For Rollball it is a fixup, not a quirk.
Do you have a YT8821 module or a rtl8221b? This is the topic for the YT8821.
Maybe this for the rtl8221b:
But I do not use openwrt myself.
My module is rtl8221, and they are also 8221… That’s the weird thing,
Edit: found the problem, wrong br.nominal value settings
Hi Dan,
We were not successful communicating with the phy on the sfp module at all. The author of the yt8821 driver has hardwired an yt8821 to the BPI-R3, he did not use a RollBall sfp module.
Perhaps Marek has made some progession, I do not know.