Re: [RFC] Make scan mode configurable



On Tue, Feb 10, 2009 at 02:40:01PM +0200, Tambet Ingo wrote:
> On Tue, Feb 10, 2009 at 14:20, Daniel Wagner <wagi monom org> wrote:
> > On Tue, Feb 10, 2009 at 01:12:02PM +0200, Tambet Ingo wrote:
> >> What would call the API you added (other than your test program)?
> >
> > Good question. I assumed this could be an option in the nm-applet.
> 
> The problem is there's no place to put it there. There's no per-device
> configuration location anywhere, all the configuration is NMConnection
> specific.

Okay, I didn't realize this.

> >> Who would want/need to use that UI?
> >
> > I can just write about the problem I wanted to fix. The time needed
> > to recognize there is a new AP or an AP disappeared was just too long.
> > Of course if you don't have a "fast" changing network setup this is not
> > really problem. This is all about moving around with your laptop/device and
> > if it takes 120 seconds to see there is a new AP and 360 seconds to
> > remove the AP from the list is just a bit too long IHMO.
> 
> Can you use wireless when you move that fast? :) Surely you can't stay
> connected to any of the APs?

My use case is not about to stay connected when I move around. This might
be the next thing I'd like to look at. It is as you say "I want my wireless 
APs appear/disappear faster". Hopping from one hot spot to the next one 
(read: open AP) :)

> > If I didn't get it completely wrong, connman uses continuously
> > scanning to overcome this problem.
> 
> That's exactly what I meant by being device specific. Connman only
> cares about a few selected wireless cards that support passive
> scanning, NM needs to also work on cards where a scan request takes
> noticeable amount of time (when no other IP traffic could be sent).

I was not aware of this problem, though I should have. Argh! 

> >> Is it wireless device specific?
> >
> > The patch allows to set the scan interval for each device separately.
> > Basically the patch just changes default behavior in NM. The
> > scan is still triggered through the wpa_supplicant interface.
> >
> >> If it's card specific, then we can do the right thing in the NM
> >> without asking users to try random options if something doesn't feel
> >> right.
> >
> > No, it is not card specific. Okay I think you are right about
> 
> Sounds like it still is.

Hmm, I think I don't understand you here. What do you mean with card specific?
The thing you explaned above (passive/active scan)? I was talking about
dependencies on hardware specific HW interface (madwifi vs. wext vs. cfg80211, 
etc.)

> > offering users too many knobs to play with. How do you propose
> > to "fix" my use case?
> 
> I don't know much about wireless drivers, but maybe a new capability
> for drivers, IW_SCAN_CAPA_SOMETHING? 

As I said I'm not sure where the scanning policy belongs to.

> Dan or Helmut will have a better
> answer. But having UI for something like "I want my wireless APs
> appear/disappear faster" is certainly not a solution, everybody wants
> that.

Clearly, this is what we should aim for :)

daniel


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]