Banana Pi BPI-R3 OpenWRT image

I am a rookie and I don’t know what command to use to swipe in

Really, please just read the instructions:

  1. Insert the microSD card with OpenWrt image on it. See the instructions in the link on how to put OpenWrt on the microSD card
  2. Setup little switches on the R3 board to positions A=1, B=1, C=1, D=1
  3. Connect the serial port and start terminal program (puTTY or minicom or such thing)
  4. Now power on the device. Right in the beginning you see a menu. There you can use the cursor keys to navigate and select installation to SPI-NAND. Do that.
  5. Once installation to SPI-NAND is done, remove the power from the device, and remove microSD card.
  6. Setup little switches on the R3 board to positions A=1, B=0, C=1, D=0
  7. Now power on the device, now it should be starting from SPI-NAND memory. Right in the beginning you again see a menu. Again use the cursor keys to navigate and select installation to eMMC. Do that.
  8. Remove power again
  9. Setup little switches on the R3 board to positions A=0, B=1, C=1, D=0
  10. Now you are done, the device will boot from eMMC.
1 Like

I know the steps, openwrt official website to get the firmware is bin format, you give the steps is img format, and openwrt official website to give the firmware is not bl2_emmc but more a openwrt-mediatek-filogic-bananapi_bpi-r3-emmc-bl31-uboot.fip file I wouldn’t know how to refresh it? I understand the following steps do not know if it is right.

  • mount -t vfat /dev/sda1 /mnt
  • echo 0 > /sys/block/mmcblk0boot0/force_ro
  • dd if=openwrt-mediatek-filogic-bananapi_bpi-r3-emmc-preloader.bin of=/dev/mmcblk0
  • mmc bootpart enable 1 1 /dev/mmcblk0

Please just read the instructions, it’s written there:

If you want to use official OpenWrt you have to start like this with a microSD card. You can not use SinoVoip’s MediaTek SDK factory build to switch to OpenWrt, it cannot work and there is not way.

Thank you for your pointers

1 Like

I discovered that somehow the current OpenWRT brings up the network before the macaddress is set:

ifconfig phy0-ap0
phy0-ap0  Link encap:Ethernet  HWaddr 00:0C:43:26:60:00
          inet6 addr: fe80::20c:43ff:fe26:6000/64 Scope:Link
wifi up
ifconfig phy0-ap0
phy0-ap0  Link encap:Ethernet  HWaddr BA:C3:31:B6:10:8A
          inet6 addr: fe80::b8c3:31ff:feb6:108a/64 Scope:Link

Oh wow, that’s a problem. I was wondering if it can work in the way we built it, and thought it’s ok because other boards do the same. Turns out: it’s not.

Anyone can share some recent snapshot? Latest one bricked my device. Cannot build a new one either.

image

EDIT. Found a working one. Weird stuff anyways.

Error building the firmware image

Server response: Unsupported package(s): procd-ujail, procd-seccomp, procd

Please report the error message and request

The latest builds with some kind of problems all the time.

I encountered a problem with vanilla OpenWRT snapshot builds for Banana Pi R3 running on HW 1.1 (didn’t try builds from sinovoip though yet) - it prevents practical use of it in my setup.

I configure internet connection via PPPoE with credentials provided by ISP - connecting WAN ethernet port to ISP-provided optics-to-ethernet media converter box. When I do this - I get “Unknown error (USER_REQUEST)” in LuCi.

In debug console it looks like WAN to media converter ethernet link goes down every few seconds:

[  413.827897] mt7530 mdio-bus:1f wan: configuring for phy/gmii link mode
[  413.860935] mt7530 mdio-bus:1f wan: configuring for phy/gmii link mode
[  417.048288] mt7530 mdio-bus:1f wan: Link is Up - 1Gbps/Full - flow control off
[  417.055525] IPv6: ADDRCONF(NETDEV_CHANGE): wan: link becomes ready
[  432.300578] mt7530 mdio-bus:1f wan: Link is Down
[  432.307980] mt7530 mdio-bus:1f wan: configuring for phy/gmii link mode
[  432.341040] mt7530 mdio-bus:1f wan: configuring for phy/gmii link mode
[  435.898735] mt7530 mdio-bus:1f wan: Link is Up - 1Gbps/Full - flow control off
[  435.905974] IPv6: ADDRCONF(NETDEV_CHANGE): wan: link becomes ready
[  443.449471] mt7530 mdio-bus:1f wan: Link is Down
[  443.457038] mt7530 mdio-bus:1f wan: configuring for phy/gmii link mode
[  443.489716] mt7530 mdio-bus:1f wan: configuring for phy/gmii link mode
[  446.748057] mt7530 mdio-bus:1f wan: Link is Up - 1Gbps/Full - flow control off
[  446.755293] IPv6: ADDRCONF(NETDEV_CHANGE): wan: link becomes ready
[  462.020686] mt7530 mdio-bus:1f wan: Link is Down

readlog gives me this:

Mon Apr 24 20:07:51 2023 daemon.notice netifd: Interface 'wan_eth' is enabled
Mon Apr 24 20:07:51 2023 daemon.notice netifd: Interface 'wan_eth' is setting up now
Mon Apr 24 20:07:51 2023 kern.info kernel: [ 3932.942194] mt7530 mdio-bus:1f wan: configuring for phy/gmii link mode
Mon Apr 24 20:07:51 2023 daemon.info pppd[19964]: Plugin pppoe.so loaded.
Mon Apr 24 20:07:51 2023 daemon.info pppd[19964]: PPPoE plugin from pppd 2.4.9
Mon Apr 24 20:07:51 2023 daemon.notice pppd[19964]: pppd 2.4.9 started by root, uid 0
Mon Apr 24 20:08:06 2023 daemon.warn pppd[19964]: Timeout waiting for PADO packets
Mon Apr 24 20:08:06 2023 daemon.err pppd[19964]: Unable to complete PPPoE Discovery
Mon Apr 24 20:08:06 2023 daemon.info pppd[19964]: Exit.
Mon Apr 24 20:08:06 2023 daemon.notice netifd: Interface 'wan_eth' is now down
Mon Apr 24 20:08:06 2023 daemon.notice netifd: Interface 'wan_eth' is disabled
Mon Apr 24 20:08:06 2023 daemon.notice netifd: Interface 'wan_eth' is enabled
Mon Apr 24 20:08:06 2023 daemon.notice netifd: Interface 'wan_eth' is setting up now
Mon Apr 24 20:08:06 2023 kern.info kernel: [ 3948.262162] mt7530 mdio-bus:1f wan: configuring for phy/gmii link mode
Mon Apr 24 20:08:06 2023 daemon.info pppd[20069]: Plugin pppoe.so loaded.
Mon Apr 24 20:08:06 2023 daemon.info pppd[20069]: PPPoE plugin from pppd 2.4.9
Mon Apr 24 20:08:07 2023 daemon.notice pppd[20069]: pppd 2.4.9 started by root, uid 0
Mon Apr 24 20:08:22 2023 daemon.warn pppd[20069]: Timeout waiting for PADO packets
Mon Apr 24 20:08:22 2023 daemon.err pppd[20069]: Unable to complete PPPoE Discovery
Mon Apr 24 20:08:22 2023 daemon.info pppd[20069]: Exit.
Mon Apr 24 20:08:22 2023 daemon.notice netifd: Interface 'wan_eth' is now down
Mon Apr 24 20:08:22 2023 daemon.notice netifd: Interface 'wan_eth' is disabled
Mon Apr 24 20:08:22 2023 daemon.notice netifd: Interface 'wan_eth' is enabled
Mon Apr 24 20:08:22 2023 daemon.notice netifd: Interface 'wan_eth' is setting up now
Mon Apr 24 20:08:22 2023 kern.info kernel: [ 3963.552196] mt7530 mdio-bus:1f wan: configuring for phy/gmii link mode
Mon Apr 24 20:08:22 2023 daemon.info pppd[20174]: Plugin pppoe.so loaded.
Mon Apr 24 20:08:22 2023 daemon.info pppd[20174]: PPPoE plugin from pppd 2.4.9
Mon Apr 24 20:08:22 2023 daemon.notice pppd[20174]: pppd 2.4.9 started by root, uid 0
Mon Apr 24 20:08:37 2023 daemon.warn pppd[20174]: Timeout waiting for PADO packets
Mon Apr 24 20:08:37 2023 daemon.err pppd[20174]: Unable to complete PPPoE Discovery
Mon Apr 24 20:08:37 2023 daemon.info pppd[20174]: Exit.
Mon Apr 24 20:08:37 2023 daemon.notice netifd: Interface 'wan_eth' is now down
Mon Apr 24 20:08:37 2023 daemon.notice netifd: Interface 'wan_eth' is disabled

Interesting thing is that if I configure the same interface to DHCP (instead of PPPoE) and plug it into router - it works flawlessly. Also even more interesting - if I configure Static IP and plug it to the same media converter (with the same cable) then again - everything is fine - no disconnections (of course no internet either unfortunately).

Looks like some software bug. My current router (TP-Link Archer A64 with its native FW) works flawlessly with the same PPPoE connection to the same media converter with the same cable.

Research of this problem lead me to find many bug reports with similar symptoms both very old and quite recent - most of them supposedly fixed/closed/resolved (e.g. this or this, etc).

Is there something I can try to resolve this problem? Any ideas?

First of all, please share your configuration. Most likely something is wrong there. Please post the content of /etc/config/network here (make sure to remove PPPoE username and password!).

Sure. Here it is:

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 'fd08:2679:9aa1::/48'

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.1.1'
        option netmask '255.255.255.0'
        option ip6assign '60'

config device
        option name 'eth1'
        option macaddr '6a:50:3b:cf:46:74'

config device
        option name 'wan'
        option macaddr '6a:50:3b:cf:46:73'

config interface 'wan_eth'
        option proto 'pppoe'
        option device 'wan'
        option username '<username>'
        option password '<password>'
        option ipv6 'auto'

config interface 'wan_sfp'
        option proto 'pppoe'
        option device 'eth1'
        option username '<username>'
        option password '<password>'
        option ipv6 'auto'

^^^ Here I already broke br-wan bridge device into separate wan ethernet port and eth1 (left SFP) devices and used wan device directly. I connected only ethernet cable from ISP’s media converter to wan port.

Initially I tried to simply switch to PPPoE in original wan interface configuration (that used original br-wan bridge device) with the same result - “Unknown error (USER_REQUEST)”.

I also tried adding:

    option mtu '1492'

and another time

    option mtu '1480'

(^^^That matches default config in my TP-Link router that works - with its native FW - not OpenWRT. Unfortunately I cannot install OpenWRT to this TP-Link - cannot risk losing Internet connection that I need to work.)

Also tried adding:

    option keepalive '10 6'

None of those tweaks changed the outcome.

I’ll also add package list that I used to build a snapshot here (in case this helps to diagnose):

base-files blkdiscard busybox ca-bundle collectd-mod-ethstat collectd-mod-ipstatistics collectd-mod-irq collectd-mod-load collectd-mod-ping collectd-mod-powerdns collectd-mod-sqm collectd-mod-thermal collectd-mod-wireless coreutils-sha512sum dnsmasq dropbear e2fsprogs exfat-fsck exfat-mkfs ethtool f2fs-tools f2fsck fdisk firewall4 fstools fstrim iperf iperf3 iptables iptables-mod-ipopt iptables-mod-conntrack-extra kmod-crypto-hw-safexcel kmod-fs-exfat kmod-fs-ext4 kmod-fs-f2fs kmod-fs-isofs kmod-fs-ntfs kmod-fs-squashfs kmod-fs-vfat kmod-gpio-button-hotplug kmod-hwmon-pwmfan kmod-i2c-gpio kmod-ifb kmod-ipt-ipopt kmod-leds-gpio kmod-loop kmod-mppe kmod-mt7915e kmod-mt7986-firmware kmod-ppp kmod-pppoe kmod-pppox kmod-pptp kmod-nft-offload kmod-nvme kmod-sched-core kmod-sched-connmark kmod-scsi-core kmod-sfp kmod-usb2 kmod-usb3 kmod-usb-core kmod-usb-ehci kmod-usb-ohci kmod-usb-storage kmod-usb-storage-extras kmod-usb-storage-uas kmod-usb-xhci-hcd kmod-usb-xhci-mtk libc libgcc libustream-mbedtls lm-sensors logd luci luci-app-commands luci-app-minidlna luci-app-samba4 luci-app-statistics luci-compat luci-proto-bonding luci-proto-ipip luci-proto-ipv6 luci-proto-ppp mc minidlna mkf2fs mt7986-wo-firmware mtd netifd nftables ntfs-3g ntfs-3g-utils odhcp6c odhcpd-ipv6only opkg pciutils ppp ppp-mod-pppoe ppp-mod-pptp procd procd-seccomp procd-ujail resolveip rp-pppoe-common qos-scripts samba4-admin samba4-server samba4-utils smartmontools sysfsutils tune2fs uboot-envtools uci uclient-fetch urandom-seed urngd usbutils wpad-basic-mbedtls

(The last build I tested was built on 2023.04.25.)

I can provide full snapshot build output log if needed - I saved it.

So you are still seeing this ^^^ in the logs? If so, maybe your ISP uses a VLAN for PPPoE (many if not most ISPs do that)?

Yes. I always see this in the logs. TBH I don’t know if my ISP (or media converter provided by ISP?) uses VLAN for PPPoE or not. If you say that most of them do - probably my ISP also does.

How do I deal with it? What I should change in config?

(In my TP-Link there is no VLAN-related settings and everything works fine…)

It depends on your country and supposedly hence where you got the TP-Link device from and who sold or gave it to you. In many countries VLAN 7 is used for the PPPoE link providing Internet connectivity, while other VLANs are used for VoIP, IP-TV, management, …

So my first try here would be to use wan.7 instead of wan as device for the wan_eth interface. If that doesn’t work, search on the search engine of your choice for the exact settings required for your ISP and/or inside the country you are.

My TP-Link is usual stock version that I bought here (in Ukraine) - no custom ISP side tweaks or something. I configured network settings myself.

Just browsed router settings more thoroughly and found that apparently VLAN is turned off (“Configure IPTV/VLAN settings if you want to enjoy IPTV or VoIP service, or if your ISP requires VLAN tags.” - checkbox OFF). On that same page also noticed setting under Multicast subsection - checkbox “IGMP Proxy: ON” (and combo selection “IGMP Version: V3”) - not sure if that matters.

Just in case configured in LuCi wan.7 (selection “VLAN (802.1q)” in Devices tab -> “Add device configuration…” dialog, right?) - effect is almost the same. Link is down every several seconds and the same error in GUI. The only difference is that if wan is selected in PPoE interface than RX: stats is occasionally growing on that interface while with wan.7 it remains 0 and never grows.

[  257.278423] mt7530 mdio-bus:1f wan: Link is Down
[  257.285652] mt7530 mdio-bus:1f wan: configuring for phy/gmii link mode
[  257.400231] mt7530 mdio-bus:1f wan: configuring for phy/gmii link mode
[  260.315480] mt7530 mdio-bus:1f wan: Link is Up - 1Gbps/Full - flow control off
[  260.322728] IPv6: ADDRCONF(NETDEV_CHANGE): wan: link becomes ready
[  260.329154] IPv6: ADDRCONF(NETDEV_CHANGE): wan.7: link becomes ready
[  275.748427] mt7530 mdio-bus:1f wan: Link is Down
[  275.755952] mt7530 mdio-bus:1f wan: configuring for phy/gmii link mode
[  275.870263] mt7530 mdio-bus:1f wan: configuring for phy/gmii link mode
[  278.757497] mt7530 mdio-bus:1f wan: Link is Up - 1Gbps/Full - flow control off
[  278.764746] IPv6: ADDRCONF(NETDEV_CHANGE): wan: link becomes ready
[  278.771350] IPv6: ADDRCONF(NETDEV_CHANGE): wan.7: link becomes ready
[  294.208428] mt7530 mdio-bus:1f wan: Link is Down
[  294.216053] mt7530 mdio-bus:1f wan: configuring for phy/gmii link mode
[  294.330205] mt7530 mdio-bus:1f wan: configuring for phy/gmii link mode
[  297.607030] mt7530 mdio-bus:1f wan: Link is Up - 1Gbps/Full - flow control off
[  297.614276] IPv6: ADDRCONF(NETDEV_CHANGE): wan: link becomes ready
[  297.620877] IPv6: ADDRCONF(NETDEV_CHANGE): wan.7: link becomes ready

Using any vlan used anywhere is wrong. You need to get your ISPs settings. Either extract them from working setup or ask your provider. Vlan-setup requires multiple pppoe-sessions with different credentials. I have this here in germany with local ISP (bambit one vlan for voip and one for internet)…and this ISP uses vlans 110 and 140

another point in my setup is that mac-adresses from both vlans need to be different on my side to get it working

Yes. Totally agree.

Apparently everything points to the conclusion that my ISP doesn’t use VLAN - (1) no mentions on ISP provided settings memo paper copy - only Username//Password, (2) VLAN off in my current router config that works fine.

Maybe also that Vlan is configured into ONT. In Europe almost every ISP that use PPPoE use a Vlan. Check also if you need to clone the MAC address of the original router or to comunicate the new MAC to the ISP.

1 Like

Thanks a lot! Worked like a charm.

How didn’t I try this earlier? This is so obvious. (Clone router’s MAC.)

While I know that my ISP doesn’t lock to a specific MAC address of my router - as I never communicated it to them and changed the router twice and I use internal MAC (didn’t ever override MAC address for this connection).

BUT it is quite reasonable to assume that ISP equipment may either validate the registered Vendor ID from MAC or at least check its Universally Administered Bit.

Apparently while understandable but it is still quite annoying shortcoming of OpenWRT’s default behavior - assigning Locally Administered random MAC address to WAN interface. (I wasted a week to figure this out - BIG disclamer in LuCi GUI would be VERY useful. Having LuCI GUI in a build by default would be helpful too BTW.)