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:
pgppvOwqWaNsr.pgp
Description: PGP signature
