There are some problems with my description at the beginning. I can confirm that there is no problem with my pppoe settings because the sfp port of eth2 can dial normally. With the same setting, lan0 cannot dial normally.
I formatted the log as code for better readability,but the only problem i see is this:
Timeout waiting for PADO packets
Which means you send PADI to your access node and got no response. On r4 the 2 sfp are mostly identical (both on mac directly),so i would guess there is a configuration issue on the bridge,but do not know any except vlan-awareness which would affect pppoe.
Which kernel/system do you use? Maybe disable offloading (flow offload,vlan offload).
Why dialin with lan0? Imho this is a very strange setup,as pppoe works on layer2…client sends PADI via broadcast (your full lan if bridged) and then get direct response (PADO with both macs set right) from access-control-node (router). Pppoe handshake then has 2 additional steps to handle ethernet parameters before next protocol (lcp) kicks in,but imho it is unrelated here.
because i have two broadband access to the internet one use sfp0 other use lan0
Have you tried removing lan0 from lanbr0 and use it with pppoe?
lan0 not in br-lan and not in br0 only lan0
see my pic
br-lan ： eth1、lan1、lan2、lan3
git from this
Linux OpenWrt 5.4.246 git
Hard to follow if someone (me) cannot read chinese chars and not know the frontend 
You can try use tcpdump on the interface and look if there is a PADI going out…maybe contact your isp if he sees this packet from your mac…maybe there is a mac filter…lan0 receives mac adress from eth0…maybe a problem is here that the other ports have same mac
Now you can learn Chinese.
thank you i‘will try it
Try upstream openwrt snapshot
上游的lan0可以拨号
openwrt23.snapshot lan0 pppoe is ok
but mtksdk openwrt21.02 can’t
So I post this problem on here.
then it is up to sinovoip to fix this issue
I had the same problem as him. lan 0 is isolated from brlan and subsequently set to wan intertace for pppoe dialing. Dial-up works normally on sfp0, but cannot be achieved on lan0 in this situation.
I captured packets on lan0 through tcpdump and found that there were PADI, PADO, and PADR packets, but I could not obtain the next stage of PADS packets. Maybe this is a driver problem with the switch that comes with MT7988 in the MTK SDK.
if mainline openwrt works without issues, i would not put work into it
Seems it is reported here too: mediatek: switch to Linux 6.1 and add BananaPi BPi-R4 by dangowrt · Pull Request #14140 · openwrt/openwrt · GitHub
you can try to revert/delete the ppe patch and see if it fixes your issue and report back
You can apply this patch to fix this issue.
1 Like
Good,it’s OK The lan0 can PPPOE Now.
Could you please let me know when this patch will be merged? https://git01.mediatek.com/plugins/gitiles/openwrt/feeds/mtk-openwrt-feeds/+/20a093d4d6d2bcf41a2db2c1796f0ee6dd04598e
- This feature was eventually implemented here.
Tested both official 25.12.5 and custom 24.10 with this patch - PPPoE on WAN port still fails with “Timeout waiting for PADO packets” (while an older OpenWrt 19 router and Ubuntu PC connect instantly on the same line).
It's really hard to believe that such a popular flagship board still cannot establish a basic PPPoE connection on WAN.
Do you send it over wan directly or over an vlan? You can setup a local pppoe server on another host an read packets via tcpdump to see if vlan tags and pppoe packets are leaving R4
https://wiki.fw-web.de/doku.php?id=en:bpi-r2:network:start#server1
It is sent directly over WAN untagged (no VLAN). On Ubuntu and OpenWrt 19 it connects on the raw physical interface without VLAN.
Thanks for the pppoe-server idea - I will connect R4’s WAN port directly to a PC NIC, run pppoe-server and tcpdump on the PC side to inspect the exact egress frames and see if any unexpected tags/padding issues are present.
I completed the local PPPoE server test: BPI-R4 connects successfully to pppoe-server on Ubuntu. The capture on the PC shows untagged, correctly padded PADI frames.
However, through my C-Data FD511G-X ONU, R4 sends PADI but receives no PADO. Ubuntu and my old OpenWrt router connect through the same ONU without problems. Disabling flow control and testing at 100 Mbps did not help. What would you suggest checking next?
Would a compatible ONU SFP module in the R4 bypass this problem, or could it behave the same way? I was considering a GPON stick, but the C-Data status page reports EPON, so I assume I would need an EPON module supported and provisioned by my ISP. Does this approach make sense?