Anonym, who deleted his account is right. SFP modules that are using chipsets from Realtek RTL8672 or RTL9601 has broken the EEPROM emulator, which returns zeroes instead of EEPROM content. There is no way to get fix the emulator, however, we have two SFP modules based on these chipsets in our offices.
Our kernel developers are right now looking if there is a possibility to have these modules working in Turris OS and in the upstream kernel. I donāt want to promise anything. Because there is a going be a big chance that the patch will break others SFP as well. We will see about a response in kernel soon!
i have datasheet pdf for the carlitoxx v2 based on chip rtl if help something but doesnt matter to me because i prefer to test other SFP module like the g-010s-p or ma5671a,
about the kernel you have any image to test it if works on the turris with MA5671a and g-010s-p modules? because i can test it
Thanks to Pali RohƔr and Russel King, workaround for SFP modules based on Realtek RTL8672 and RTL9601C was accepted to branch net-linux! It means that we can see it in the upstream kernel soon.
@backon@Pepe two questions for you both, as Iām a little new at this but I think i get the idea of whats going on.
Once the workaround for SFP modules is part of the upstream kernel, does that mean SFP modules like the G-010S-A will work? Or did i misunderstand?
Should i just get a DFP-34G-2C2 somehow and get it registered with my ISP? Iāve been wanting to use the SFP port on my Turris Omnia for years and Iām hoping to finally do that now that iāve got FTTH
Until i have no luck with the DFP-34G-2C2 module because i cant configure it for my isp configuration. The G-010S-A looks like a g010sp but im not able to test it on HBD branch because im having issues and its unstable. Im going to try it on my other turris MOX with SFP
The omnia until gets the last kernel for SFP Quirks supponts its going to be via cableā¦
Regarding GPON SFP module Nokia Alcatel G-010S-A, which is also referred as ALCATELLUCENT 3FE46541AA, there are multiple fixes in vanilla kernel. Iām referring to these two:
They are present in LTS version 5.10+, but upcoming OpenWrt 21.02 uses LTS kernel 5.4, and in daily OpenWrt snapshots, you can use testing LTS kernel 5.10, which we already have in one of our development branches:
the kernel that support SFP module quirks was 5.4 so was say you before .
ok im going to test it the turris HBD branch build in the turris mox for check if its working . im going to report what module works (because i have a bunch of sfp module for test) if the hbd version works from medkitā¦
if you need any help with test the SFP modules or something you can send me a pm or how i can help you to test all modules?
I built a kernel with the changes from the patch mentioned above:
Works fine for me with CPG0S03-0490 V2.0.
There might be some additional issues with UF-INSTANT, because it has some strange data in the EEPROM.
If it doesnāt work, overwriting the EEPROM with some reasonable values using i2cset could help
You can then reboot the router, but because the SFP port doesnāt lose power, the SFP stick will keep working and the EEPROM changes will stay.
I am sorry, but there is nothing that we can do about it. I will say it loud and clear.
Take a look at these two posts in this thread:
Even though there are already kernel patches present for it, they were not backported to the stable LTS kernel, which we are using. I told you that most of them are present in newer versions like LTS kernel 5.4 (OpenWrt 21.02), LTS kernel 5.10 (OpenWrt master). The same applies to your EEPROM. More details about it are in the kernel mailing list.
In other words, you should buy a rather different SFP module until it lands to the stable branches, or feel free to send pull requests.
i have several SFP sticks to test only i reporting the feedback. the only until now that works on turris its a afm0002 tim but with issues because when you reboot the router doesnt take the dhcp. other issues with this modules is that need sometimes doesnt take dhcp when i plug . so i need to plug several times or unplug power from turris for take DHCP fron SFP module (the module works well with a media converter and in turris when i plug in SFP mode doesnt work but when i switch to ETH mode with the module in a media converter with same config works well without issues.)
so any unnoficial patch like xDSx kernel patch its welcome to test it until releases it as stable because can help to community improve . so about the thing that is nothing about you can do it for me goes wrong with the open source philosophy.
so im a little dissanpointed with turris team about developing software or improve support (the last builds from turris os its like backporting from openwrt and add a new gui with a some packages) but its only my opinion from my point of view.
Hello @xDSx and thanks for your info. Iām trying to understand how to modify/simulate the EEPROM so the kernel could read the UF-instant. Could you please tell me how exactly I could do that?
I donāt think that this is possible. Since the SFP module, UF-Instant does not have real EEPROM. There is only a semi-working emulator that does not work well and requires many hacks into the kernel.
Unfortunately, i2c dump or any other tools like i2c set will not work until hacks land into the kernel. But I have good news for you. This SFP module is supported since Turris OS 6.0 has these hacks already, and also they will be included in OpenWrt 21.02.3 (not yet released).
