[23.05-SNAPSHOT] filogic: WPA2+WPA3 Unable to connect periodically #13156
Comments
|
What is in your /etc/config/wireless (minus passwords and AP names) |
|
|
FWIW, on the device, it reports the PSK is wrong. Restarting the AP works without changing the PSK on the device. |
|
That is a big hint as to what's wrong. I was running a snapshot build recently that caused similar behavior for my iPhone with regular AP mode where after a while it was reporting wrong password. @stintel pointed out this is a hostapd issue. |
|
Try setting up 2 access points w same name and pass in place of one mixed AP - one with WPA2-PSK (AES and optional w-protection to match interop minimum security), other with WPA3-SAE, it is more interop that way. |
ynezz
changed the title
ynezz
added
target/mediatek
|
@soxrok2212 recompile images with
That is probably not that correct and might be misleading, IIRC then he is using snapshots and was pointing fingers at cd804c1 ( |
Correct. Haven't had time to debug that further and probably won't have anytime soon. I have a small co-working space at home and someone is working here for the rest of the month. |
Will do. Seems a pretty good trigger is to make a change on a VAP or sometimes even just restarting the radio. I'm unsure if this is related at all, but I see this in the logs when simply restarting a radio. Seems related to 6603748
Are you positive? Looks like it made it into 23.05-rc2 5 days ago. I'm on the |
Is wpad-full-openssl the same thing as wpad-openssl? I found the openwrt wiki The description of them on the wiki is very bad. I've been manually selecting to wpad-openssl and compiling, and it was working fine until June 3. After I waited until July 9 for mt76 to do a big update, I also started a big update (I did re-pull the source code), and then the wireless key errors and disconnected wireless connection issues started happening more often! I also do use wpa2-psk/wpa3-sae encryption. In the past few days, I have had tests come out that it wasn't the mt76 that was causing the wireless issues(?). At least rolling back to an older dated package didn't fix the problem. |
|
@ynezz with |
ynezz
changed the title
Ok, thanks for clearing this out, but then you're not using
perhaps you've missed the enable debug logging part?
Ok, then we're probably looking at the wrong place (hostapd) and should focus on that mt76 updates? Which update broke it, 01885bc ? |
Yep, that's correct, my mistake.
I totally missed that. Will report back. |
|
@ynezz I can confirm this bug can be triggered by simply toggling the radio on/off (maybe a few times). Looks like only the 1st message in the handshake is sent before it times out. |
Does |
|
Looks like that commit is the culprit. I can't seem to trigger the bug any more. |
@PolynomialDivision @dhewg FYI this is about 8d7d9aa (backport of cd804c1) |
|
I just tested on latest master with latest hostapd, and I can not reproduce it: Let's see if I can reproduce it on 23.05. Update: I have no issues. |
Did a quick test and my phone doesn't seem to be disconnecting with this. Can you open a PR? |
Nope, instead it would not be mt76 as I just have tested it ... |
Scratch that. Started happening again. I propose we revert the bump that causes the problem until someone can fix it properly? |
|
Scratch that. Started happening again. I propose we revert the bump that causes the problem until someone can fix it properly?
The bump is question fixes a regression from the previous bump, we would merely shift the affected audience :/
I could bisect the hostapd commit required to fix the issue I ran into, to then cherry-pick that to the earlier version. But I guess it makes more sense to find the problematic commit for hostapd master?
|
FYI, on my side I discovered that this issue occurs when the STA devices are switching from a 2.4G wifi connection to a 5G wifi connection. I can reproduce the issue by rebooting the AP. Then all STA devices connect to 2.4G wifi N. And then, when the 5G wifi is available ( approx 1 min after due to DFS) some devices try to switch to 5G wifi AC/AX and boom ! wifi password required on STA devices. |
Would be interesting to know how you would do that. We can't really use CONFIG_SRC_TREE_OVERRIDE afaik because of all our patches ... |
|
I guess we could revert it until it is fixed in master? Can someone put also the issue to the hostap mailinglist? |
Usually I'd |
Commit e978072baaca ("Do prune_association only after the STA is
authorized") causes issues when an STA roams from one interface to
another interface on the same PHY. The mt7915 driver is not able to
handle this properly. While the commits fixes a DoS, there are other
devices and drivers with the same limitation, so revert to the orginal
behavior for now, until we have a better solution in place.
Fixes: #13156
Signed-off-by: Stijn Tintel <stijn@linux-ipv6.be>
(cherry picked from commit 3246739)
Tested today with latest OpenWrt SNAPSHOT r23769-324673914d / LuCI Master git-23.223.85458-f7583b6 on Banana-pi BPI-R3 and the issue is still there |
|
Issue still present on avm_fritzbox-4040 ipq40xx/generic - tested just now with snapshots r23782-ac68fbf526 and 23.05-SNAPSHOT r23389-5deed175a5 I thought this Fritzbox had a sudden wifi-death the other day until I found this GH issue. Was about to take a marker and write "broken" on it :) Happends both with Open and OWE / Enhanced Open, I'm not even using WPA2/WPA3 here. |
|
@soxrok2212 Can this issue be reopen as the issue does not seem solved ? Or do we need to open a new one ? |
My quick test showed that this was probably fixed in 23.05.0-rc3. |
|
I am running the latest SNAPSHOT (not 23.05 snapshot) with the hostapd revert, issue seems to have come back. |
|
I unfortunately can not re-open. Ping @hauke |
|
Are we sure we're not confusing two different issues here? |
|
I believe it's the same. I checked logs, its looping over message 1 in the 4-way handshake, just like it was originally. Rebooting the AP (or restarting just wifi a few times) does the trick. A few others have reported its still not working as well, and one on ipq4xxx so its not localized to MT76. |
|
Being I'm the only one who reported this issue on the IPQ4xxx platform is there and debugging or as such that may help? |
|
Weird. I was having this issue so I applied 3246739 and flashed my own build to fix. Works great now. I'm guessing someone else broke it. |
|
So maybe I experienced a different issue. It's definitely fixed for me. I'll reopen this one and someone still experiencing it shall have to bisect. |
|
Last night I disabled my 5ghz radio to ensure devices don’t flip between bands. Haven’t had any problems since then, so yeah seems like this still exists. |
Commit e978072baaca ("Do prune_association only after the STA is
authorized") causes issues when an STA roams from one interface to
another interface on the same PHY. The mt7915 driver is not able to
handle this properly. While the commits fixes a DoS, there are other
devices and drivers with the same limitation, so revert to the orginal
behavior for now, until we have a better solution in place.
Fixes: openwrt#13156
Signed-off-by: Stijn Tintel <stijn@linux-ipv6.be>
Did you file a separate bug report on this? That sounds like an issue unrelated to the one being discussed here (merits its own bug report), but the behavior of "passes traffic for 10 seconds then timesout with authentication failure" (when it clearly did auth properly since it passed traffic) sounds like #12634 is affecting AP mode in addition to client mode. If you can confirm you're seeing behavior in AP mode similar to my client mode issues, maybe drop a note on my issue and I'll amend the title/description. In general, I'm questioning why hostapd has been updated to pull in random git commits that are yet to be released upstream. All of the multilink stuff seems to have introduced a variety of regressions in link state handling with non-MLO systems. I haven't figured out HOW, but somehow on a Raspberry Pi, the hostapd updates cause the wifi driver to stop properly reporting link state handling up from the kernel. I cannot yet figure out HOW hostapd is causing the driver to do weird things as far as reporting link state. Maintaining a series of reverts is getting harder and harder as more patches are dropped on top of the broken update in 304423a - as others have mentioned, OpenWRT's pile of patches on top of hostapd makes it REALLY hard to bisect upstream to find the exact commit that caused a regression. |
My apologies - this Fritzbox indeed has its wifi hardware broken, apparantly. Works fine with a different device of the same model. |
So this means it again may be specific to MT76 |
Yesterday I downloaded the latest snapshot and the issue was still there. |
|
This used to affect my setup, but after bumping to a build from HEAD ~a week ago I've had no problems since. |
|
Recent patched fixed my problem also. |
Commit e978072 ("Do prune_association only after the STA is authorized") causes issues when an STA roams from one interface to another interface on the same PHY. The mt7915 driver is not able to handle this properly. While the commits fixes a DoS, there are other devices and drivers with the same limitation, so revert to the orginal behavior for now, until we have a better solution in place. Ref: openwrt/openwrt#13156 Signed-off-by: Stijn Tintel <stijn@linux-ipv6.be>
Commit e978072 ("Do prune_association only after the STA is authorized") causes issues when an STA roams from one interface to another interface on the same PHY. The mt7915 driver is not able to handle this properly. While the commits fixes a DoS, there are other devices and drivers with the same limitation, so revert to the orginal behavior for now, until we have a better solution in place. Ref: openwrt/openwrt#13156 Signed-off-by: Stijn Tintel <stijn@linux-ipv6.be>
Commit e978072 ("Do prune_association only after the STA is authorized") causes issues when an STA roams from one interface to another interface on the same PHY. The mt7915 driver is not able to handle this properly. While the commits fixes a DoS, there are other devices and drivers with the same limitation, so revert to the orginal behavior for now, until we have a better solution in place. Ref: openwrt/openwrt#13156 Signed-off-by: Stijn Tintel <stijn@linux-ipv6.be>
Commit e978072 ("Do prune_association only after the STA is authorized") causes issues when an STA roams from one interface to another interface on the same PHY. The mt7915 driver is not able to handle this properly. While the commits fixes a DoS, there are other devices and drivers with the same limitation, so revert to the orginal behavior for now, until we have a better solution in place. Ref: openwrt/openwrt#13156 Signed-off-by: Stijn Tintel <stijn@linux-ipv6.be>
Commit e978072 ("Do prune_association only after the STA is authorized") causes issues when an STA roams from one interface to another interface on the same PHY. The mt7915 driver is not able to handle this properly. While the commits fixes a DoS, there are other devices and drivers with the same limitation, so revert to the orginal behavior for now, until we have a better solution in place. Ref: openwrt/openwrt#13156 Signed-off-by: Stijn Tintel <stijn@linux-ipv6.be>
Commit e978072 ("Do prune_association only after the STA is authorized") causes issues when an STA roams from one interface to another interface on the same PHY. The mt7915 driver is not able to handle this properly. While the commits fixes a DoS, there are other devices and drivers with the same limitation, so revert to the orginal behavior for now, until we have a better solution in place. Ref: openwrt/openwrt#13156 Signed-off-by: Stijn Tintel <stijn@linux-ipv6.be>
Describe the bug
Running recent builds, I'm sometimes unable to connect with WPA2+WPA3. On 22.03 snapshots, this was never an issue. Resolving requires restarting the radios on the AP. Tested with wpad-mesh-openssl and wpad-mesh-mbedtls on MT76 XDR-6086. Looks like a loop of this:
Mostly has been seen on iPhone with iOS 16 and MacBook with 13.4.1. Haven't verified with other devices as sometimes others can connect without issue while one fails to connect.
OpenWrt version
r23290-339e71cbd3
OpenWrt target/subtarget
mediatek/filogic
Device
TP-Link TL-XDR6086
Image kind
Self-built image
Steps to reproduce
Toggle the radio on/off a few times.
Actual behaviour
Clients cannot authenticate with the AP.
Expected behaviour
Clients connect to the AP without issue.
Additional info
No response
Diffconfig
Terms
The text was updated successfully, but these errors were encountered: