Bug 3599 - Option to disable auto-connecting to specific saved wifi connections
: Option to disable auto-connecting to specific saved wifi connections
Status: VERIFIED DUPLICATE of bug 1050
Product: Connectivity
WiFi
: 4.1.1 (4.2008.30-2)
: All Maemo
: Low enhancement (vote)
: ---
Assigned To: unassigned
: wifi-bugs
:
:
:
:
  Show dependency tree
 
Reported: 2008-08-18 00:45 UTC by Magnus Ihse Bursie
Modified: 2008-12-16 14:11 UTC (History)
2 users (show)

See Also:


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description Magnus Ihse Bursie (reporter) 2008-08-18 00:45:42 UTC
I'd like to have the ability to disable automatic connection to a stored WiFi
connection.

Consider the following (unfortunately very true) scenario: On my work, there is
a badly working AP, which draws all power from my N810 when it connects, so I
run out of battery on less than a day. The WPA key is non-trivial, and I want
to store it as a remembered connection. At other places (home, etc) I want the
NIT to connect automatically to any stored connection it can find, but at work,
I'd like to treat the WLAN connection like the Bluetooth connection, that is,
only connect when I accept.

There are of course several ways of solving this. I'd suggest adding a checkbox
at the Advanced settings window on a connection with something like "Disable
automatic connection for this connection". And correspondingly, in the
connection code, if only such connections are found, ask the user how to
connect. (Presumably suggesting a found, but "disabled" WLAN account in front
of a bluetooth connection).
Comment 1 Andre Klapper maemo.org 2008-08-18 15:38:31 UTC
So going into Offline mode is not an appropriate workaround?
Comment 2 Magnus Ihse Bursie (reporter) 2008-08-18 19:12:52 UTC
It's the workaround I'm using, but it's a workaround, not a good solution. It
requires me to remember to bring the N810 into offline mode when arriving at
the office in the morning, and to bring it out of offline mode when leaving. If
I forget the former, I'll end up with a dead N810 on the subway home, and if I
forget the latter, I'll end up with a N810 that doesn't do the things it's
supposed to do. (Like, checking mail when I get home and it finds a working
WLAN connection).

Another workaround (which solves the problems the one above creates) is to not
save the connection, but that requires me to enter the WPA key everytime I want
to connect, which in practice is too tedious.
Comment 3 Neil MacLeod maemo.org 2008-08-19 01:55:25 UTC
Sounds like this could be another use case for enhancement bug 1046 which asks
for more and sophisticated power management profiles. In the case of your
"Work" profile (which would be determined based on day of week [eg. Mon-Fri] &
time of day [eg. 9am-6pm], availability of specific WiFi networks and/or geo
location etc.) your tablet would not auto connect to the available networks,
and may exhibit other "Work" related behaviour.

However when you get "Home" (again determined by geo-location, available WiFi
networks, day of week/time of day) your tablet would auto-connect to a known
good WiFi network.
Comment 4 Magnus Ihse Bursie (reporter) 2008-08-19 18:15:19 UTC
Well, maybe, but that really feels like just another, somewhat more usable,
workaround.

The real problem here is the broken AP. The "correct" solution would be to
replace it with a working AP; unfortunately, I can't affect this.

So, from my point of view, the best way to handle this is to handle this
specific connection as "non-auto", in the same way that GPRS connection is
"non-auto".

This is not really a question of a power profile (even if I like the concept
with extended power profiles), it's a question of getting a easy-to-use middle
way between automatic connection to a known AP, and manual connection on-demand
to all WLAN connections all the time.
Comment 5 Andre Klapper maemo.org 2008-10-11 03:01:55 UTC
In fact this is a duplicate of bug 1050 I just realize while looking at the
Connectivity bug reports. :)

*** This bug has been marked as a duplicate of bug 1050 ***