I am now running 23.05-snapshot on my E8450 to get the hostapd SAE H2E security patch, kernel 5.15.164 and the mac80211 speed bugfix. The measured iperf3 WiFi TCP performance on 2.4 and 5 GHz is about the same as on 23.05.4 for my configuration.
Another way that the WiFi speed display bug on Netgear WAX202 manifests itself:
Poco X4 Pro 5G is a WiFi5 device with a single antenna. It just cannot physically go above 433 Mbps. Probably, some confusion of which line belongs to which client is happening.
This should be a different issue. Could you verify this on command line?
iwinfo
iwinfo phy1-ap0 assoclist
This should give you your configured virtual access points and for your phy1-ap0 the same current connection speed information for each station identified by the MAC address.
I moved the phone to phy1-ap1 to check if the problem is related to the fact that both the STA interface and phy1-ap0 have the same SSID. It didn't help.
The bug is still reproducible from time to time (not always) on the command line:
FC:02:96:1C:80:74 -43 dBm / -92 dBm (SNR 49) 0 ms ago
RX: 960.7 MBit/s, HE-MCS 9, 80MHz, HE-NSS 2, HE-GI 0, HE-DCM 0 2085 Pkts.
TX: 433.3 MBit/s, VHT-MCS 9, 80MHz, VHT-NSS 1 619 Pkts.
expected throughput: unknown
I also tried to reproduce it with iw dev phy1-ap1 station dump | grep -E 'Station|bitrate'. This also succeeded after many iterations:
Station fc:02:96:1c:80:74 (on phy1-ap1)
tx bitrate: 433.3 MBit/s VHT-MCS 9 80MHz short GI VHT-NSS 1
rx bitrate: 960.7 MBit/s 80MHz HE-MCS 9 HE-NSS 2 HE-GI 0 HE-DCM 0
Yes, this looks like a bug to me, too. I can't imagine that transmission side of a station would operate in 11ac VHT mode while at the same time the receive side would be in 11ax HE mode. I only saw one connection mode for one station at a time, with different MCS connection speeds but not different WiFi generation modes like 11n, 11ac or 11ax at a time.
I still think is may be another bug unrelated to the mac80211 speed issue. But you could verify this with running 23.05-snapshot. The last commits in 23.05-branch include a mac80211 version update, kernel update and the mac80211 dual stream bugfix.
Netgear WAX202 is ramips MT7621. If this is related to the mac80211 issue then we at least know that this SoC series may be affected.
I tried requesting the snapshot with auc, unsuccessfully:
root@Netgear:~# auc -B 23.05-SNAPSHOT
auc/0.3.2-1
Server: https://sysupgrade.openwrt.org
Running: 23.05.4 r24012-d8dd03c46f on ramips/mt7621 (netgear,wax202)
Available: 23.05-SNAPSHOT r24024-e4625c37c4
Requesting package lists...
<snip>
Are you sure you want to continue the upgrade process? [N/y] y
Requesting build..........Current Target: "ramips/mt7621"
Current Architecture: "mipsel"
Current Revision: "r24025-c241885687"
Default Packages: base-files ca-bundle dropbear fstools libc libgcc libustream-mbedtls logd mtd netifd opkg uci uclient-fetch urandom-seed urngd busybox procd procd-ujail procd-seccomp kmod-leds-gpio kmod-gpio-button-hotplug wpad-basic-mbedtls uboot-envtools dnsmasq firewall4 nftables kmod-nft-offload odhcp6c odhcpd-ipv6only ppp ppp-mod-pppoe
Available Profiles:
<snip>
Error: Received incorrect version r24025-c241885687 (requested r24024-e4625c37c4)
Bad message (77)
And this seems to be cached, and the same error (requesting r24024-e4625c37c4, getting r24025-c241885687) persists. Could someone please clear the cache?
For a similar reason (cached error), yesterday I could not downgrade this router via auc to 23.05.3 either:
Collected errors:
* opkg_download: Failed to download https://downloads.openwrt.org/releases/23.05.3/packages/mipsel_24kc/luci/luci-mod-admin-full_git-19.253.48496-3f93650_all.ipk, wget returned 4.
* opkg_download: Check your network settings and connectivity.
* opkg_install_pkg: Failed to download luci-mod-admin-full. Perhaps you need to run 'opkg update'?
* opkg_install_cmd: Cannot install package luci-ssl.
* opkg_install_pkg: Checksum or size mismatch for package luci-mod-admin-full. Either the opkg or the package index are corrupt. Try 'opkg update'.
* opkg_install_cmd: Cannot install package luci-mod-admin-full.
make[2]: *** [Makefile:189: package_install] Error 255
make[1]: *** [Makefile:144: _call_image] Error 2
make: *** [Makefile:262: image] Error 2
Error: Error while building firmware. See stdout/stderr
Bad message (77)
Today building the 23.05.3 image succeeded, and the router has been downgraded.
Hello!
I'm curious to know when we can expect the release candidate for OpenWrt version 24.x? Is there any information available on the timeline or release plans?
Thank you in advance for your response!
http://lists.openwrt.org/pipermail/openwrt-devel/2024-August/043087.html
"Looking at the status of OpenWrt main branch we will probably branch in
the next 2 months."
3 Likes
I tested the 23.05-SNAPSHOT version (specifically, OpenWrt 23.05-SNAPSHOT r24026-6fadcee50b / LuCI openwrt-23.05 branch git-24.212.79335-cdbe903) by using web-based attended sysupgrade and hacking the select field value.
The "6.0 Mbit/s" display bug (possibly a consequence of some power-saving mode not enabled previously) is still there.
The "impossible 960 Mbps rate on a WiFi5 device" bug can no longer be reproduced.
I also have a speed problem on a wired client connected to the repeater:
For comparison, here is what I get when the repeater runs 23.05.3:
Note that no 2.4 GHz transmission is involved at all in any of the above tests. The main router (Linksys E8450) runs OpenWrt 23.05.4.
Sorry to hear that you had issues. My BTHH5a is working well with OpenWrt 23.05.3.
-Gamma
How were you able to get 23.05.4? I have an Archer C7 v4 as well, but the Table of Hardware and product page both show 23.05.3 as the latest version for all Archer C7 versions (https://openwrt.org/toh/tp-link/archer_c7).
The ToH is generally updated manually, and with thousands of entries can lag behind.
Get 23.05.4 from https://firmware-selector.openwrt.org/?version=23.05.4&target=ath79%2Fgeneric&id=tplink_archer-c7-v4
or https://downloads.openwrt.org/releases/23.05.4/targets/ath79/generic/openwrt-23.05.4-ath79-generic-tplink_archer-c7-v4-squashfs-sysupgrade.bin
1 Like
Hi All,
Having issues with Raspberry pi 4 with version Openwrt 23.05.4, after installing bcp38,ban ip,Dns-http-proxy,squid now cannot access to luci login page and internet cannot connect. Cannot update packages no permission to update.
Hi folks,
just upgraded r7800 to 23.05.4 and my HP_LaserJet_MFP_M227fdw stopped connecting to wifi. Cable connection works fine. That's what I see in the openwrt logs:
Sat Aug 17 14:13:47 2024 daemon.info dnsmasq-dhcp[1]: DHCPDISCOVER(br-lan) 5c:ea:1d:bb:e0:d4
Sat Aug 17 14:13:47 2024 daemon.info dnsmasq-dhcp[1]: DHCPOFFER(br-lan) 192.168.1.172 5c:ea:1d:bb:e0:d4
Sat Aug 17 14:13:51 2024 daemon.info dnsmasq-dhcp[1]: BOOTP(br-lan) 5c:ea:1d:bb:e0:d4 no address configured
Please give me a hint if this can be somehow fixed via openwrt and/or printer settings.
Thanks!
I always set printers to a static ip and add a dns record for the printer. Printers often have very old network stacks.
FYI
2 Likes
I had no issues before upgrading to 23.05.4 so I wonder if some bug could be introduced?
Based on your logs, if 5c:ea:1d:bb:e0:d4 is the printer's wireless MAC address, some traffic is being passed.
If you can install tcpdump on your router capturing the DHCP attempt with this may shed some light on what's going on:
tcpdump -v -ni br-lan ether host 5c:ea:1d:bb:e0:d4
Also, any messages from either hostapd (in the system logs) or the wireless driver (in the kernel logs) at the time the printer is switched on?
1 Like
When I switch printer on I see the following in the system log:
Tue Aug 20 10:37:46 2024 daemon.info hostapd: phy1-ap0: STA 5c:ea:1d:bb:e0:d4 IEEE 802.11: authenticated
Tue Aug 20 10:37:46 2024 daemon.info hostapd: phy1-ap0: STA 5c:ea:1d:bb:e0:d4 IEEE 802.11: associated (aid 1)
Tue Aug 20 10:37:48 2024 daemon.notice hostapd: phy1-ap0: AP-STA-CONNECTED 5c:ea:1d:bb:e0:d4 auth_alg=open
Tue Aug 20 10:37:48 2024 daemon.info hostapd: phy1-ap0: STA 5c:ea:1d:bb:e0:d4 WPA: pairwise key handshake completed (RSN)
Tue Aug 20 10:37:48 2024 daemon.notice hostapd: phy1-ap0: EAPOL-4WAY-HS-COMPLETED 5c:ea:1d:bb:e0:d4
Tue Aug 20 10:38:01 2024 daemon.info dnsmasq-dhcp[1]: DHCPDISCOVER(br-lan) 5c:ea:1d:bb:e0:d4
Tue Aug 20 10:38:01 2024 daemon.info dnsmasq-dhcp[1]: DHCPOFFER(br-lan) 192.168.1.172 5c:ea:1d:bb:e0:d4
Tue Aug 20 10:38:01 2024 daemon.info dnsmasq-dhcp[1]: DHCPDISCOVER(br-lan) 5c:ea:1d:bb:e0:d4
Tue Aug 20 10:38:01 2024 daemon.info dnsmasq-dhcp[1]: DHCPOFFER(br-lan) 192.168.1.172 5c:ea:1d:bb:e0:d4
Tue Aug 20 10:38:05 2024 daemon.info dnsmasq-dhcp[1]: DHCPDISCOVER(br-lan) 5c:ea:1d:bb:e0:d4
Tue Aug 20 10:38:05 2024 daemon.info dnsmasq-dhcp[1]: DHCPOFFER(br-lan) 192.168.1.172 5c:ea:1d:bb:e0:d4
Tue Aug 20 10:38:14 2024 daemon.info dnsmasq-dhcp[1]: DHCPDISCOVER(br-lan) 5c:ea:1d:bb:e0:d4
Tue Aug 20 10:38:14 2024 daemon.info dnsmasq-dhcp[1]: DHCPOFFER(br-lan) 192.168.1.172 5c:ea:1d:bb:e0:d4
Tue Aug 20 10:38:16 2024 daemon.info dnsmasq-dhcp[1]: BOOTP(br-lan) 5c:ea:1d:bb:e0:d4 no address configured
Tue Aug 20 10:38:20 2024 daemon.info dnsmasq-dhcp[1]: BOOTP(br-lan) 5c:ea:1d:bb:e0:d4 no address configured
Tue Aug 20 10:38:24 2024 daemon.info dnsmasq-dhcp[1]: BOOTP(br-lan) 5c:ea:1d:bb:e0:d4 no address configured
Tue Aug 20 10:38:35 2024 daemon.info dnsmasq-dhcp[1]: BOOTP(br-lan) 5c:ea:1d:bb:e0:d4 no address configured
Tue Aug 20 10:38:49 2024 daemon.info dnsmasq-dhcp[1]: DHCPDISCOVER(br-lan) 5c:ea:1d:bb:e0:d4
Tue Aug 20 10:38:49 2024 daemon.info dnsmasq-dhcp[1]: DHCPOFFER(br-lan) 192.168.1.172 5c:ea:1d:bb:e0:d4
Tue Aug 20 10:38:51 2024 daemon.info dnsmasq-dhcp[1]: DHCPDISCOVER(br-lan) 5c:ea:1d:bb:e0:d4
Tue Aug 20 10:38:51 2024 daemon.info dnsmasq-dhcp[1]: DHCPOFFER(br-lan) 192.168.1.172 5c:ea:1d:bb:e0:d4
and here is the tail of the kernel log:
[703407.749866] ath10k_pci 0001:01:00.0: mac flush vdev 0 drop 0 queues 0x1 ar->paused: 0x0 arvif->paused: 0x0
[751796.622006] ath10k_pci 0001:01:00.0: mac flush vdev 0 drop 0 queues 0x1 ar->paused: 0x0 arvif->paused: 0x0
[763775.805598] ath10k_pci 0001:01:00.0: mac flush vdev 0 drop 0 queues 0x1 ar->paused: 0x0 arvif->paused: 0x0
[783142.641825] ath10k_pci 0000:01:00.0: mac flush vdev 0 drop 0 queues 0x1 ar->paused: 0x0 arvif->paused: 0x0
[783170.281806] ath10k_pci 0000:01:00.0: mac flush vdev 0 drop 0 queues 0x1 ar->paused: 0x0 arvif->paused: 0x0
[803501.007962] ath10k_pci 0000:01:00.0: mac flush vdev 0 drop 0 queues 0x1 ar->paused: 0x0 arvif->paused: 0x0
[815243.157485] ath10k_pci 0001:01:00.0: mac flush vdev 0 drop 0 queues 0x1 ar->paused: 0x0 arvif->paused: 0x0
Thank you for the hint with tcpdump. I'll try to install it and will follow up.
Thanks!
Here is tcpdump log: https://pastebin.com/k6sWJ3Hw I don't see anything suspicious in this log and will very much appreciate any hint what can be wrong. Thanks!