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: 494241
imho 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.
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”.
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.
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