From: Nicolas Cavallari <Nicolas.Cavallari@lri.fr>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: Antonio Quartulli <antonio@open-mesh.com>,
linux-wireless@vger.kernel.org,
Will Hawkins <hawkinsw@opentechinstitute.org>
Subject: Re: [PATCHv3 2/2] mac80211: in AD-HOC mode wait for the AUTH response
Date: Thu, 31 Jan 2013 15:18:40 +0100 [thread overview]
Message-ID: <510A7D40.2030206@lri.fr> (raw)
In-Reply-To: <1359639241.8415.17.camel@jlt4.sipsolutions.net>
On 31/01/2013 14:34, Johannes Berg wrote:
> That seems reasonable. Actually there's no reason for wpa_s to "reset
> the [...] sta_info", all it really has to do is set it to unauthorized
> if it detects it was rebooted, and then start key negotiation again, I
> think?
I'm not sure why Antonio resetted the sta_info. Not resetting it when a node reboot is
detected from userspace works for me anyway.
>> If we want a working node reboot detection with the current wpasupplicant, we need, in
>> IBSS mode, to only make the kernel send NEW_STA when a station is authenticated. There's
>> not much choice here.
>>
>> If it's acceptable to not have node reboot detection with current wpasupplicant, we could
>> make a future wpasupplicant add a flag saying it supports the new IBSS_STA event, and the
>> kernel would only do reboot detection in this case.
>
> 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.
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...
(Will once said he uses fixed-channel, so he is not affected)
next prev parent reply other threads:[~2013-01-31 14:18 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-10 13:40 [PATCHv3 1/2] cfg80211: add the new IBSS_STA event Antonio Quartulli
2012-12-10 13:40 ` [PATCHv3 2/2] mac80211: in AD-HOC mode wait for the AUTH response Antonio Quartulli
2012-12-28 14:51 ` Johannes Berg
2013-01-02 6:32 ` Antonio Quartulli
2013-01-02 9:40 ` Nicolas Cavallari
2013-01-07 11:40 ` Antonio Quartulli
2013-01-07 13:16 ` Nicolas Cavallari
2013-01-25 22:05 ` Johannes Berg
2013-01-26 12:09 ` Nicolas Cavallari
2013-01-29 11:37 ` Johannes Berg
2013-01-29 13:59 ` Nicolas Cavallari
2013-01-29 21:50 ` Will Hawkins
2013-01-31 13:34 ` Johannes Berg
2013-01-31 14:18 ` Nicolas Cavallari [this message]
2013-01-31 14:26 ` Johannes Berg
2013-04-07 21:17 ` Antonio Quartulli
2013-04-08 7:53 ` Nicolas Cavallari
2013-04-08 9:11 ` Antonio Quartulli
2013-01-31 14:32 ` Antonio Quartulli
2013-02-01 17:11 ` [PATCH] {cfg,nl}80211: tx_mgmt: use current bss channel if omitted Nicolas Cavallari
2013-02-04 16:04 ` Johannes Berg
2013-02-04 17:15 ` Nicolas Cavallari
2013-01-03 21:05 ` [PATCHv3 2/2] mac80211: in AD-HOC mode wait for the AUTH response Will Hawkins
2013-01-25 21:45 ` Johannes Berg
2013-01-29 21:54 ` Will Hawkins
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=510A7D40.2030206@lri.fr \
--to=nicolas.cavallari@lri.fr \
--cc=antonio@open-mesh.com \
--cc=hawkinsw@opentechinstitute.org \
--cc=johannes@sipsolutions.net \
--cc=linux-wireless@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.