All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dan Williams <dcbw@redhat.com>
To: timg@tpi.com
Cc: linux-wireless@vger.kernel.org
Subject: Re: [PATCH] ipw2200: Change driver default policies
Date: Tue, 14 Oct 2008 12:35:37 -0400	[thread overview]
Message-ID: <1224002137.1799.0.camel@localhost.localdomain> (raw)
In-Reply-To: <48F4C7E8.4020201@tpi.com>

On Tue, 2008-10-14 at 10:25 -0600, Tim Gardner wrote:
> Dan Williams wrote:
> > On Tue, 2008-10-14 at 08:57 -0600, Tim Gardner wrote:
> >> From 41804698de6f2ce121c1452943b9ad2b8a54988b Mon Sep 17 00:00:00 2001
> >> From: Tim Gardner <tim.gardner@canonical.com>
> >> Date: Tue, 14 Oct 2008 08:16:09 -0600
> >> Subject: [PATCH] ipw2200: change default policies for auto-associate, auto-create, and auto-roaming
> >>
> >> We now have applications available to set policy. This patch changes the driver defaults to:
> >>
> >> 1) associate=0 - do not automatically associate to an SSID.
> > 
> > This one is fine.
> > 
> >> 2) auto_create=0 - do not automatically create an ad-hoc network
> > 
> > This will break adhoc network creation, thus NAK.  I think we should
> > just remove the module parameter and default to 1 anyway.  This is the
> > way adhoc _should_ work in the first place, if the adhoc network you're
> > attempting to join does not yet exist, the driver should create that
> > network.  This is the way it works for all other drivers as well.
> > 
> > Disabling this effectively means you can only join existing adhoc
> > networks, not start your own.
> > 
> 
> Agreed - I missed the part where its qualified by IW_MODE_ADHOC.
> 
> >> 3) roaming=0 - do not automatically roam to another AP with the same SSID.
> > 
> > Not really sure why this should be changed?  Were there reported issues
> > with this behavior?
> > 
> 
> Its been my expereince that wireless drivers rarely make the correct
> decision about when or where to roam. It also seems like a policy
> decision that ought to be made elsewhere.
> 
> Frankly, I'm not that concerned about the roaming option. The default
> for 'associate' was the one I _really_ wanted changed. I'll submit a v2
> patch with just that change.

Sure.  That's something I've wanted to turn off for quite a while, it's
sort of a security problem.  Nothing should be auto-associating until
told to do so to a specific SSID or SSID/BSSID combination.

Dan


      parent reply	other threads:[~2008-10-14 16:36 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-14 14:57 [PATCH] ipw2200: Change driver default policies Tim Gardner
2008-10-14 15:43 ` Dan Williams
2008-10-14 16:25   ` Tim Gardner
2008-10-14 16:35     ` Johannes Berg
2008-10-14 16:44       ` Tim Gardner
2008-10-14 16:47       ` Dan Williams
2008-10-14 16:35     ` Dan Williams [this message]

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=1224002137.1799.0.camel@localhost.localdomain \
    --to=dcbw@redhat.com \
    --cc=linux-wireless@vger.kernel.org \
    --cc=timg@tpi.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 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.