When you see these logs in your router, do you know if the device connected to that LAN port is down or up?
AFAIK E8450 do not bring down any ports. It only senses whether the other end connected to its port is up or down. When it boots, OpenWrt will bring up all ports as configured by user. After that it doesn't actively managed the ports.
Do you see any weird behaviour (e.g. no traffic flowing) for your router?
I can also confirm that latest master builds are causing the wireless interfaces to become inaccessible after a while. Sometimes very soon after updating the firmware, but sometimes after several days of continuous working without issues. The device is used as a classic router (PPPoE WAN connection) but I am using only wireless devices so I enabled WED. After the latest event I was able to connect to the Ethernet interface and downloaded the log:
Latest messages are during my Ethernet connection for debugging the router, but I left them to see the subsequent timeouts.
I also remember that I've tested a more recent mt76 build than the one used until yesterday by openwrt and noticed that WED was not active. I saw now that they recently updated the mt76 build, will test soon.
Well, my E8450 is happily purring away for more than 10 days now. I've setup a cronjob to detect issues and force a kernel panic so that I can capture the kernel logs. Will know if mine is the same as yours once I get my hands on the logs.
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
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:
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!
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?
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.
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
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: