799

Something very odd started happening after a sysupgrade last weekend. And continues happening today on a freshly written sdcard without any non standard packages:

R4 comes back up, works normally in the LAN but does no longer obtain an IP from the ISP (10G SFP+).

Since I needed the link back up, I grabbed another sdcard with r26161 on it and it works again. Did I miss something in the past few weeks?

800

This significant change is that ethtool settings are now also applied to SFP modules.
Maybe this is a problem because it can of course be that your setup depended on the previvous (broken) behavior.

Please install ethtool-full on both images and share the output of

ethtool eth2
ethtool -a eth2

(assuming that you are using eth2 to connect to your ISP)

If the results are not the same on working vs. non-working image, you can adjust in /etc/config/network by creating a device section and settings speed, duplex and pause.

1 Like
801

Thanks, here we go. It seems to me that the link is up properly (?) [the 10G DAC works either way]. What am I missing?

Old one

root@OpenWrt:~# opkg install ethtool-full
Multiple packages (libgcc1 and libgcc1) providing same name marked HOLD or PREFER. Using latest.
Installing ethtool-full (6.6-r1) to root...
Downloading https://downloads.openwrt.org/snapshots/packages/aarch64_cortex-a53/base/ethtool-full_6.6-r1_aarch64_cortex-a53.ipk
Configuring ethtool-full.
root@OpenWrt:~# ethtool eth2
Settings for eth2:
        Supported ports: [ FIBRE ]
        Supported link modes:   10000baseLR/Full
        Supported pause frame use: Symmetric Receive-only
        Supports auto-negotiation: Yes
        Supported FEC modes: Not reported
        Advertised link modes:  10000baseLR/Full
        Advertised pause frame use: Symmetric Receive-only
        Advertised auto-negotiation: Yes
        Advertised FEC modes: Not reported
        Speed: 10000Mb/s
        Duplex: Full
        Auto-negotiation: on
        Port: FIBRE
        PHYAD: 0
        Transceiver: internal
        Current message level: 0x000000ff (255)
                               drv probe link timer ifdown ifup rx_err tx_err
        Link detected: yes
root@OpenWrt:~# ethtool -a eth2
netlink error: Not supported

And FWIW, the DAC as downlink to the switch:

root@OpenWrt:~# ethtool eth1
Settings for eth1:
        Supported ports: [  ]
        Supported link modes:   2500baseX/Full
                                1000baseX/Full
                                10000baseCR/Full
        Supported pause frame use: Symmetric Receive-only
        Supports auto-negotiation: Yes
        Supported FEC modes: Not reported
        Advertised link modes:  10000baseCR/Full
        Advertised pause frame use: Symmetric Receive-only
        Advertised auto-negotiation: Yes
        Advertised FEC modes: Not reported
        Speed: 10000Mb/s
        Duplex: Full
        Auto-negotiation: on
        Port: Direct Attach Copper
        PHYAD: 0
        Transceiver: internal
        Current message level: 0x000000ff (255)
                               drv probe link timer ifdown ifup rx_err tx_err
        Link detected: yes

New one


 -----------------------------------------------------
 OpenWrt SNAPSHOT, r27110-54623c6a1d
 -----------------------------------------------------
=== WARNING! =====================================
There is no root password defined on this device!
Use the "passwd" command to set up a new password
in order to prevent unauthorized SSH logins.
--------------------------------------------------
root@OpenWrt:~# ethtool eth2
Settings for eth2:
        Supported ports: [ FIBRE ]
        Supported link modes:   10000baseLR/Full
        Supported pause frame use: Symmetric Receive-only
        Supports auto-negotiation: Yes
        Supported FEC modes: Not reported
        Advertised link modes:  10000baseLR/Full
        Advertised pause frame use: Symmetric Receive-only
        Advertised auto-negotiation: Yes
        Advertised FEC modes: Not reported
        Speed: 10000Mb/s
        Duplex: Full
        Auto-negotiation: on
        Port: FIBRE
        PHYAD: 0
        Transceiver: internal
        Current message level: 0x000000ff (255)
                               drv probe link timer ifdown ifup rx_err tx_err
        Link detected: yes
root@OpenWrt:~# ethtool -a eth2
Pause parameters for eth2:
Autonegotiate:  on
RX:             off
TX:             off

root@OpenWrt:~# ethtool -a eth1
Pause parameters for eth1:
Autonegotiate:  on
RX:             off
TX:             off

root@OpenWrt:~# ethtool eth1
Settings for eth1:
        Supported ports: [  ]
        Supported link modes:   2500baseX/Full
                                1000baseX/Full
                                10000baseCR/Full
        Supported pause frame use: Symmetric Receive-only
        Supports auto-negotiation: Yes
        Supported FEC modes: Not reported
        Advertised link modes:  10000baseCR/Full
        Advertised pause frame use: Symmetric Receive-only
        Advertised auto-negotiation: Yes
        Advertised FEC modes: Not reported
        Speed: 10000Mb/s
        Duplex: Full
        Auto-negotiation: on
        Port: Direct Attach Copper
        PHYAD: 0
        Transceiver: internal
        Current message level: 0x000000ff (255)
                               drv probe link timer ifdown ifup rx_err tx_err
        Link detected: yes


root@OpenWrt:~# dmesg | grep eth
[    0.000000] psci: probing for conduit method from DT.
[    4.092379] mtk_soc_eth 15100000.ethernet: generated random MAC address 65:74:68:25:64:00
[    4.100565] mtk_soc_eth 15100000.ethernet: generated random MAC address 65:74:68:25:64:00
[    4.112544] mtk_soc_eth 15100000.ethernet eth0: mediatek frame engine at 0xffffffc082780000, irq 103
[    4.122220] mtk_soc_eth 15100000.ethernet eth1: mediatek frame engine at 0xffffffc082780000, irq 103
[    4.131888] mtk_soc_eth 15100000.ethernet eth2: mediatek frame engine at 0xffffffc082780000, irq 103
[    4.372712] mtk_soc_eth 15100000.ethernet eth0: entered promiscuous mode
[    5.238540] mtk_soc_eth 15100000.ethernet eth0: configuring for fixed/internal link mode
[    5.246737] mtk_soc_eth 15100000.ethernet eth0: Link is Up - 10Gbps/Full - flow control rx/tx
[    9.181592] mtk_soc_eth 15100000.ethernet eth2: switched to inband/10gbase-r link mode
[    9.210178] mtk_soc_eth 15100000.ethernet eth1: switched to inband/10gbase-r link mode
[   15.025920] mtk_soc_eth 15100000.ethernet eth0: Link is Down
[   15.049894] mtk_soc_eth 15100000.ethernet eth0: configuring for fixed/internal link mode
[   15.058097] mtk_soc_eth 15100000.ethernet eth0: Link is Up - 10Gbps/Full - flow control rx/tx
[   15.092596] mtk_soc_eth 15100000.ethernet eth0: entered allmulticast mode
[   15.180703] mtk_soc_eth 15100000.ethernet eth1: configuring for inband/10gbase-r link mode
[   15.203962] br-lan: port 4(eth1) entered blocking state
[   15.209213] br-lan: port 4(eth1) entered disabled state
[   15.214524] mtk_soc_eth 15100000.ethernet eth1: entered allmulticast mode
[   15.221684] mtk_soc_eth 15100000.ethernet eth1: entered promiscuous mode
[   15.277383] mtk_soc_eth 15100000.ethernet eth2: configuring for inband/10gbase-r link mode
[   15.299166] mtk_soc_eth 15100000.ethernet eth1: Link is Up - 10Gbps/Full - flow control off
[   15.299519] br-wan: port 2(eth2) entered blocking state
[   15.312806] br-wan: port 2(eth2) entered disabled state
[   15.318057] mtk_soc_eth 15100000.ethernet eth2: entered allmulticast mode
[   15.325374] mtk_soc_eth 15100000.ethernet eth2: entered promiscuous mode
[   15.332262] br-lan: port 4(eth1) entered blocking state
[   15.337499] br-lan: port 4(eth1) entered forwarding state
[   15.386125] mtk_soc_eth 15100000.ethernet eth2: Link is Up - 10Gbps/Full - flow control off
[   15.397278] br-wan: port 2(eth2) entered blocking state
[   15.402542] br-wan: port 2(eth2) entered forwarding state
802

Have you seen this? :wink:

803

I've backported this patch to Linux 6.6 which is used by OpenWrt Snapshot:

If you compile your own OpenWrt Snapshot, simply drop the patch file in target/linux/mediatek/patches-6.6. This get you the feature anywhere from 3 months to half a year ahead of the curve.

I think eventually the patch will trickle down from Linux 6.12 to 6.6 LTS and then will get picked up by OpenWrt Snapshot.

I've been running the patch for the past two weeks. Watching CPU clock changes more frequently in 'htop' tells me it's effective & doing its job.

1 Like
804

Has anyone managed to get the official wifi module BPI-R4-NIC-BE14 to work?

It seems that snapshot openwrt have no kernel modules for it, so nic is completely invisible in the system: no interfaces, and even nothing by lspci.

That nic is somehow initializing only on the chinese firmware. However, it doesn't even work on it, and in general chinese FW is seems completely trash.

So there is no way to use BPI-R4-NIC-BE14, or I missing something?

805

We are waiting for MediaTek to release the firmware binaries needed for 2+3+3 layout of MT7995/6. There are experimental patches for the mt76 driver (see BananaPi forum), however, using them requires the firmware files which haven't yet been released to the public. (Note: using the firmware files which are part of the BPi stock firmware does not work because they are intended for the proprietary driver and not for mt76).

6 Likes
806

Been debugging my uplink issue with recent builds a bit more.

Starting to think there is something wrong with udhcpc in the boot sequence. It does not actually show up in syslog or hang around as daemon after boot but if I run it manually, I do get the IP I should get:

root@OpenWrt:~# udhcpc -i br-wan -f
udhcpc: started, v1.36.1
udhcpc: broadcasting discover
udhcpc: broadcasting select for 212.51.131.XX, server 82.197.188.234
udhcpc: lease of 212.51.131.XX obtained from 82.197.188.234, lease time 4000
udhcpc: ip addr add 212.51.131.XX/255.255.255.0 broadcast + dev br-wan
udhcpc: setting default routers: 212.51.131.1

and after that I can ping stuff on the net just fine. It also routes traffic for the LAN just fine. DNS is a bit weird but that could have many reasons (not the least being that the image I was using has https-dns-proxy installed)...

807

FWIW, what helped is setting force_link on wan and wan6:

config interface 'wan'
        option device 'br-wan'
        option proto 'dhcp'
        option force_link '1'

God knows why that is now needed...

1 Like
808

wouldn't these work ? https://git01.mediatek.com/plugins/gitiles/openwrt/feeds/mtk-openwrt-feeds/+/refs/heads/master/autobuild/autobuild_5.4_mac80211_release/package/kernel/mt76/src/firmware/mt7996/

I am using these with the be14 ... however I only have the 2g radio working ...
the second radio shows but can't use it ... third radio doesn't show

on Frank's debian build all three radios work ...

809

actually applying patch https://github.com/dangowrt/mt76/commit/8ad06fc44bb989b918e0c86da896235001b14419 with Frank's firmware files now shows the three radios :slight_smile:

810

Hey, could you summary what needs to be done to make it work? I want to prepare for the future. (Is it just patch from Dango repo https://github.com/dangowrt/mt76/commit/8ad06fc44bb989b918e0c86da896235001b14419 + download firmware https://git01.mediatek.com/plugins/gitiles/openwrt/feeds/mtk-openwrt-feeds/+/refs/heads/master/autobuild/autobuild_5.4_mac80211_release/package/kernel/mt76/src/firmware/mt7996/ or something else?)

Btw, similar question was done on forum openwrt. Replying there would be welcome.

811

which other openwrt forum ?

  1. apply this commit to your repo
    https://github.com/rmandrad/openwrt/commit/34988a2bb2b87ad58cdec828c6ea8389c3bca331

it includes Daniel's (dangowrt) patch to support 233 variant - https://github.com/rmandrad/mt76/commit/90e457b04357318cf347562c487881a4833f0d52
but also enable 11BE support on hostapd

  1. wget https://git01.mediatek.com/plugins/gitiles/openwrt/feeds/mtk-openwrt-feeds/+archive/refs/heads/master/autobuild/autobuild_5.4_mac80211_release/package/kernel/mt76/src/firmware/mt7996.tar.gz

  2. extract and copy to /lib/firmware/mediatek/mt7996 the files below

mt7996_wa_233.bin
mt7996_wm_233.bin|
mt7996_rom_patch_233.bin
mt7996_eeprom_233.bin
mt7996_dsp.bin

  1. reboot

note I just enabled 11be ... the gui doesn't support it ... and trying it now manually using hostapd

edit - the netfid / mac80211 scripts don't support iee80211be - does anyone know if there is ongoing work to update these ?

4 Likes
812

Hello, I hope you can help me solve these doubts that keep me awake at night, I don't have any WiFi 7 devices, I only have like 8 WiFi 6 devices.

I have fiber optic internet with a 300mbs plan and I am going to completely replace my ISP router with the GPON ONU "DFP-34X-2C2" recommended on this site:

But I have these doubts about the BPi-R3 and the BPi-R4 and I don't know which router to buy:

  1. WLAN Hardware:
    • BPi-R3: 2.4GHz: 4T4R, 5GHz: 4T4R
    • BPi-R4: 2.4GHz: 2T2R, 5GHz: 3T3R, 6GHz: 3T3R
  2. Diplexer:
    • BPi-R3: The 2.4 GHz and 5 GHz bands do not share the same antenna and there is no diplexer.
    • BPi-R4: The 2.4 GHz and 5 GHz bands share the same antenna and a diplexer is used to mix both signals.
  3. Power consumption (both WiFi bands enabled):
  4. Price:
    • BPi-R3: $121 Total (BPI-R3, Heat Sink, Power Supply and WiFi 6 Antennas).
    • BPi-R4: $207 Total (BPI-R4, Heat Sink and Power Supply = $119 + WiFi 7 Module = $74 + WiFi 7 Antennas = $14).

Is the BPi-R4 worth buying even though the wireless hardware is inferior to the BPi-R3?:

  1. From 4x4 each band on the BPi-R3 to 2x2 (2.4GHz) + 3x3 (5GHz) on the BPi-R4.
  2. The 2.4 GHz and 5 GHz bands share the same antenna on the BPi-R4 (not separated like on the BPi-R3).
  3. BPi-R4 consumes almost twice as much only because it has the new 6GHz band and all bands are now WiFi 7, but is this huge increase in power consumption worth it?
  4. The BPi-R4 costs almost twice as much, could it offer twice the performance of the BPi-R3?

Information:

  • Real-World comparison between WiFi 6 vs WiFi 7:
    # Insane Wifi 7 Router Shootout!!
https://www.youtube.com/watch?v=NgpknCHkORs&t=477s

# WiFi 6 vs 6E vs 7 Explained: Real-World Speed Testing!
https://www.youtube.com/watch?v=FUG8XhHmQ1Q&t=281s

# Wi-Fi 7 is Marketing BS (...for now)
https://www.youtube.com/watch?v=nvDAxWX-CYw
813

I'd say if your connection won't go above 2.5Gbps in 5 years and the cost is a major factor, get the R3. You can always add an AP later.

2 Likes
814

Your comparison is made with a replaceable and lightweight WiFi 7 card (BE-14) on the R4. There are plans for a BE-19, but that will most probably have an even higher power consumption.
Other than that you can also use WiFi 6 cards on the R4 (but 2 MT7915 instead of BE-14 won't decrease the power consumption unfortunately).

1 Like
815

I recommend you opening up a new thread for the comparison.

1 Like
816

Buy BPI R4 and pair it with one WiFI 6 card. It'll be good for the next 5 years. By then WiFi 7 will be dirt cheap or you may try with WiFi 8 supposedly.

The point of BPI R4 is that it has two m.2 slots and two mini PCIe slots. All are general purpose which means you can insert whatever mechanically & electrically compatible cards into the slots with Linux driver available. That's a huge tonne of flexibility that BPI R3 or any other brands' router boards on the market at the moment will simply pale.

2 Likes
817

Can you recommend an commercially available wi-fi 6/6E module for R4, which is well compatible with openwrt?

818

I remember I've seen someone put extra 10G NIC on one of the slot (I like this idea)