Re: [PATCHv3 2/2] mac80211: in AD-HOC mode wait for the AUTH response

[Nicolas Cavallari <Nicolas.Cavallari@lri.fr>]

On 07/04/2013 23:17, Antonio Quartulli wrote:
> Hi all,
> 
> let's resurrect this thread :)
> 
> On Thu, Jan 31, 2013 at 06:26:13AM -0800, Johannes Berg wrote:
>> On Thu, 2013-01-31 at 15:18 +0100, Nicolas Cavallari wrote:
>>
>>>> I think that's acceptable, but if it requires a wpa_s change anyway we
>>>> could just implement reboot detection there instead of adding all these
>>>> new events etc.? I.e. rather than having a new supplicant say "OK I will
>>>> listen to the right event when handling reboot detection", it could just
>>>> use the existing infrastructure and implement it itself?
>>>
>>> Well i already have wpa_supplicant patches for that. Might just need to clean that up a
>>> bit so it's at least configurable.
>>>
> 
> Would you mind sharing this code?

Well yes, i just need to untangle it with some other local policies ;)

> Maybe I can help and offload some work. :)
> Anyhow I did not understand how you can detect a node reboot from userspace if, as
> you stated, wpa_s is not able to distinguish encrypted from un-encrypted frames.

Well, you do it the same way as you do in the kernel, using auth frames. Except you're not
in the kernel.

>>> But now i'm reminded that transmitting management frames from userspace requires a
>>> frequency. For wpasupp to be race-free during ibss merges, we should have a way to
>>> transmit management frames to the current bss without specifying a frequency...
>>
>> That seems reasonable.
>>
> 
> This is a common problem I faced in other contexts too...

I sent a patch shorty after this message, trying to solve the problem, except Johannes
pointed out that it could still introduce races, at least in some non-mac80211 drivers,
the most problematic being ath6kl. I don't have any ath6kl hardware here, and i don't like
patching things that i can't test.