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

[Antonio Quartulli <antonio@open-mesh.com>]

[-- Attachment #1: Type: text/plain, Size: 2372 bytes --]

On Mon, Apr 08, 2013 at 12:53:55AM -0700, Nicolas Cavallari wrote:
> 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.
> 

Ah ok. I thought we were not talking about registering for AUTH frames here. Got
it now.


I'm wondering why it is better to implement kernel reboot detection in
userspace, but I think it is cleaner and less racy...Then I think it is better
to revert the "delete and add station" mechanism we currently have.

> 
> >>> 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.

Understood. Thanks for the explanation.


Cheers,

-- 
Antonio Quartulli

..each of us alone is worth nothing..
Ernesto "Che" Guevara

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]