linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Michael Buesch <mb@bu3sch.de>
To: "Alina Friedrichsen" <x-alina@gmx.net>
Cc: linux-wireless@vger.kernel.org
Subject: Re: [PATCH v2] mac80211: Call commit() on channel setting
Date: Fri, 27 Feb 2009 17:14:54 +0100	[thread overview]
Message-ID: <200902271714.54181.mb@bu3sch.de> (raw)
In-Reply-To: <20090227153418.254900@gmx.net>

On Friday 27 February 2009 16:34:18 Alina Friedrichsen wrote:
> > Could you explain what commit is supposed to to after the channel switch?
> > To me it's not clear what the difference in functionality is.
> > What do you expect to happen on the commit call after the channel change.
> 
> I think after all changes which affect the selected network a rejoin should be done.
> 
> For example you have at channel 4 a AP with the SSID "test" und at channel 11 an other AP with the same SSID, too.
> 
> If you now first say set_ssid("test") and then set_channel(11), we first join the network at channel 4 and then we switch the hardware low-level to channel 11. So we hang now in channel 4 with the BSSID of the network in channel 4 and nothing works anymore.

I think this is desired behavior. We voluntarily associated with the "test" AP on channel 4.
Who says that we want to assoc to the "test" ssid on channel 11? This is a policy decision and such policy
doesn't belong into the kernel. Userspace can initiate a reassociation after the channel change,
if the AP switch is desired.
There are good reasons to leave roaming decisions in userspace, because these decisions are simply very
complex and would put lots of policy into the kernel or require lots of kernel API.

> I think the order of the commands should not affect the result on the end and the driver should never hang in an broken/undefined state if it can be recovered.

-- 
Greetings, Michael.

  parent reply	other threads:[~2009-02-27 16:16 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-26 23:43 [PATCH v2] mac80211: Call commit() on channel setting Alina Friedrichsen
2009-02-27 14:03 ` Michael Buesch
2009-02-27 15:35   ` Alina Friedrichsen
2009-02-27 15:39     ` Alina Friedrichsen
     [not found]   ` <20090227153418.254900@gmx.net>
2009-02-27 16:14     ` Michael Buesch [this message]
2009-02-27 17:16       ` Alina Friedrichsen
2009-02-27 18:25         ` [PATCH v3] " Alina Friedrichsen
2009-02-27 16:20 ` [PATCH v2] " Johannes Berg
2009-02-27 21:26   ` Alina Friedrichsen
2009-02-27 21:35     ` 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=200902271714.54181.mb@bu3sch.de \
    --to=mb@bu3sch.de \
    --cc=linux-wireless@vger.kernel.org \
    --cc=x-alina@gmx.net \
    /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).