linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Will Hawkins <hawkinsw@opentechinstitute.org>
To: Nicolas Cavallari <Nicolas.Cavallari@lri.fr>
Cc: Johannes Berg <johannes@sipsolutions.net>,
	Antonio Quartulli <antonio@open-mesh.com>,
	linux-wireless@vger.kernel.org
Subject: Re: [PATCHv3 2/2] mac80211: in AD-HOC mode wait for the AUTH response
Date: Tue, 29 Jan 2013 16:50:37 -0500	[thread overview]
Message-ID: <5108442D.9080104@opentechinstitute.org> (raw)
In-Reply-To: <5107D5D5.3070601@lri.fr>



On 01/29/2013 08:59 AM, Nicolas Cavallari wrote:
> On 29/01/2013 12:37, Johannes Berg wrote:
>> On Sat, 2013-01-26 at 13:09 +0100, Nicolas Cavallari wrote:
>>> (and my take on this, is that we should just handle open system
>>> authentication and reboot detection in userspace (i have code for that),
>>> and revert the kernel to the old state where it would just answers an
>>> open system authentication request if userspace is not handling it)
>>
>> I think that would make sense. However, to really implement that it
>> seems that wpa_s should be able to control the in-kernel station
>> "authenticated" state, not just "authorized" state?
> 
> Theoritically, yes. However, i don't remember that the "authenticated" state actually
> changes anything in IBSS mode. In fact, with the current code, all stations have the
> "authenticated" state, whatever the specified parameters and even when the kernel
> initiates an open system authentication.

I agree with this statement. From my reading of the code, it seems that
IBSS nodes are always authenticated. Which is fine, as long as I am not
missing something! :-)

> 
>>
>> What's the status we have today in the kernel, without the patches, and
>> what would that "revert" mean?
> 
> Right now, all IBSS stations have the "authenticated" flag.
> 
> If userspace is subscribed to auth frames, userspace have to handle everything, else, if
> userspace is not subscribing to auth frames:
> - When detecting a new station, the kernel sends an open system auth request, as part of
> node reboot detection.
> - When the kernel receives an open system authentication request, it destroys the station
> and recreates it as part of node reboot detection. If all goes well, it answers it.
> - wpasupplicant uses the NEW_STA and DEL_STA events to maintain a list of stations. It
> starts RSN handshakes on NEW_STA, and destroy its state on DEL_STA. Eventually, if
> handshakes succeeds, wpasupp authorize the stations with SET_STA (i think). much older
> wpasupplicant do not support authorizing stations, so the kernel always authorize stations
> (but all their unencrypted frames will be dropped until wpasupp configures a PTK after a
> successful handshake).
> 
> The revert is just my personal taste, but in the case where userspace does not subscribe
> to auth frames, i would just make the kernel answer an open system authentication request
> if it receives one, and not send any open system auth by itself. That would mean no reboot
> detection unless userspace does it. wpasupplicant would maybe need a way to reset the
> kernel's sta_info if not already possible.
> 
> 
>> What changes could we make today to solve this in a way that's
>> compatible with today's wpa_supplicant (and maybe Will's SAE
>> implementation, though maybe he wouldn't mind small changes too much)?
> 
> Will's SAE will not be affected by any of this, as it's done in userspace by subscribing
> to auth frames. If Will need node reboot detection, he has to do it himself.

Totally agreed! This will not change my code at all. However, having a
"new authenticated station" message (to parallel a message like
NL80211_CMD_NEW_PEER_CANDIDATE from the 802.11s world) would be great
too. That's how I interpreted the IBSS_STA event to work.

The ultimate goal for me is to eventually incorporate SAE support for
IBSS into wpa_s. In other words, I'm following this discussion very
closely and I appreciate everyone's work.

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

  reply	other threads:[~2013-01-29 21:50 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 [this message]
2013-01-31 13:34                     ` Johannes Berg
2013-01-31 14:18                       ` Nicolas Cavallari
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=5108442D.9080104@opentechinstitute.org \
    --to=hawkinsw@opentechinstitute.org \
    --cc=Nicolas.Cavallari@lri.fr \
    --cc=antonio@open-mesh.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).