My problem seems to be an old one, resurrected: https://github.com/openwrt/mt76/issues/690
Oh no, my fears were confirmed, with latest mt76 wed is not working, router goes up to 85% CPU usage and the wireless client download speed is lower than before, not even reaching 700Mbps... I have several entries listed in /sys/kernel/debug/ppe0/entries but /sys/kernel/debug/ppe0/bind is empty. What a disappointment 
1 Like
Good news, I've found the cause, this commit: wifi: mt76: mt7915 add tc offloading support. After reverting the changes, wed is back: 30% CPU usage at over 800Mbps. Here is the reverting patch if needed:
--- a/mt7915/init.c
+++ b/mt7915/init.c
@@ -346,9 +346,6 @@ mt7915_init_wiphy(struct mt7915_phy *phy)
hw->max_tx_aggregation_subframes = IEEE80211_MAX_AMPDU_BUF_HE;
hw->netdev_features = NETIF_F_RXCSUM;
- if (mtk_wed_device_active(&mdev->mmio.wed))
- hw->netdev_features |= NETIF_F_HW_TC;
-
hw->radiotap_timestamp.units_pos =
IEEE80211_RADIOTAP_TIMESTAMP_UNIT_US;
--- a/mt7915/main.c
+++ b/mt7915/main.c
@@ -1514,20 +1514,6 @@ mt7915_net_fill_forward_path(struct ieee80211_hw *hw,
return 0;
}
-
-static int
-mt7915_net_setup_tc(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
- struct net_device *netdev, enum tc_setup_type type,
- void *type_data)
-{
- struct mt7915_dev *dev = mt7915_hw_dev(hw);
- struct mtk_wed_device *wed = &dev->mt76.mmio.wed;
-
- if (!mtk_wed_device_active(wed))
- return -EOPNOTSUPP;
-
- return mtk_wed_device_setup_tc(wed, netdev, type, type_data);
-}
#endif
const struct ieee80211_ops mt7915_ops = {
@@ -1580,6 +1566,5 @@ const struct ieee80211_ops mt7915_ops = {
.set_radar_background = mt7915_set_radar_background,
#ifdef CONFIG_NET_MEDIATEK_SOC_WED
.net_fill_forward_path = mt7915_net_fill_forward_path,
- .net_setup_tc = mt7915_net_setup_tc,
#endif
};
Save the text as something like 120-revert-mt7915-add-tc-offloading-support.patch in /package/kernel/mt76/patches and recompile.
@nbd Dear Felix, please look at your commit mentioned here, because it breaks wed acceleration on RT3200/E8450. Thanks!
3 Likes
I would create a separate issue at github in the mt76 repo, which then can be closed once it is resolved.
2 Likes
I am not sure if this is a mt76 specific issue. If I remember correctly, mt7915, in addition to the Ethernet-WLAN offload, can also do those offloads from WLAN to Ethernet and WLAN to WLAN, but not in tandem with mt7622. So it may be a specific 7622+7915 issue; maybe it should be treated at OpenWRT code level?
for you to decide. You seem to know more than me there.
Hello, i have a problem.
I've finally recently flashed OpenWRT and everything went fine, but my download connection literally went down alot... and i can't figure out why.
With stock firmware i had a normal 940+Mbps, but now with OpenWRT i have around 160Mbps...
I tried with software offloading and hardware offloading on but nothing changes...
It's a PPPoE with VLAN ID 835 configured by adding a custom .835 after the wan name (every document i found speaks about a "switch" menu that doesn't actually exist in the latest version)
"Apparently" i've fixed it.
I've removed the WAN6 interface (i've found a post on github that is deprecated or something like that and interfere) so now only WAN (pppoe-wan) and a disabled WAN_6 virtual exist and reactivated Software + Hardware flow offloading and seems i'm back at around 930Mbps
After 6 days of continuously using the build with the new mt76 code (patched for wed), the router finally stopped the wifi interface with the same timeout issue (#690). But following the mentioned thread I saw many people actively testing and debugging the issue so I hope we'll have a fix soon 
LE: I will try using the firmware mt7915_wa.bin version 20230315163130 from rany2's mt76 repository.
Over the past week or so I've been getting this error from an RT3200 running snapshot builds, configured as a Dumb AP. Is this something to raise a defect upon? For reference here is the ethtool output from the 4 lan ports on the dumb AP.
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
Speed: Unknown!
Duplex: Unknown! (255)
Port: Twisted Pair
PHYAD: 0
Transceiver: external
Auto-negotiation: on
MDI-X: Unknown
Supports Wake-on: d
Wake-on: d
Link detected: no
Settings for lan2:
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
Speed: Unknown!
Duplex: Unknown! (255)
Port: Twisted Pair
PHYAD: 1
Transceiver: external
Auto-negotiation: on
MDI-X: Unknown
Supports Wake-on: d
Wake-on: d
Link detected: no
Settings for lan3:
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
Speed: Unknown!
Duplex: Unknown! (255)
Port: Twisted Pair
PHYAD: 2
Transceiver: external
Auto-negotiation: on
MDI-X: Unknown
Supports Wake-on: d
Wake-on: d
Link detected: no
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
Link partner advertised pause frame use: No
Link partner advertised auto-negotiation: Yes
Link partner advertised FEC modes: Not reported
Speed: 100Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 3
Transceiver: external
Auto-negotiation: on
MDI-X: Unknown
Supports Wake-on: d
Wake-on: d
Link detected: yes
In the kernel log I get a flood of errors like below, the MAC address being given is a MacBook M1, that has only once been connected to the upstream router which is also an Rt3200 via ethernet, but never directly to this router.
[133263.140087] mt7530-mdio mdio-bus:00: port 2 failed to delete <MACADDRESS> vid 0 from fdb: -2
[133263.149215] mt7530-mdio mdio-bus:00: port 3 failed to delete <MACADDRESS> vid 0 from fdb: -2
[133263.158543] mt7530-mdio mdio-bus:00: port 3 failed to delete <MACADDRESS> vid 0 from fdb: -2
[133263.167676] mt7530-mdio mdio-bus:00: port 4 failed to delete <MACADDRESS> vid 0 from fdb: -2
[133263.177118] mt7530-mdio mdio-bus:00: port 4 failed to delete <MACADDRESS> vid 0 from fdb: -2
Happy to open an issue on GitHub if it's worthwhile and move the discussion there if the expert's think it should be logged.
Hi,
TLDR: What is the reason for part 1, what to do to get stable 22.0.3.5 to run with 802.11s like snapshot image does (part 2)
Part1: I recently wanted to update one of my Belkin RT3200 from running snapshot 22040 to current snapshot to get Wireguard. My setup consists of 3 of these routers in a 802.11s mesh configuration (AX at 5Ghz, 80Mhz channel width) running flawlessly for months. After successful upgrade I could not connect to router over Wifi-connection, but connected with a local ethernet port, connect was possible. I further examined with tcpdump, that only broadcast and multicast traffic passes the bridged lan ports. I disabled the firewall, I set firewall rules to any-any-any-allow, but nothing changed that behaviour. Because of the nature of snapshots (and my humble knowledge of it) I did not have a fallback image to come to the state where I started (snapshot-22040). To get out of this I thougt I could try stable 22.0.3.5. Flashing the sysupgrade-Image (with or without keeping the settings) ends up in 802.11-meshconnection not coming up with the stable image. I tryed to find, why, and as far as I'm not wrong, the difference between snapshot and stable in terms of mesh is the packaging of openssl-libs in snapshot versus wolfssl-libs in stable.
Part2: So to make it happen, I tryed to create a stable image with openssl-lib instead of wolfssl using the openwrt firmware selector page (just replaced the 2 wolf-ssl packages in standard choice to openssl) and tryed to flash this paket. This gives unresponcable device at all (just ethernet connection, no wifi and therefor also no mesh network), so had to go to recovery and restart with the procedure.
I did not describe all my other non-successful attempts, think, that post is long enough, but, if someone wants additional information, I'm willing and able to deliver 
I guess you could compile r22040 to get it up again.
Here's the git hash:
❯ scripts/getver.sh r22040
eeba2a67caa2b9b92ffb9d756089408643971a2e
Running same r22040 with wireguard:
openwrt_SNAPSHOT_r22040-eeba2a67ca-cc9bb1bcdfb0-mediatek-mt7622-linksys_e8450-ubi-squashfs-sysupgrade-22212.itb
Thanks for this. For my understanding: The scripts sets the git-checkout to the appropriate branch and I then have to compile the itb-file by myself? Or is this shellscript useable with auc?
Thanks to you too. I gave it a try (even not considering it to be used in "production"). It gives me the same error as the stable image does (mesh wifi does not start) so here is what (in both cases) the log says:
Tue May 30 19:20:42 2023 daemon.notice netifd: Wireless device 'radio1' is now up
Tue May 30 19:20:44 2023 daemon.info dnsmasq[1]: read /etc/hosts - 12 names
Tue May 30 19:20:44 2023 daemon.info dnsmasq[1]: read /tmp/hosts/dhcp.cfg01411c - 4 names
Tue May 30 19:20:44 2023 daemon.info dnsmasq[1]: read /tmp/hosts/odhcpd - 2 names
Tue May 30 19:20:44 2023 daemon.info dnsmasq-dhcp[1]: read /etc/ethers - 0 addresses
Tue May 30 19:22:44 2023 daemon.notice netifd: radio1 (6901): WARNING: Variable 'data' does not exist or is not an array/object
Tue May 30 19:22:44 2023 daemon.notice netifd: radio1 (6901): Bug: PHY is undefined for device 'radio1'
Tue May 30 19:22:44 2023 daemon.notice netifd: Wireless device 'radio1' is now down
Tue May 30 19:22:45 2023 daemon.err wpa_supplicant[1819]: Line 8: too large mode (value=5 max_value=4)
Tue May 30 19:22:45 2023 daemon.err wpa_supplicant[1819]: Line 8: failed to parse mode '5'.
Tue May 30 19:22:45 2023 daemon.err wpa_supplicant[1819]: Line 9: unknown network field 'mesh_fwding'.
Tue May 30 19:22:45 2023 daemon.err wpa_supplicant[1819]: Line 10: unknown network field 'mesh_rssi_threshold'.
Tue May 30 19:22:45 2023 daemon.err wpa_supplicant[1819]: Line 17: failed to parse network block.
Tue May 30 19:22:45 2023 daemon.err wpa_supplicant[1819]: Failed to read or parse configuration '/var/run/wpa_supplicant-wifi5g-mesh.conf'.
Tue May 30 19:22:45 2023 daemon.notice wpa_supplicant[1819]: : CTRL-EVENT-DSCP-POLICY clear_all
Tue May 30 19:22:45 2023 daemon.notice netifd: radio1 (6923): Command failed: ubus call wpa_supplicant config_add { "driver": "nl80211", "ctrl": "/var/run/wpa_supplicant", "iface": "wifi5g-mesh", "config": "/var/run/wpa_supplicant-wifi5g-mesh.conf" } (Invalid argument)
Tue May 30 19:22:45 2023 daemon.notice netifd: radio1 (6923): Usage: ubus [<options>] <command> [arguments...]
Tue May 30 19:22:45 2023 daemon.notice netifd: radio1 (6923): Options:
Tue May 30 19:22:45 2023 daemon.notice netifd: radio1 (6923): -s <socket>: Set the unix domain socket to connect to
Tue May 30 19:22:45 2023 daemon.notice netifd: radio1 (6923): -t <timeout>: Set the timeout (in seconds) for a command to complete
Tue May 30 19:22:45 2023 daemon.notice netifd: radio1 (6923): -S: Use simplified output (for scripts)
Tue May 30 19:22:45 2023 daemon.notice netifd: radio1 (6923): -v: More verbose output
Tue May 30 19:22:45 2023 daemon.notice netifd: radio1 (6923): -m <type>: (for monitor): include a specific message type
Tue May 30 19:22:45 2023 daemon.notice netifd: radio1 (6923): (can be used more than once)
Tue May 30 19:22:45 2023 daemon.notice netifd: radio1 (6923): -M <r|t> (for monitor): only capture received or transmitted traffic
Tue May 30 19:22:45 2023 daemon.notice netifd: radio1 (6923):
Tue May 30 19:22:45 2023 daemon.notice netifd: radio1 (6923): Commands:
Tue May 30 19:22:45 2023 daemon.notice netifd: radio1 (6923): - list [<path>] List objects
Tue May 30 19:22:45 2023 daemon.notice netifd: radio1 (6923): - call <path> <method> [<message>] Call an object method
Tue May 30 19:22:45 2023 daemon.notice netifd: radio1 (6923): - subscribe <path> [<path>...] Subscribe to object(s) notifications
Tue May 30 19:22:45 2023 daemon.notice netifd: radio1 (6923): - listen [<path>...] Listen for events
Tue May 30 19:22:45 2023 daemon.notice netifd: radio1 (6923): - send <type> [<message>] Send an event
Tue May 30 19:22:45 2023 daemon.notice netifd: radio1 (6923): - wait_for <object> [<object>...] Wait for multiple objects to appear on ubus
Tue May 30 19:22:45 2023 daemon.notice netifd: radio1 (6923): - monitor Monitor ubus traffic
Tue May 30 19:22:45 2023 daemon.notice netifd: radio1 (6923):
Tue May 30 19:22:45 2023 daemon.notice netifd: radio1 (6923): Interface 0 setup failed: WPA_SUPPLICANT_FAILED
Tue May 30 19:22:45 2023 daemon.notice netifd: radio1 (6923): Failed to parse json data: unexpected end of data
Tue May 30 19:22:45 2023 daemon.notice netifd: radio1 (6923): WARNING (wireless_add_process): executable path /usr/sbin/wpad does not match process path (/proc/exe)
Tue May 30 19:22:45 2023 daemon.notice netifd: radio1 (6923): Command failed: ubus call network.wireless notify { "command": 2, "device": "radio1", "data": { "pid": 0, "exe": "\/usr\/sbin\/wpad", "required": true, "keep": true } } (Invalid argument)
Tue May 30 19:22:45 2023 daemon.notice netifd: radio1 (6923): Usage: ubus [<options>] <command> [arguments...]
Tue May 30 19:22:45 2023 daemon.notice netifd: radio1 (6923): Options:
Tue May 30 19:22:45 2023 daemon.notice netifd: radio1 (6923): -s <socket>: Set the unix domain socket to connect to
Tue May 30 19:22:45 2023 daemon.notice netifd: radio1 (6923): -t <timeout>: Set the timeout (in seconds) for a command to complete
Tue May 30 19:22:45 2023 daemon.notice netifd: radio1 (6923): -S: Use simplified output (for scripts)
Tue May 30 19:22:45 2023 daemon.notice netifd: radio1 (6923): -v: More verbose output
Tue May 30 19:22:45 2023 daemon.notice netifd: radio1 (6923): -m <type>: (for monitor): include a specific message type
Tue May 30 19:22:45 2023 daemon.notice netifd: radio1 (6923): (can be used more than once)
Tue May 30 19:22:45 2023 daemon.notice netifd: radio1 (6923): -M <r|t> (for monitor): only capture received or transmitted traffic
Tue May 30 19:22:45 2023 daemon.notice netifd: radio1 (6923):
Tue May 30 19:22:45 2023 daemon.notice netifd: radio1 (6923): Commands:
Tue May 30 19:22:45 2023 daemon.notice netifd: radio1 (6923): - list [<path>] List objects
Tue May 30 19:22:45 2023 daemon.notice netifd: radio1 (6923): - call <path> <method> [<message>] Call an object method
Tue May 30 19:22:45 2023 daemon.notice netifd: radio1 (6923): - subscribe <path> [<path>...] Subscribe to object(s) notifications
Tue May 30 19:22:45 2023 daemon.notice netifd: radio1 (6923): - listen [<path>...] Listen for events
Tue May 30 19:22:45 2023 daemon.notice netifd: radio1 (6923): - send <type> [<message>] Send an event
Tue May 30 19:22:45 2023 daemon.notice netifd: radio1 (6923): - wait_for <object> [<object>...] Wait for multiple objects to appear on ubus
Tue May 30 19:22:45 2023 daemon.notice netifd: radio1 (6923): - monitor Monitor ubus traffic
Tue May 30 19:22:45 2023 daemon.notice netifd: radio1 (6923):
Tue May 30 19:22:45 2023 daemon.notice netifd: radio1 (6923): command failed: Link has been severed (-67)
Tue May 30 19:22:45 2023 daemon.notice netifd: radio1 (6923): command failed: Link has been severed (-67)
Tue May 30 19:22:45 2023 daemon.notice netifd: Wireless device 'radio1' is now up
Tue May 30 19:22:45 2023 kern.info kernel: [ 940.885430] br-lan: port 6(wifi5g-mesh) entered blocking state
Tue May 30 19:22:45 2023 kern.info kernel: [ 940.891277] br-lan: port 6(wifi5g-mesh) entered disabled state
Tue May 30 19:22:45 2023 kern.info kernel: [ 940.897404] device wifi5g-mesh entered promiscuous mode
Tue May 30 19:22:46 2023 daemon.info dnsmasq[1]: read /etc/hosts - 12 names
Tue May 30 19:22:46 2023 daemon.info dnsmasq[1]: read /tmp/hosts/dhcp.cfg01411c - 4 names
Tue May 30 19:22:46 2023 daemon.info dnsmasq[1]: read /tmp/hosts/odhcpd - 2 names
Tue May 30 19:22:46 2023 daemon.info dnsmasq-dhcp[1]: read /etc/ethers - 0 addresses
Mode value 5 seem to correlate with Mesh security setting wpa3-SAE (which is, as far as the web interface is showing with colors) the only possible setting for 802.11s mesh wifi security. Any thoughts? My config is as follows:
root@belkin-owrt-eg2:~# cat /etc/config/wireless
config wifi-device 'radio0'
option type 'mac80211'
option path 'platform/18000000.wmac'
option channel '1'
option band '2g'
option htmode 'HT20'
option disabled '1'
config wifi-device 'radio1'
option type 'mac80211'
option path '1a143000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0'
option band '5g'
option htmode 'HE80'
option cell_density '0'
option channel '116'
option country 'DE'
config wifi-iface 'wifinet0'
option device 'radio1'
option mode 'mesh'
option encryption 'sae'
option mesh_id 'xxxxxx-meshnet'
option mesh_fwding '1'
option mesh_rssi_threshold '0'
option key 'xxxxxxxxxxx'
option ifname 'wifi5g-mesh'
option network 'lan wan'
root@belkin-owrt-eg2:~# cat /etc/config/network
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 'fdc6:743d:8ac4::/48'
config device
option name 'br-lan'
option type 'bridge'
list ports 'lan1'
list ports 'lan2'
list ports 'lan3'
list ports 'lan4'
list ports 'wan'
config interface 'lan'
option device 'br-lan'
option proto 'static'
option netmask '255.255.255.0'
option ip6assign '60'
option ipaddr '192.168.100.3'
option gateway '192.168.100.1'
option broadcast '192.168.100.255'
list dns '192.168.100.2'
list dns '192.168.100.1'
list dns_search 'xxxx.yyy'
config interface 'wan'
option device 'wan'
option proto 'dhcp'
option type 'bridge'
config interface 'wan6'
option device 'wan'
option proto 'dhcpv6'
option type 'bridge'
root@belkin-owrt-eg2:~# cat /tmp/run/wpa_supplicant-wifi5g-mesh.conf
country=DE
network={
ssid="Zuhause-meshnet"
key_mgmt=SAE
mode=5
mesh_fwding=1
mesh_rssi_threshold=0
fixed_freq=1
frequency=5580
ht40=1
max_oper_chwidth=1
sae_password="xxxxxxxxxxxxxxxxxxxxxx"
beacon_int=100
}
Edit: checked the packages your version of snapshot 22040 uses:
# opkg list-installed |grep wpad
wpad-basic-mbedtls - 2022-07-29-b704dc72-17.2
# opkg list-installed |grep libus
libustream-mbedtls20201210 - 2022-12-08-9217ab46-2
whereas my working snapshot 22040 has
# opkg list-installed |grep wpad
wpad-openssl - 2022-07-29-b704dc72-17.2
# opkg list-installed |grep libus
libustream-openssl20201210 - 2022-12-08-9217ab46-2
That script was just to go from the DISTRIB_REVISION r22040 to a git commit hash.
To build from that you should be able to just check it out with
git checkout eeba2a67caa2b9b92ffb9d756089408643971a2e
solved!
@rickmv's image gave me the right kick: package wpad-openssl instead of wpad-mesh-openssl has to be used when creating a custom stable image from openwrt firmware selector, that have working mesh wifi. there is, anyway, still a cosmetic error (old image gave me the meshed devices and there connection details in system overview and also wifi connection details view), but that's not a game stopper.
thanks all until here
1 Like
Mediatek wpad package is wpad-basic-mbedtls. Remove this and add wpad-mbedtls when building your image, instead of wpad-openssl.
hi rickmv,
the customization tool at https://firmware-selector.openwrt.org/?version=22.03.5&target=mediatek%2Fmt7622&id=linksys_e8450-ubi says: "Unsupported package(s): wpad-mbedtls", whyever
That's because wpad-mbedtls is not supported in the 22.03 release. Only in main branch and development snapshots, and also in the upcoming (but not yet released) OpenWrt 23.05.
1 Like