Turris Omnia: Experimental support for SFP cage

Good to hear.

Concerning the Cisco module, it seems to be advertised as Fibre Channel SFP module (and not Ethernet). There seems to be a lot of guesswork involved during parsing of the SFP firmware (phylink.c et al). Maybe Mikrotik and Linux do it in different ways, ending up in incompatible configurations.

Maybe that is why TurrisOS has this https://github.com/CZ-NIC/turris-misc/blob/master/sfpswitch/sfpswitch.py ? The module can work as 1Gb Ethernet.

In my understanding of recent Linux kernels (>=4.14), parsing of SFP module EEPROM is done by phylink_sfp_module_insert() in phylink.c and the supporting sfp_parse_*() functions in sfp-bus.c. The code covers Fibre Channel modules.

To find out what is going wrong, you may want to correlate that code with your kernel messages and/or the output of ethtool -m eth2. The structure of the EEPROM is declared in include/linux/sfp.h.

there was any news ? i have some cisco and juniper sx sfp , and i will give it a try!!
in the future this support will become part of the standard tree??

No news, I am just regularly re-basing the branch against master, and it is working fine for me.
Upon request, I had submitted the LED support to openwrt-devel, but it was rejected. I guess the same would happen to the SFP support.
A clean solution with support for hot plugging would be a modification of the phylink subsystem (see this linux-netdev thread). At the moment, I don't have time for this.

2 Likes

Did you try submitting the SFP support?

No, so far not.