linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Johannes Berg <johannes@sipsolutions.net>
To: Denis Kenzior <denkenz@gmail.com>,
	"linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>
Cc: j@w1.fi
Subject: Re: LINKMODE & OPERSTATE thoughts
Date: Tue, 13 Jun 2017 11:15:44 +0200	[thread overview]
Message-ID: <1497345344.6068.10.camel@sipsolutions.net> (raw)
In-Reply-To: <ad95b6e5-9220-3eca-bf93-8ba1d89bde3b@gmail.com> (sfid-20170609_234205_953285_C41D8028)

On Fri, 2017-06-09 at 16:42 -0500, Denis Kenzior wrote:

> > I'm not convinced that it does have that information in all cases,
> > and I don't see how that causes race conditions or much latency,
> > since for client mode userspace would probably just set that
> > together with the NL80211_STA_FLAG_AUTHORIZED flag?
> 
> Well right there is a race condition.  You have 2 sockets and both 
> conveying the same information?

There's no race because we wait for the nl80211 operation to return
before even starting the rtnetlink operation.

> If we can optimize away an extra kernel trap, isn't that worthwhile 
> thing to do?

In itself, for something as rare as this? I don't really see it that
way.

> The most common case is issuing Dormant + UP after setting keys & 
> issuing the set_station command.  Isn't setting STA_FLAG_AUTHORIZED
> and operstate to IF_OPER_UP in effect equivalent?

Not entirely, since STA_FLAG_AUTHORIZED also applies to stations in
modes other than client mode, i.e. to stations other than the AP. In
almost all of those cases, the interface itself is already ready much
earlier.

> Oh, by the way, some drivers don't implement set_station for normal 
> links (e.g. setting STA_FLAG_AUTHORIZED returns an error), should
> they?

If they support encryption they probably should, but they might hook it
from getting the keys or so?

> The only other cases where we mess with setting linkmode I can think
> of are:
> 
> 1. After connecting to an open network
> 2. After a fast transition
> 
> For 1, it would seem that the kernel can easily infer that the 
> IF_OPER_UP flag should be tweaked.

Userspace should still set the AUTHORIZED flag in this case, just
possibly earlier and obviously without any key negotiation. The same is
true for WEP.

> For 2, this needs to be done after the new TK is installed.  Can we 
> combine these steps somehow?

I'm just not convinced it's worth it.


What I think we *can* do, with new EAPOL-over-nl80211 API, would be to
mandate that drivers supporting that, and when it's used, must only set
the carrier state after the controlled port is opened (AUTHORIZED
flag). That way, wpa_s wouldn't have to play with IF_OPER_DORMANT and
IF_OPER_UP at all.

johannes

  reply	other threads:[~2017-06-13  9:15 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-08 23:17 Question on setting key right after the EAPOL 4/4 is sent Ben Greear
2017-06-08 23:36 ` Denis Kenzior
2017-06-08 23:43   ` Ben Greear
2017-06-09  0:07     ` Denis Kenzior
2017-06-09  7:28       ` Johannes Berg
2017-06-09 13:10         ` Denis Kenzior
2017-06-09 19:56           ` Johannes Berg
2017-06-09 21:42             ` LINKMODE & OPERSTATE thoughts Denis Kenzior
2017-06-13  9:15               ` Johannes Berg [this message]
2017-06-09 13:46         ` Question on setting key right after the EAPOL 4/4 is sent Ben Greear
2017-06-09 20:01           ` Johannes Berg
2017-06-09 20:18             ` Ben Greear
2017-06-09 21:47               ` Janusz Dziedzic
2017-06-09 22:02                 ` Ben Greear
     [not found]                   ` <CADP2NhbXgHWo+BWhrKQndu5X7fzd2J9teqf-o6fSWwDMv8X5Hw@mail.gmail.com>
2017-06-10 16:01                     ` Ben Greear
2017-06-10 19:13               ` Arend van Spriel

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=1497345344.6068.10.camel@sipsolutions.net \
    --to=johannes@sipsolutions.net \
    --cc=denkenz@gmail.com \
    --cc=j@w1.fi \
    --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).