From: Antonio Quartulli <antonio@open-mesh.com>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: <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: Wed, 2 Jan 2013 07:32:55 +0100 [thread overview]
Message-ID: <20130102063255.GA27676@open-mesh.com> (raw)
In-Reply-To: <1356706268.9922.23.camel@jlt4.sipsolutions.net>
[-- Attachment #1: Type: text/plain, Size: 3441 bytes --]
Hi Johannes,
On Fri, Dec 28, 2012 at 03:51:08 +0100, Johannes Berg wrote:
> Anyway this part is really confusing. If userspace is handling auth
> frames, should the kernel really mark the station as authenticated? What
> then is the point in handling auth frames in userspace??
>
> Will?
Actually I don't know. Maybe Will can help us in understanding how to handle this point.
I simply kept the same behaviour: before this (my) patch a station was marked as
AUTHenticated in by the kernel, even if userspace registered for AUTH frames,
and the same I'm doing here.
>
> Any chance we could converge on a single implementation here?
>
Maybe yes :)
I think that leaving the station not AUTHenticated and let userspace do so would
be the best approach..but then we need a way to enable userspace to do it :)
> > +static void ieee80211_ibss_auth_sta(struct sta_info *sta)
> > +{
> > + if (sta->sta_state > IEEE80211_STA_NONE)
> > + return;
> > +
> > + sta_info_move_state(sta, IEEE80211_STA_AUTH);
> > + sta_info_move_state(sta, IEEE80211_STA_ASSOC);
> > + /* authorize the station only if the network is not RSN protected. If
> > + * not wait for the userspace to authorize it
> > + */
>
> technically, control_port != RSN protected, but I guess for IBSS ...
> who's going to do WAPI? ;-)
This is a behaviour I introduced some time ago:
1153 sdata->u.ibss.control_port = params->control_port;
which is set based on NL80211_ATTR_CONTROL_PORT and at the moment, in IBSS, I
think it is only set by wpa_supplicant when using IBSS/RSN..you told me to use
control_port instead of creating another member..but maybe it is general and
could be used for something else?
>
> > + cfg80211_ibss_sta(sta->sdata->dev, sta->sta.addr, GFP_KERNEL);
>
> I'm not really convinced that this event is the right thing to do.
>
> If userspace is handing the auth frame, it already has the event right
> there, no? It can even reply, even if for some reason it can't send a
> negative reply because the kernel has already marked the station as
> authenticated (see above).
>
Here I am missing something. To the best of knowledge, wpa_supplicant (which is
the only userspace tool providing IBSS/RSN and it is not handling AUTH frames.
Therefore it will not have any event for authentication..
> If there's no userspace, then RSN can't work anyway, so maybe this isn't
> really needed?
what we could do is to "move" the NEW_STA event and use it in this point. But I
preferred to create a new event type in order to distinguish between the case of
detecting a new station from the case of having a new station ready for key
exchange.
>
> Also, a more generic event would make more sense I think?
>
You mean a generic event to be triggered on state change? Yes sure, but at the
moment it was much more important to reshape the interaction between US and KS
when using IBSS/RSN.
> > + ieee80211_ibss_auth_expire(sdata);
>
> It seems you should have something to trigger the timer too?
>
uhm? I don't understand. This function is invoked in ieee80211_sta_merge_ibss()
which should be periodically called (if I got it correctly...the timer stuff in
ibss is not really clear to me)
Thank you very much for your feedbacks!
Happy new year :)
Cheers,
--
Antonio Quartulli
..each of us alone is worth nothing..
Ernesto "Che" Guevara
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
next prev parent reply other threads:[~2013-01-02 6:34 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 [this message]
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
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=20130102063255.GA27676@open-mesh.com \
--to=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.