linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Johannes Berg <johannes@sipsolutions.net>
To: Thomas Pedersen <thomas@cozybit.com>
Cc: linux-wireless@vger.kernel.org, devel@lists.open80211s.org,
	linville@tuxdriver.com
Subject: Re: [RFC] nl80211: don't require netdev UP for wdev
Date: Wed, 09 May 2012 11:15:45 +0200	[thread overview]
Message-ID: <1336554945.4323.12.camel@jlt3.sipsolutions.net> (raw)
In-Reply-To: <1335479316-2933-1-git-send-email-thomas@cozybit.com> (sfid-20120427_002914_313709_1CC9F96D)

On Thu, 2012-04-26 at 15:28 -0700, Thomas Pedersen wrote:
> It seems as long as we have a netdev, a wdev is available as well.
> Remove the restriction that netdev must be up before a wdev can be
> obtained in nl80211, or changing channels in cfg80211.
> 
> Signed-off-by: Thomas Pedersen <thomas@cozybit.com>
> 
> ---
> Hi list,
> 
> This was encountered while implementing an interface for setting
> BSSBasicRateSet in mesh. The wdev->channel is needed in nl80211.c for
> rate verification, but prior to this patch not available.  This doesn't
> seem right since the following sequence of commands would fail:
> 
> iw wlan0 set type mp
> iw wlan0 set channel n
> ip link set wlan0 up
> iw wlan0 mesh join meshid basic-rate 1,2
> 
> Also, 'iw set channel' is met with an -EBUSY if doing this after the
> link is up for fixed channel modes (mesh) anyway.
> 
> Comments? Any idea why this was required initially?


I don't think this patch is correct -- mac80211 will get updated even if
the device isn't even started which will likely cause trouble. Even if
not though, this all doesn't match any kind of multi-channel concept. We
treat the channel as part of the temporary setup, e.g. part of the
association. AP and mesh are the only ones that are different today I
think.

Overall, I don't think setting the channel & doing mesh setup separately
is really a good API.

>From mac80211's (and other drivers if they existed) POV the channel
should be given with the mesh_join command, like for IBSS.

Now, obviously, requiring userspace to do that would be an API change.
We probably don't want that, so I would suggest to change cfg80211 to
track the channel and then pass it to join_mesh as one of the mesh
parameters. This could be made work even when somebody attempts to set
the channel before the interface is up, but we'd have to be careful
about interface type changes.

We should do the same for AP mode as well, since the channel really
becomes relevant only upon start_ap(), before that there's no real
concept of a channel since you don't use it yet anyway.

johannes



  reply	other threads:[~2012-05-09  9:15 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-26 22:28 [RFC] nl80211: don't require netdev UP for wdev Thomas Pedersen
2012-05-09  9:15 ` Johannes Berg [this message]
2012-05-09  9:41   ` Michal Kazior
2012-05-09  9:50     ` Johannes Berg
2012-05-09 10:16       ` Michal Kazior
2012-05-09 11:40         ` Johannes Berg
2012-05-10 18:06   ` Thomas Pedersen
2012-05-10 18:12     ` Johannes Berg
2012-05-10 19:47       ` Thomas Pedersen
2012-05-10 19:52         ` Johannes Berg

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=1336554945.4323.12.camel@jlt3.sipsolutions.net \
    --to=johannes@sipsolutions.net \
    --cc=devel@lists.open80211s.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=linville@tuxdriver.com \
    --cc=thomas@cozybit.com \
    /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).