On Sun, Jan 21, 2024 at 09:20:42PM +0100, Johannes Berg wrote: > On Sun, 2024-01-21 at 12:29 +0200, Jouni Malinen wrote: > > In fact, I was even > > able to test this with mac80211_hwsim by disabling the kernel side > > association comeback mechanism. > > I suppose we could even make some kind of parameter from hwsim towards > mac80211 to disable using it, if you wanted to be able to test this > further? Perhaps hidden behind a Kconfig option, though in this case I > wouldn't even really be worried about code size/etc. since it's really > not a hot path in the first place. It was actually easy to do this in hostapd/wpa_supplicant by having them use a different Timeout Interval Type field value in the Timeout Interval element as testing functionality since that was all that it took to "disable" the functionality in mac80211.. In other words, I already added a fully automated this for this without needing kernel changes. > I also have in the back of my mind to add a kind of strict mode to > mac80211, where we would remove workarounds for various broken APs like > the one we'll probably put in for the CSA thing ... Or checking more > strictly channel configuration from beacon vs. assoc response, etc. That would likely be useful for various testing needs.. > I'm thinking of making that a parameter that comes from the driver to > the stack, so that it'd be possible to run tests with some hwsim radios > configured one way and some another way, or really more pragmatically so > we could do different tests in different ways without having to > reconfigure "everything" (just a new hwsim radio that changes the > settings here would be sufficient for the hwsim case). This would kind > of fit in a similar fashion? This would also be useful for the mac80211_hwsim tests in hostap.git. > Though actually if we have comeback mechanism in userspace, maybe more > generally we want to be able to disable the kernel mechanism, opt-in by > an assoc-request flag? Yes, I started to think about something like this after realizing how simple it was to make this work in wpa_supplicant. I don't remember how we ended up with the mac80211-based design in the first place, but there is really no need for that there since the auth/assoc split works without issues with userspace taking case of that part of complexity. If nothing else, this would have avoided the race condition issues that showed up with kernel scheduling changes in UML time travel. One thing I noticed when looking at the details was that there was no explicit limit on the maximum comeback time. I added one in the wpa_supplicant implementation to avoid pointless wait of something like 50 days that could be hit by injecting an unprotected Association Response frame. mac80211 could do something similar. Though, at least wpa_supplicant would be timing that out with the overall connection timeout, so the practical impact from a potential attack would be quite limited. -- Jouni Malinen PGP id EFC895FA _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
