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: 1736 bytes --]

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

But why did we trash the idea of simply postponing the moment when NEW_STA is
sent to userspace? It can be sent when the kernel has received the AUTH "Reply"
message and avoid the current race condition.
Actually this would mean to send the NEW_STA at the same moment the kernel with
this patch would send the IBSS_STA.

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


Cheers,

-- 
Antonio Quartulli

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

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