not sure it’s the same module as it says 3FE46541AA instead of G010SP
if (!memcmp(id.base.vendor_name, "ALCATELLUCENT ", 16) &&
!memcmp(id.base.vendor_pn, "3FE46541AA ", 16))
Then it is not the same…is your string there too? Maybe try another quirk/fixup (e.g. the bootup delay)?
i was told that kernel 6.x will be used in the next openwrt 24.x, in a couple of weeks…So let’s wait for it 
@frank-w My gpon stick is working with openwrt 24.10.0.
After I remove eth1 from wan and add new interface static address, I can ping my stick from router
root@OpenWrt:~# ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1): 56 data bytes
64 bytes from 192.168.1.1: seq=0 ttl=64 time=0.731 ms
64 bytes from 192.168.1.1: seq=1 ttl=64 time=0.355 ms
64 bytes from 192.168.1.1: seq=2 ttl=64 time=0.419 ms
64 bytes from 192.168.1.1: seq=3 ttl=64 time=0.393 ms
64 bytes from 192.168.1.1: seq=4 ttl=64 time=0.359 ms
64 bytes from 192.168.1.1: seq=5 ttl=64 time=0.263 ms
But I can’t ping or access stick from my PC
Mac ~ % ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1): 56 data bytes
92 bytes from openwrt.lan (192.168.100.1): Destination Port Unreachable
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst
4 5 00 5400 97e3 0 0000 3f 01 fcf8 192.168.100.123 192.168.1.1
Request timeout for icmp_seq 0
92 bytes from openwrt.lan (192.168.100.1): Destination Port Unreachable
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst
4 5 00 5400 1f1f 0 0000 3f 01 75bd 192.168.100.123 192.168.1.1
Request timeout for icmp_seq 1
92 bytes from openwrt.lan (192.168.100.1): Destination Port Unreachable
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst
4 5 00 5400 9042 0 0000 3f 01 049a 192.168.100.123 192.168.1.1
Request timeout for icmp_seq 2
92 bytes from openwrt.lan (192.168.100.1): Destination Port Unreachable
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst
4 5 00 5400 1ee8 0 0000 3f 01 75f4 192.168.100.123 192.168.1.1
Interface
config interface 'loopback'
option device 'lo'
option proto 'static'
option ipaddr '127.0.0.1'
option netmask '255.0.0.0'
config globals 'globals'
option ula_prefix 'fddc:a448:e755::/48'
option packet_steering '1'
config device
option name 'br-lan'
option type 'bridge'
list ports 'lan1'
list ports 'lan2'
list ports 'lan3'
list ports 'lan4'
list ports 'sfp2'
config interface 'lan'
option device 'br-lan'
option proto 'static'
option ipaddr '192.168.100.1'
option netmask '255.255.255.0'
option ip6assign '60'
config device
option name 'br-wan'
option type 'bridge'
list ports 'wan'
config device
option name 'wan'
option macaddr '3e:9b:90:6f:16:40'
config interface 'wan'
option device 'br-wan'
option proto 'dhcp'
config interface 'wan6'
option device 'br-wan'
option proto 'dhcpv6'
config interface 'GPON'
option proto 'static'
option device 'eth1'
option ipaddr '192.168.1.5'
option netmask '255.255.255.0'
My gpon stick is GPON ONU Stick 1.25G/2.5G ODI DFP-34CX-2C2 HSGQ SFP XPON ONU Stick
Do I need to use custom firewall rule or something?
PS: It’s the same as you’ve guessed, I need to plug fiber in order to access gpon stick.
You need to enable routing on r4 and tell your pc that it can reach the gpon subnet over your r4 lan address (but seems your pc config is right).
For deeper analysis you can start tcpdump on r4 lan interface and capturing icmp packets.
in your br-wan device there is no eth1 ports ?? it should be like this :
config device
option name 'eth1'
option macaddr '3e:9b:90:6f:16:40'
config device
option name 'br-wan'
option type 'bridge'
list ports 'eth1'
list ports 'wan'
and add ‘br-wan’ in your gpon interface :
config interface 'gpon'
option proto 'static'
option device 'br-wan'
option ipaddr '192.168.1.5'
option netmask '255.255.255.0'
do not use capital letters for interface names.
This works well for me since i have my BPI-R3
1 Like
Thanks guy. It worked.
Hello, since openwrt 24.10, when i reboot the BPI-R3, my gpon ONT Nokia G-010S-P display this message at startup : EEPROM base structure checksum failure: 0x7c != 0x00
root@OpenWrt:~# logread | grep "sfp"
Thu May 8 09:54:52 2025 kern.info kernel: [ 12.562771] sfp sfp-1: Host maximum power 3.0W
Thu May 8 09:54:52 2025 kern.info kernel: [ 12.567825] sfp sfp-2: Host maximum power 3.0W
Thu May 8 09:54:52 2025 kern.err kernel: [ 12.891510] sfp sfp-1: EEPROM base structure checksum failure: 0x7c != 0x00
Thu May 8 09:54:52 2025 kern.err kernel: [ 12.898467] sfp EE: 00000000: 03 04 01 00 00 00 00 00 00 00 00 03 19 00 00 c8 ................
Thu May 8 09:54:52 2025 kern.err kernel: [ 12.907143] sfp EE: 00000010: 00 00 00 00 40 40 42 40 40 41 00 00 00 00 00 00 ....@@B@@A......
Thu May 8 09:54:52 2025 kern.err kernel: [ 12.915818] sfp EE: 00000020: 00 20 20 20 00 00 00 00 46 00 11 10 41 50 00 00 . ....F...AP..
Thu May 8 09:54:52 2025 kern.err kernel: [ 12.924493] sfp EE: 00000030: 00 00 00 00 00 00 00 00 30 30 20 20 01 14 00 00 ........00 ....
Thu May 8 09:54:52 2025 kern.err kernel: [ 12.933167] sfp EE: 00000040: 40 b7 ba 7f 80 ff ff ff 20 3d f8 80 c0 ff ff ff @....... =......
Thu May 8 09:54:52 2025 kern.err kernel: [ 12.941842] sfp EE: 00000050: fc 7e 07 80 c0 ff ff ff 30 3d f8 80 c0 ff ff ff .~......0=......
Thu May 8 09:54:52 2025 kern.info kernel: [ 12.980030] sfp sfp-2: module OEM SFP-2.5G-T-R-RM rev 1.0 sn 2412190031 dc 241219
Thu May 8 09:54:54 2025 kern.info kernel: [ 15.657039] mt7530-mdio mdio-bus:1f sfp2: configuring for inband/2500base-x link mode
Thu May 8 09:54:54 2025 kern.info kernel: [ 15.658782] br-lan: port 5(sfp2) entered blocking state
Thu May 8 09:54:54 2025 kern.info kernel: [ 15.658804] br-lan: port 5(sfp2) entered disabled state
Thu May 8 09:54:54 2025 kern.info kernel: [ 15.658852] mt7530-mdio mdio-bus:1f sfp2: entered allmulticast mode
Thu May 8 09:54:54 2025 kern.info kernel: [ 15.661098] mt7530-mdio mdio-bus:1f sfp2: entered promiscuous mode
Thu May 8 09:54:59 2025 daemon.notice netifd: Network device 'sfp2' link is up
Thu May 8 09:54:59 2025 kern.info kernel: [ 20.569236] mt7530-mdio mdio-bus:1f sfp2: Link is Up - 2.5Gbps/Full - flow control off
Thu May 8 09:54:59 2025 kern.info kernel: [ 20.569435] br-lan: port 5(sfp2) entered blocking state
Thu May 8 09:54:59 2025 kern.info kernel: [ 20.569444] br-lan: port 5(sfp2) entered forwarding state
so my ONT doesn’t work until i take it out and put it back in its SFP cage.
Thu May 8 09:57:42 2025 kern.info kernel: [ 183.978797] sfp sfp-1: module removed
Thu May 8 09:57:46 2025 kern.info kernel: [ 187.645213] sfp sfp-1: module removed
Thu May 8 09:57:46 2025 kern.info kernel: [ 187.981352] sfp sfp-1: module ALCATELLUCENT G010SP rev 10 sn ALCLFAB44018 dc 161205
i don’t have this problem with my other ONT Huawei MA5671A.
How can we fix this problem ?
I guess there was a eeprom crc quirk in older openwrt which is now missing
I also have the SFP G-010s-A, I use it on a BPI-R3 in OpenWrt 23.05, I’m still going to test it on the latest version, and it has the same error. In the research I did on the forum, this happens because the SFP takes a long time to restart, so I managed to use the SFP, I used a media converter to configure the SFP and insert it into the BPI-R3. On the first boot, the SFP is not recognized, so I just restarted the BPI-R3 again and the SFP was recognized and I’m using the G-010s-A without a patch.
I also expired almost the same error on old 23.05 and new 24.10.2 openwrt version
[ 16.931749] sfp sfp-1: EEPROM base structure checksum failure: 0x92 != 0x00
[ 16.938711] sfp EE: 00000000: 03 04 01 00 00 00 00 00 00 00 00 03 10 00 04 c8 ................
[ 16.947387] sfp EE: 00000010: 00 00 00 00 40 40 42 40 50 40 0c 00 00 00 00 00 ....@@B@P@......
[ 16.956062] sfp EE: 00000020: 00 20 20 20 00 00 00 00 46 00 11 10 41 50 00 00 . ....F...AP..
[ 16.964737] sfp EE: 00000030: 00 00 00 00 00 00 00 00 30 30 20 20 01 14 00 00 ........00 ....
[ 16.973411] sfp EE: 00000040: 00 00 00 00 00 00 00 00 70 3d 61 81 c0 ff ff ff ........p=a.....
[ 16.982086] sfp EE: 00000050: f8 7e 8d 80 01 00 00 00 30 3d 61 81 c0 ff ff ff .~......0=a.....
helps only reinsert sfp module.
lets clarify, you said that you have no problems with “ONT Huawei MA5671A” and has fully supported in 24.10?
If crc is right after reinsert than it is not the known eeprom crc which have to be fixed by quirk…afaik the quirk is when eeprom crc is always wrong.
Maybe some delay quirk can help?
I thought that version 24.10.2 with kernel 6.6.93 already included it, but unfortunately, it doesn’t.
SFP_QUIRK_M("ALCATELLUCENT", "G010SP", sfp_quirk_2500basex),
So, do you suggest adding a path that introduces sfp_fixup_long_startup for the G010SP quirks and testing it?
Something like this:
SFP_QUIRK_M("ALCATELLUCENT", "G010SP", sfp_quirk_2500basex,
sfp_fixup_long_startup),
?
After I (and possibly @Rooot) test that, is there any way it will be merged into the OpenWRT mainstream? Or will I face the same problem in the next release?
I ask this because purchasing and setting up a guaranteed working “Huawei MA5671A” is a much simpler solution than going through the process of patching, compiling, and flashing just to make it work for me. However, if we can successfully integrate this fix and it proves useful for others as well, it would definitely make the effort worthwhile!
Does the firmware of the ONT allow you to change the vendor and product string? Then you can have it match a quirk that has the long startup.
I never thought about that. I guess changing the product string will be enough because the quirks for G-010S-A are exactly what it should look like.
SFP_QUIRK("ALCATELLUCENT", "3FE46541AA", sfp_quirk_2500basex,
sfp_fixup_long_startup),
Unfortunately, there is no simple way to do that. I can’t find any instructions on how to do it fw_printenv output looks very cryptic to me.
Eric means using his tool to write a known vendor string to your sfp eeprom…not related to fw_printenv
But imho the wrong way as it says your sfp is another one because of software in linux kernel…
I guess this was the second stick that I bricked with the i2csfp tool; the first was the DFP-34CX-2C2. Be careful, guys!
It failed to detect after I ran i2csfp sfp-1 eepromfix w/o any params.
Now, @Rooot, you are one-on-one with this problem.
I do not expect i2csfp works on any ONT. It was not written to use on ONT’s. Never can know what damage it could do, as every ONT is implemented in a different manner.
Some ONT’s firmware allows for changing the vendor and product string. If possible, this would be the easiest way
The only place where these strings are used in the kernel are for quirk/fixup lookup.
Edit:
It is likely this cannot be changed through the firmware, so then never mind the above, you’ll need to patch the kernel.