My ISP also confirmed work MA5671A with MikroTik.
Any changes on HBS o HBT branch for improve SFP support? i tested the modified MA5671a on a Mikrotik router and works well
I have tested on turris 5.1.3 G-010S-P module too but doesnt works @Pepe what is the stable version that includes 5.4 kernel to test it ? only can be tested it on the HBD branch?
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!
For reference, here goes patch series which was sent to kernel.
It was decided there, these SFP modules are not going to be supported.
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
here is the PDF with eeprom table if helps that i found in internet
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.
- 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
Thank you in advance!
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…
any news? support maybe in the next release with openwrt 21.02?
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:
But there is a really long way until it reaches a stable version.
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?
On last update (5.2.2) i see some improvements now its linking a 1000base x or 2500base-x but doesnt works because says module transmit fault
Here the logs
MA5671a (Unlocked Modified with HL23446 Firmware)
324.102654] sfp sfp: module HUAWEI MA5671A rev 0001 sn ELTX11223344 dc 14-09-20 [ 324.111995] sfp sfp: SC connector, encoding NRZ, nominal bitrate 2.5Gbps +0% -0% [ 324.119598] sfp sfp: 1000BaseSX- 1000BaseLX- 1000BaseCX- 1000BaseT- 100BaseTLX- 1000BaseFX- BaseBX10- BasePX- [ 324.129736] sfp sfp: 10GBaseSR- 10GBaseLR- 10GBaseLRM- 10GBaseER- [ 324.136053] sfp sfp: Wavelength 1310nm, fiber lengths: [ 324.141419] sfp sfp: 9µm SM : 40km [ 324.145525] sfp sfp: 62.5µm MM OM1: unsupported/unspecified [ 324.151283] sfp sfp: 50µm MM OM2: unsupported/unspecified [ 324.157152] sfp sfp: 50µm MM OM3: unsupported/unspecified [ 324.162936] sfp sfp: 50µm MM OM4: unsupported/unspecified [ 324.168727] sfp sfp: Options: txdisable, txfault, los+ [ 324.174064] sfp sfp: Diagnostics: ddm, intcal, rxpwravg [ 324.179511] mvneta f1034000.ethernet eth2: switched to inband/2500base-x link mode [ 324.501361] sfp sfp: module transmit fault indicated [ 329.901366] sfp sfp: module persistently indicates fault, disabling
sfp sfp: module ALCATELLUCENT G010SP rev 10 sn ALCL12345678 dc 21-02-17
[ 11.899957] sfp sfp: SC connector, encoding NRZ, nominal bitrate 2.5Gbps +0% -0%
[ 11.907558] sfp sfp: 1000BaseSX- 1000BaseLX+ 1000BaseCX- 1000BaseT- 100BaseTLX- 1000BaseFX- BaseBX10- BasePX-
[ 11.917673] sfp sfp: 10GBaseSR- 10GBaseLR- 10GBaseLRM- 10GBaseER-
[ 11.923957] sfp sfp: Wavelength 33685nm, fiber lengths:
[ 11.929367] sfp sfp: 9µm SM : 20000m
[ 11.933647] sfp sfp: 62.5µm MM OM1: unsupported/unspecified
[ 11.939405] sfp sfp: 50µm MM OM2: unsupported/unspecified
[ 11.945166] sfp sfp: 50µm MM OM3: unsupported/unspecified
[ 11.950923] sfp sfp: 50µm MM OM4: unsupported/unspecified
[ 11.956686] sfp sfp: Options: txdisable, txfault, los+
[ 11.962012] sfp sfp: Diagnostics: ddm, intcal, rxpwravg
[ 11.967429] mvneta f1034000.ethernet eth2: switched to inband/1000base-x link mode
127.093567] mvneta f1034000.ethernet eth2: configuring for inband/1000base-x link mode
[ 127.102512] IPv6: ADDRCONF(NETDEV_UP): eth2: link is not ready
[ 127.421381] sfp sfp: module transmit fault indicated
[ 132.861362] sfp sfp: module persistently indicates fault, disabling
i have some new new. AFM0002TIM its fully compatible with turris omnia if you need to modify sn and ploam passsword you can change it
UF-INSTANT have issues with the eeprom like the CPG0S03-0490 V2.0 so im still waiting to see the kernel patch
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.
Example values that could be used:
0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef 00: 03 04 01 00 00 00 02 00 00 00 00 03 0c 00 14 c8 ???...?....??.?? 10: 00 00 00 00 43 61 72 6c 69 74 6f 78 78 50 72 6f ....CarlitoxxPro 20: 20 20 20 20 00 00 e0 4c 56 32 38 30 31 46 20 20 ..?LV2801F 30: 20 20 20 20 20 20 20 20 56 32 2e 30 05 1e 00 40 V2.0??.@ 40: 00 1a 00 00 43 50 32 30 32 30 30 33 31 38 30 30 .?..CP2020031800 50: 36 36 20 20 32 31 30 33 32 38 00 00 68 e0 02 03 66 210328..h???
Im going to test that patched kernel and all all like uf instant eeprom and test all other modules
thanks for the info and patch
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.
Thank you @backon for your report!
As far as I understood, these are the SFP modules working in kernel 5.10 (HBD in Turris):
I think I’m going to the first one, since it have GUI and 2.5G without hacks