Re: [RFC] Make scan mode configurable
- From: Tambet Ingo <tambet gmail com>
- To: Daniel Wagner <wagi monom org>
- Cc: networkmanager-list gnome org
- Subject: Re: [RFC] Make scan mode configurable
- Date: Tue, 10 Feb 2009 14:40:01 +0200
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.
>> 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?
> 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).
>> 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.
> 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? 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.
Tambet
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]