maemo.org Bugzilla – Bug 8444
Switch automatically to higher priority WiFi network
Last modified: 2012-03-24 11:45:26 UTC
You need to
before you can comment on or make changes to this bug.
EXACT STEPS LEADING TO PROBLEM:
1. Configure connections for multiple wireless networks that are accessible
from one physical location
2. Locate yourself in range of only the less preferred network, device connects
3. Relocate yourself to a point where both networks are within range, the
device remains connected to the less preferred network
Disconnect from less preferred network, connect to more preferred network
Existing connection remains, even though it may be to a less preferred network
EXTRA SOFTWARE INSTALLED:
For example, I have a wireless access point in my car providing 2mbit internet
via Verizon EV-DO. When I get near the car, my N900 automatically connects to
the access point within the car. I then arrive home, within range of an access
point providing 7mbit internet access via cable modem, but the device remains
connected to the AP in my car until the signal becomes too weak.
what is your setting for
"Settings > Internet Connections > Connect automatically"?
On a related note, I don't think that it is technically possible yet to switch
WiFis without interruption. Hence this is most probably a design decision that
constant data flow is prefered towards a stronger network reception, and hence
> what is your setting for
> "Settings > Internet Connections > Connect automatically"?
> On a related note, I don't think that it is technically possible yet to switch
> WiFis without interruption. Hence this is most probably a design decision that
> constant data flow is prefered towards a stronger network reception, and hence
I'm looking for the ability to configure a preferred network order or assign a
priority to each network, which would then be taken into account when
evaluating the WiFi network to connect/change to. Data flow interruption isn't
of much concern in this case, as the performance gains of automatically
connecting to a more preferred network would be more beneficial than not having
a momentary interruption.
(In reply to comment #2)
> I'm looking for the ability to configure a preferred network order or assign a
> priority to each network
For this part see bug 1043 and its dependencies, and feel free to vote :-)
(In reply to comment #0)
> EXPECTED OUTCOME:
> Disconnect from less preferred network, connect to more preferred network
This is conceptually (the same connection interruption concerns apply) similar
to bug 4264 which is marked FIXED, so let's keep this for the WLAN -> higher
priority WLAN switch case for now.
Note that this may be a WONTFIX as it would require periodic scans during an
active WLAN connection, which AFAIK would interrupt traffic.
(In reply to comment #3)
> For this part see bug 1043 and its dependencies, and feel free to vote :-)
> Note that this may be a WONTFIX as it would require periodic scans during an
> active WLAN connection, which AFAIK would interrupt traffic.
This does not appear to be the case. While connected to a wireless network, I
started a ping in one x-term and ran "iwlist scanning" in another. I was able
to receive results of a scan without packet loss being indicated by the ping.
Doug, is it not possible for the AP in the car to be powered down (as you would
a CD/Radio header unit) whenever the ignition is cut?
If ever you need the car AP to be available, but don't want the motor running,
most in-car equipment will power up when the ignition key is moved to the first
position. Remove the ignition key and your problem would be solved as the car
AP would automatically power down/disappear, leaving the home AP to take over.
(In reply to comment #5)
> Doug, is it not possible for the AP in the car to be powered down (as you would
> a CD/Radio header unit) whenever the ignition is cut?
No. I have a high gain antenna installed on the car to provide enough coverage
to use from inside nearby buildings, as a backup for when I am at locations
which don't otherwise have internet connectivity. Keying the car on when I
require internet access is generally not an option, because I then would run
the risk of having the car stolen as it would be unattended.
(In reply to comment #4)
> This does not appear to be the case. While connected to a wireless network, I
> started a ping in one x-term and ran "iwlist scanning" in another. I was able
> to receive results of a scan without packet loss being indicated by the ping.
Hmm, try connecting over ssh and start a scan... I was surprised, too, but the
connection went berserk.
(In reply to comment #7)
> Hmm, try connecting over ssh and start a scan... I was surprised, too, but the
> connection went berserk.
I can't seem to reproduce this result - the most I noticed was a very slight
pause, not unlike what I normally experience randomly. I even tried a ping -f
(flood ping, 100/sec or faster) against my device while performing "iwlist
scanning" and saw (at most) 56 packets dropped. Results of multiple tests:
Average pings/sec = 140, average drops/scan = 50.. so the average connection
interruption was roughly 1/3rd of a second.
(In reply to comment #8)
> I can't seem to reproduce this result
You're right, must have been some other problem: using WifiInfo, I could scan
continuously without losing chat presence.
*** This bug has been confirmed by popular vote. ***
The Maemo 5 User Interface and Maemo 5 platform components (e.g. libraries)
used for the N900 are considered stable by Nokia and it seems that there are no
plans for official updates currently, hence nobody plans to work on this
(And in case you feel like discussing this situation: Nokia Customer Care or
http://talk.maemo.org would be the place to do so as you will not reach Nokia
officials in this community bugtracker - though all of this is really no news.)
Reflecting this status by setting RESOLVED WONTFIX for this
enhancement/wishlist request (see
https://bugs.maemo.org/page.cgi?id=fields.html#status for status explanations).
There is a small chance for issues in those Maemo components that are open
source: Contributed patches could be included and made available in the Maemo 5
Community CSSU updates.
The Maemo CSSU project is run by a small team of volunteers; see
http://wiki.maemo.org/CSSU for more information.
So in case that you can provide a patch that fixes the reported problem, please
feel encouraged to file a request under
Please note: The Maemo CSSU project is not related in any way to Nokia.
( Tag for mass-deleting bugmail: [cleanup20120324] )