Ma5671A SFP issues on turris os 5.0.3

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.

1 Like

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. :slight_smile:


@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.

  1. 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?
  2. 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 :slight_smile:

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 :slight_smile:
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???
1 Like

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):

  • DFP-34G-2C2
  • G-010S-A
  • AFM0002TIM

I think I’m going to the first one, since it have GUI and 2.5G without hacks :slight_smile:

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?

Thank you in advance

Hi @vk496,
The idea would be to use the command
i2cset -y 5 0x50 <offset> <value>
to set the required data.

For example, the values I posted previously could be set using this series of commands:

i2cset -y 5 0x50 0x00 0x03
i2cset -y 5 0x50 0x01 0x04
i2cset -y 5 0x50 0x02 0x01
i2cset -y 5 0x50 0x03 0x00
i2cset -y 5 0x50 0x04 0x00
i2cset -y 5 0x50 0x05 0x00
i2cset -y 5 0x50 0x06 0x02
i2cset -y 5 0x50 0x07 0x00
i2cset -y 5 0x50 0x08 0x00
i2cset -y 5 0x50 0x09 0x00
i2cset -y 5 0x50 0x0A 0x00
i2cset -y 5 0x50 0x0B 0x03
i2cset -y 5 0x50 0x0C 0x0c
i2cset -y 5 0x50 0x0D 0x00
i2cset -y 5 0x50 0x0E 0x14
i2cset -y 5 0x50 0x0F 0xc8
i2cset -y 5 0x50 0x10 0x00
i2cset -y 5 0x50 0x11 0x00
i2cset -y 5 0x50 0x12 0x00
i2cset -y 5 0x50 0x13 0x00
i2cset -y 5 0x50 0x14 0x43
i2cset -y 5 0x50 0x15 0x61
i2cset -y 5 0x50 0x16 0x72
i2cset -y 5 0x50 0x17 0x6c
i2cset -y 5 0x50 0x18 0x69
i2cset -y 5 0x50 0x19 0x74
i2cset -y 5 0x50 0x1A 0x6f
i2cset -y 5 0x50 0x1B 0x78
i2cset -y 5 0x50 0x1C 0x78
i2cset -y 5 0x50 0x1D 0x50
i2cset -y 5 0x50 0x1E 0x72
i2cset -y 5 0x50 0x1F 0x6f
i2cset -y 5 0x50 0x20 0x20
i2cset -y 5 0x50 0x21 0x20
i2cset -y 5 0x50 0x22 0x20
i2cset -y 5 0x50 0x23 0x20
i2cset -y 5 0x50 0x24 0x00
i2cset -y 5 0x50 0x25 0x00
i2cset -y 5 0x50 0x26 0xe0
i2cset -y 5 0x50 0x27 0x4c
i2cset -y 5 0x50 0x28 0x56
i2cset -y 5 0x50 0x29 0x32
i2cset -y 5 0x50 0x2A 0x38
i2cset -y 5 0x50 0x2B 0x30
i2cset -y 5 0x50 0x2C 0x31
i2cset -y 5 0x50 0x2D 0x46
i2cset -y 5 0x50 0x2E 0x20
i2cset -y 5 0x50 0x2F 0x20
i2cset -y 5 0x50 0x30 0x20
i2cset -y 5 0x50 0x31 0x20
i2cset -y 5 0x50 0x32 0x20
i2cset -y 5 0x50 0x33 0x20
i2cset -y 5 0x50 0x34 0x20
i2cset -y 5 0x50 0x35 0x20
i2cset -y 5 0x50 0x36 0x20
i2cset -y 5 0x50 0x37 0x20
i2cset -y 5 0x50 0x38 0x56
i2cset -y 5 0x50 0x39 0x32
i2cset -y 5 0x50 0x3A 0x2e
i2cset -y 5 0x50 0x3B 0x30
i2cset -y 5 0x50 0x3C 0x05
i2cset -y 5 0x50 0x3D 0x1e
i2cset -y 5 0x50 0x3E 0x00
i2cset -y 5 0x50 0x3F 0x40
i2cset -y 5 0x50 0x40 0x00
i2cset -y 5 0x50 0x41 0x1a
i2cset -y 5 0x50 0x42 0x00
i2cset -y 5 0x50 0x43 0x00
i2cset -y 5 0x50 0x44 0x43
i2cset -y 5 0x50 0x45 0x50
i2cset -y 5 0x50 0x46 0x32
i2cset -y 5 0x50 0x47 0x30
i2cset -y 5 0x50 0x48 0x32
i2cset -y 5 0x50 0x49 0x30
i2cset -y 5 0x50 0x4A 0x30
i2cset -y 5 0x50 0x4B 0x33
i2cset -y 5 0x50 0x4C 0x31
i2cset -y 5 0x50 0x4D 0x38
i2cset -y 5 0x50 0x4E 0x30
i2cset -y 5 0x50 0x4F 0x30
i2cset -y 5 0x50 0x50 0x36
i2cset -y 5 0x50 0x51 0x36
i2cset -y 5 0x50 0x52 0x20
i2cset -y 5 0x50 0x53 0x20
i2cset -y 5 0x50 0x54 0x32
i2cset -y 5 0x50 0x55 0x31
i2cset -y 5 0x50 0x56 0x30
i2cset -y 5 0x50 0x57 0x33
i2cset -y 5 0x50 0x58 0x32
i2cset -y 5 0x50 0x59 0x38
i2cset -y 5 0x50 0x5A 0x00
i2cset -y 5 0x50 0x5B 0x00
i2cset -y 5 0x50 0x5C 0x68
i2cset -y 5 0x50 0x5D 0xe0
i2cset -y 5 0x50 0x5E 0x02
i2cset -y 5 0x50 0x5F 0x03

You can check the current data with:
i2cdump 5 0x50

1 Like

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).