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!
PS. In case somebody finds this problem, here’s the solution: ONU must be inserted when the Banana boots (and probably powers on). Then there is no “NO CARRIER”.
1 Like
GPON ONU is only working after a Banana reboot, it does not work after a power on.
Also rebooting ONU is making it inaccessible again.
It seems there’s a racing condition somewhere. What can be done?
Most likely it takes too long for the stick to boot up.
You could apply a quirk. It means rebuilding the kernel.
You could also unbind and rebind the sfp driver after power up…
echo sfp-1 >/sys/bus/platform/drivers/sfp/unbind
echo sfp-1 >/sys/bus/platform/drivers/sfp/bind
Or sfp-2 if it is in other cage.
Hopefully this doesn’t cause the stick to reboot.
1 Like
Thank you. This works in rc.local:
sleep 60
echo sfp-1 >/sys/bus/platform/drivers/sfp/unbind
echo sfp-1 >/sys/bus/platform/drivers/sfp/bind
But if I then reboot ONU through embedded OpenWRT, the ONU does not come up again. This means the internet connection may become unreliable in case the ONU reboots sometime… What quirk can I apply to overcome this?
This is not the case because I loose link to 192.168.1.10 (NO-CARRIER).
Do the same 60 seconds after rebooting the onu.
Yep, but how do I detect if ONU decides to reboot randomly? Even remotely? Too unreliable
Write a bash script that pings the local ip of the web interface perhaps.
I was able to get the Alcatel Lucent G-010S-P working well with the OpenWrt snapshot build using the attached patch I made. It’s essentially a backport of sfp.c from the latest Linux kernel, with changes to apply the long startup, los, and tx fault quirks to the module.
999-G010SP-sfp.patch (7.8 KB)
1 Like
Hello there,
I’ve tried to apply this patch to openwrt-23.05 branch placed it target/linux/mediatek/patches-5.15/999-sfp.patch here and it was rejected. Could you please provide more information about branch and commit that had been used?
The patch looks like it is defined for later kernel version than 5.15 like 6.1 or 6.6 as 5.15 had completely different code for sfp quirks. So try 6.1-patches or 6.6-patches folder and switching to this kernel
I used the snapshot/main branch, the patch is for kernel 6.6. frank-w is correct, the code changed a lot between kernel versions.