Great find! That will help limiting the number of quirks/fixups needed for all the diffferent OEM Vendor PN strings of the RollBall modules The password is the same on the other ‘known.to be rollball’ modules.
It may be exactly the same mcu, but only a few different settings (on page 3?)
The driver of the YT8821 however uses only C22 commands. So my guess here is that the sfp-module-mcu does the same. This is probably why rollball does not work (as expected), as it is C45 only.
The mcu itself, probably is a general md32 or similar mcu, but we barely know what it’s programmed to do.
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 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
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.
@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.
