WED and beamforming on BPI-R3

it worked, but seriously, we shouldn’t have to do all this, there’s a problem that needs to be fixed in the firmware, not manually by the user.

root@OpenWrt:/# ip link show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1504 qdisc mq state UP qlen 1000
    link/ether 76:90:d8:d0:b4:82 brd ff:ff:ff:ff:ff:ff
root@OpenWrt:/# ip link set lan1 up
[ 2408.601087] mt7530-mdio mdio-bus:1f lan1: configuring for phy/gmii link mode
root@OpenWrt:/# [ 2411.597005] mt7530-mdio mdio-bus:1f lan1: Link is Up - 1Gbps/Full - flow control rx/tx
[ 2411.604934] IPv6: ADDRCONF(NETDEV_CHANGE): lan1: link becomes ready

root@OpenWrt:/#

root@OpenWrt:/# ethtool lan1
Settings for lan1:
        Supported ports: [ TP    MII ]
        Supported link modes:   10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Full
        Supported pause frame use: Symmetric Receive-only
        Supports auto-negotiation: Yes
        Supported FEC modes: Not reported
        Advertised link modes:  10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Full
        Advertised pause frame use: Symmetric Receive-only
        Advertised auto-negotiation: Yes
        Advertised FEC modes: Not reported
        Link partner advertised link modes:  10baseT/Half 10baseT/Full
                                             100baseT/Half 100baseT/Full
                                             1000baseT/Full
        Link partner advertised pause frame use: Symmetric Receive-only
        Link partner advertised auto-negotiation: Yes
        Link partner advertised FEC modes: Not reported
        Speed: 1000Mb/s
        Duplex: Full
        Auto-negotiation: on
        master-slave cfg: preferred slave
        master-slave status: master
        Port: Twisted Pair
        PHYAD: 1
        Transceiver: external
        MDI-X: Unknown
        Supports Wake-on: d
        Wake-on: d
        Link detected: yes

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

yes but to do this in firmware we need to know what exactly is the problem :stuck_out_tongue:

so, now all working so far? i see the link up is there :slight_smile:

well, so /etc/config/network is a mess

i copied the one i have from a backup, and run a network restart

Then i was finaly able to access Luci, when i clic on Network >> Interface menu i’m getting this :

image

it also happen on some other menus.

as i said, who know what else is broken…

Thanks for this and your reply. I’m an old ‘newbie’! Last time I created an OS from scratch was in 1975… Had to take the media from London to Warsaw (only airline networks in those days), a 14" 7.25MB replaceable disk that just fitted into an overhead locker! With a letter from CoCom permitting me to export a forbidden material to a Warsaw Pact country… I just love GitHub! Regards

That’s cool! My parents were in primary school back then. Things are so much easier these days!

Btw, @dangowrt , WED works fine and so does everything else. I forgot I was tinkering with LTO and that messed up everything. Silently

can you please summarize your current state in the other thread so we can clean up this thread? the ONT discussion has nothing to do with WED/Beamforming

1 Like

Do you know of any empirical way of how the WED could be tested?

My router reports:

$ zgrep 'WED' /proc/config.gz                                                                                        
CONFIG_NET_MEDIATEK_SOC_WED=y
CONFIG_GENERIC_LIB_DEVMEM_IS_ALLOWED=y

but I would like to check that in action before considering it as a victory :slight_smile:

run HTOP on your BPI, and start a speedtest with your smartphone connected to the wifi. if the cpu stay close to 0/1% then it’s a victory :laughing:

Mine shows ~ 3.0 % peaks in htop, though, luci-statistics show less than 0.8 CPU core %. Wonder why the difference?

OK so WED is enabled and working :+1:

1 Like

Crap, it doesn’t work for me. The usage jumps to 40% once I start the speedtest.

$ zgrep 'WED' /proc/config.gz                                                                                        
CONFIG_NET_MEDIATEK_SOC_WED=y

What else should I check? Should the regular hardware offloading be also enabled for idk the WAN interface ? Should I configure flowtables? Maybe I am missing a kernel module that is responsible for that? :thinking:

Please note that I am not using OpenWRT but just a regular linux.

if you’re using Linux then @frank-w should be able to help you

Have not done anything with wed yet…which kernel do you use? Have you added this?

that’s not about me, it’s about @ghostbuster91 which uses Linux. This setting is for openwrt…

I though openwrt have backports so this setting should be also in mainline linux…

@dangowrt can you say since which kernel version wed should work and if the way is same as in openwrt? I guess it also needs some dts properties in r3 dts…

I have answered you because you have pointed me,but answer was for @ghostbuster91

Yes, that’s true. The same settings applied on mainline Linux if using a recent enough kernel with WED supported.

Since which version is wed fully functional? And do i need additional dts parts (e.g. node enabling)?

I guess nftables is not needed here or does it like for wan/lan?

In mainline Linux WED is fully supported since v6.2.

You will need to set the module paramter wed_enable=Y for the mt7915e module.

As offloading depends on classifying packets into flows you do always depend on nftables. In order to use WED in a dump/bridged AP which doesn’t actually do any routing/NAT what-so-ever we got a eBPF hack in OpenWrt called bridger. So if you want to use WED on an OS other than OpenWrt, you will need to manually create the needed nftables rules and if you want to use WED on non-routing APs you will also need to package and build bridger.

Are these the same as for hw-nat with flowtable and offload flag…just adding the wifi interfaces? If not is it somewhere documented?

table ip filter {
        flowtable f {
                hook ingress priority filter + 1
                devices = { lan3, lan0, wan }
                flags offload;
        }

        chain forward {
                type filter hook forward priority filter; policy accept;
                ip protocol { tcp, udp } flow add @f
        }

Btw. Needs offload done before or after other rules are applied? E.g. forward-chain with drop policy (and/or last rule reject) allowing some specific flows

So the answer is found here:

Flowtables - nftables wiki

The packets follow the normal forwarding rules, until they are established. Then offload kicks in and forwarding rules are totally bypassed for the established connection.