Bug 4264 - Switch automatically from Bluetooth to WiFi
: Switch automatically from Bluetooth to WiFi
Status: CLOSED FIXED
Product: Connectivity
Networking
: 5.0-beta
: All Maemo
: Low enhancement with 1 vote (vote)
: 5.0 (1.2009.41-10)
Assigned To: unassigned
: networking-bugs
:
:
: 1043
:
  Show dependency tree
 
Reported: 2009-04-10 10:05 UTC by Tuomas Kulve
Modified: 2010-01-23 10:52 UTC (History)
3 users (show)

See Also:


Attachments


Note

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


Description Tuomas Kulve (reporter) 2009-04-10 10:05:32 UTC
With autoconnect the n8x0 switches nicely to bluetooth connection when wlan
connections are not available anymore. But it will never switch away from the
BT connection as that's always available (if you move the n8x0 with your
phone).

It would be nice to be able to force (even when there might be some
connections, like SIP, active) the internet connection back to wlan
automatically when a known wlan is found.

E.g. when I leave to work from home, the n8x0 switches to BT when the home wlan
isn't found anymore and when I arrive to the office it would automatically
connect to office wlan.

This would break all active IP connections but most applications can reconnect
automatically (e.g. SIP client, probably the email client, browser doesn't have
active connections usually, etc).

This would mean that the device would need to check for wlans even when already
connected via the BT which of course increases the battery consumption. The
wlan checking interval could be longer when already connected via BT than the
default search interval.

This is an issue for me in the current Diablo releases. I don't know how this
is handled in the Fremantle. I don't expect to get this fixed for Diablo but
I'm suggesting that this kind of feature would be added to Fremantle, if not
there yet.
Comment 1 Andre Klapper maemo.org 2009-04-14 00:54:10 UTC
Setting version to Diablo as it's not been tested on Fremantle
Comment 2 Lucas Maneos 2009-05-04 20:12:13 UTC
Switching connections automatically would be undesirable when there are active
file transfers, ssh sessions, VoIP calls etc.

Using an idle timeout would have the desired effect in most cases, except for
SIP keepalive traffic which is too frequent (it has to be in order to work with
NAT).  I think the idle timeout is implemented in icd in maemo, but pppd has a
mechanism ("active-filter") to stop certain classes of traffic from tickling
the idle timer.  Perhaps something similar could be used to allow the
connection to close when SIP registrations are active?
Comment 3 Tuomas Kulve (reporter) 2009-05-05 08:55:30 UTC
(In reply to comment #2)
> Switching connections automatically would be undesirable when there are active
> file transfers, ssh sessions, VoIP calls etc.

That's true but that's also exactly the case I want. I do often have the SSH
open but I still want it to switch from BT to WLAN (even though it will kill
the SSH connection). For me it's easy to reconnect the SSH. Restarting a long
file transfer would of course be very annoying, but that wouldn't be an issue
for me.

> Using an idle timeout would have the desired effect in most cases, except for
> SIP keepalive traffic which is too frequent (it has to be in order to work with
> NAT).  I think the idle timeout is implemented in icd in maemo, but pppd has a
> mechanism ("active-filter") to stop certain classes of traffic from tickling
> the idle timer.  Perhaps something similar could be used to allow the
> connection to close when SIP registrations are active?

SSH and SCP have at least different TOS bits in the IPv4 headers. It would be
nice to be able to select that traffic to port 5060 (SIP) and certain TOS bits
wouldn't reset the idle timer.

That approach would be very advanced and not feasible for most of the users.
Just to be able to select "Force a switch from BT to known WLAN when available"
in Connectivity settings would be more convenient.
Comment 4 Lucas Maneos 2009-05-06 10:40:01 UTC
(In reply to comment #3)
> That approach would be very advanced and not feasible for most of the users.

I was thinking there could be a reasonable default policy, but after further
thought it would have to be dynamic and looks like too much work.  For example
SIP could be on a different port, which might not even be defined in the
account settings (ie determined via NAPTR/SRV lookups) and could change while a
connection is active.  Never mind that then.

> Just to be able to select "Force a switch from BT to known WLAN when available"
> in Connectivity settings would be more convenient.

Maybe in conjunction with bug 1043 (extended to include priorities for all
types of connections)?  The known WLAN could be a hotspot subscription and you
probably wouldn't want the cellular connection to be dropped whenever you pass
by a coffee shop.
Comment 5 Tuomas Kulve (reporter) 2009-05-09 09:31:08 UTC
(In reply to comment #4)

> Maybe in conjunction with bug 1043 (extended to include priorities for all
> types of connections)?  The known WLAN could be a hotspot subscription and you
> probably wouldn't want the cellular connection to be dropped whenever you pass
> by a coffee shop.

Priorities for WLANs and BT/GPRS connections sounds good. A tap there to force
the switch to higher priority connection whether or not there are active IP
level connections would solve my request.
Comment 6 Tuomas Kulve (reporter) 2009-05-09 09:34:14 UTC
(In reply to comment #4)

> Maybe in conjunction with bug 1043 (extended to include priorities for all
> types of connections)?  The known WLAN could be a hotspot subscription and you
> probably wouldn't want the cellular connection to be dropped whenever you pass
> by a coffee shop.

On the other hand, switching from one WLAN to another might not make sense
where as switching from slow BT to fast WLAN would make.

And BT/GPRS isn't very reliable, there are occasional break ups anyway. So
breaking the GPRS connection wouldn't be that big thing (for me at least).
Comment 7 Lucas Maneos 2009-05-10 16:25:14 UTC
(In reply to comment #6)
> On the other hand, switching from one WLAN to another might not make sense

I can see some situations where it would make sense:
- free vs paid hotspots where both are available
- preferring the user's "own" WLAN (which provides access to local servers etc)
over the public hotspot across the street
- preferring an encrypted hotspot vs an open one so one can have a reasonably
private VoIP call.

> where as switching from slow BT to fast WLAN would make.

Although (just playing devil's advocate) some WLAN connections' upstream link
can be slower than some HSPA connections.

> And BT/GPRS isn't very reliable, there are occasional break ups anyway. So
> breaking the GPRS connection wouldn't be that big thing (for me at least).

Indeed, with a bit of user-controlled fine-tuning (such as connection
priorities) it would be useful.
Comment 8 Andre Klapper maemo.org 2009-07-01 15:30:34 UTC
(In reply to comment #7)
> Indeed, with a bit of user-controlled fine-tuning (such as connection
> priorities) it would be useful.

I agree. Adding dependency and confirming.
Comment 9 Tuomas Kulve (reporter) 2009-10-12 09:42:12 UTC
I was suggesting this feature for Fremantle and in n900 the connection is
automatically switched from BT to WLAN when appropriate. Having active SIP
connection open doesn't affect this. I don't know how e.g. open SSH connection
would affect the situation.

Any way, I'm happy with the n900 connectivity related to this and from my part
this can be resolved as FIXED.
Comment 10 Andre Klapper maemo.org 2009-10-13 13:07:42 UTC
Great. Thanks for the feedback!
Comment 11 Tuomas Kulve (reporter) 2009-10-13 13:35:01 UTC
Verifying on Fremantle.
Comment 12 Tuomas Kulve (reporter) 2010-01-23 10:52:58 UTC
I probably shouldn't CLOSE bugs but I was about suggest it and at least I have
the close option below, so I'm closing this directly.

Please reopen if I shouldn't have closed this.