sorry, as the G-010S-P is now fully working, we are checking the MA5671A which is flashed with the fs.com firmware and viewed as "Lantiq Falcon SFP "
Is the MA5671A with original firmware working?
The dup ping could be caused by bit errors. Could you check ethtool statiatics (ethtool -s iface) if there are crc- or any other errors (fcs)?
Someone here reported he was using one with the original rooted firmware, and it was working.
I bought mine flashed with the FS.COM firmware, because the original firmware doesn’t work with my ISP.
I’m using R3 with the MA5671A and standard firmware on a relative old snapshot release of OpenWRT. It works ok. The same ONT never worked with other firmware with my R3 and ISP.
Have you tried recent version after adding the sfp power patch? If not can you please try?
I’m on r23223 with Kernel 5.15.114 that is already 3W patched. I found this on bootlog:
[14.723146] sfp sfp1: Host maximum power 3.0W [14.728273] sfp sfp2: Host maximum power 3.0W
I don’t want to risk with newer snapshots cause automatic upgrade don’t works anymore and I have no time and a secure way to revert in case of troubles. Anyway the issue seems not related with 3 watts patch.
My guess it is that the issue is related only with the MA5671A with not original firmware. Solving with FS.com firmware can be really useful ‘cause it is needed with different ISP / OLT manufacturers. Anyway I hope that solving for FS.com fw do not break the standard fw.
you can try different sdcard so you keep current version…if it does not work,try to find out exact version (git commit id) of your working version so we can try to find out whats missing
just tested, nothing reported by this command.
Sorry should be -S (big letter S)
root@OpenWrt:~# ethtool -S eth1
NIC statistics:
tx_bytes: 497168409
tx_packets: 4249717
tx_skip: 0
tx_collisions: 0
rx_bytes: 29155508612
rx_packets: 20887183
rx_overflow: 0
rx_fcs_errors: 0
rx_short_errors: 0
rx_long_errors: 0
rx_checksum_errors: 18
rx_flow_control_packets: 0
rx_xdp_redirect: 0
rx_xdp_pass: 0
rx_xdp_drop: 0
rx_xdp_tx: 0
rx_xdp_tx_errors: 0
tx_xdp_xmit: 0
tx_xdp_xmit_errors: 0
rx_pp_alloc_fast: 2762292
rx_pp_alloc_slow: 7774
rx_pp_alloc_slow_ho: 0
rx_pp_alloc_empty: 7774
rx_pp_alloc_refill: 61930
rx_pp_alloc_waive: 0
rx_pp_recycle_cached: 0
rx_pp_recycle_cache_full: 0
rx_pp_recycle_ring: 2334481
rx_pp_recycle_ring_full: 2762
rx_pp_recycle_released_ref: 494241imho not that bad as expected…18 crc errors in 20887183 received packets…
as long as i can’t receive my IP from my ISP, it’s not good too 
now i’m wondering if there is not a bad setting somewhere in the ONT…last time i used it, it was working…
Hello, @frank-w @dangowrt Now that the BPI-R3 is officialy supported in openwrt 23.05, does it mean all the Patchs and Quirks we made here are integrated in 23.05 ?
i’m actually using a Mikrotik RB5009 as main router and my BPI-R3 as dumb AP.
On stable release my Huawei MA5671A with rooted standards firmware works ok. Any way it seems (I need to do some test) that the fiber cable need to be connected to the Sfp module to make it identified
Yes,it is reported multiple times that the gpon modules need link to be available. You can change kernel to use different gpio for “los” but when configured it should be changed back.
Thanks, this is not really an issue cause I use a media converter when I need to configure the SFP module
Hello guyz !!
i just upgraded my BPI-R3 with openwrt 23.05.2, and i can confirm now that my ONU MA5671A is fully working without the need of patchs/quirks. 
2 Likes
Hi.
I tried MA5671A and it worked using 192.168.1.10 address.
On the next day it does not work/ping with 23.05.5 or the latest snapshot.
I have 3: eth1: <NO-CARRIER,BROADCAST,MULTICAST,UP> and no messages in logs after detection of ONU.
Is there anything can be done?
Afaik you need link (you do not have as you see NO-CARRIER) to access the web frontend
Yep I see. But what could go wrong? It WAS working!