Bugzilla – Bug 6085
Wireless Roaming
Last modified: 2012-04-25 03:32:40 UTC
Like almost all other wi-fi based remotes (Philips, Crestron, AMX) you have a real problem with roaming. My home is large and not too RF friendly due to its construction (hurricane codes). To cover the 5000 square feet (single level) there are three WAP's installed. (Master bedroom, Great Room, Theater). When the Jive device is booted and it finds the network I assume it signs on to the access point with the best signal (one hopes). If I roam around the house with it, it never switches to a better WAP, it just stays with the one it was on no matter how bad the signal gets. Ideally it should be able to detect a prolonged bad signal (low SQ) for lets say 5-10 seconds and then re-acquire the WAP. This should be able to be done with just software as you do know the SQ level since you show it in the wi-fi widget. As a second and probably mandatory alternative, one should be able to command the Jive radio to re-acquire a WAP. That should not require a hardware change just whet ever is necessary software wise to re-initilize the radio, and let it do its thing to find the best siganl (SQ wise). Perhaps under settings.
Mickey: Can you see that Barry gets one of the new units with the improved antenna design?
Wow -- 3 access points in the same house! That's one big house. A great test location. I'll see about getting him the latest and (hopefully) greatest hardware.
In email Dean seems to suggest this is pretty important. Richard, is there any support for roaming at all in the current firmware? Is it something the drivers ought to handle or is it a high-level thing?
*** Bug 6212 has been marked as a duplicate of this bug. ***
Ross is looking at this re: bug 6212, which has been closed as a dup.
Well I am ready to receive the advanced Jive hardware. I will try it out roaming as need be. Two of the WAP's are leGrande onQ units (actually motorola devices) and the third is by Pakedge which is a commercial grade unit. All are running the same SSID, spaced out on channels 3,6,11 and in a quiet neighborhood WiFi signal wise. All are ceiling mounted in 10 and 12 foot ceilings. I do run NetStumbler occasionally to check things out with regards to Signal Strength, interference, etc. I have been in iT operations for decades when I worked, so I am pretty sure I can give you a decent assessment. I still feel that it should be a trivial software patch to be able to force the radio to de-authenticate and then re-acquire a WAP. Would probably be handy for testing even if not in the production units. If I had my way, there would be settings that allowed the user to state a signal strength level and a time duration. If the SS went to the specified SS (or lower) and stayed there for the specified time, then the deauthentication/re acqusition cycle would occurr automatically. An SS setting of zero would inhibit this automatic action. Just my 2 cents.
Dean did you have something specific you wanted tested? Has Wifi roaming been implemented yet?
The reinforced-concrete construction of my 5-story house also means that three access points would be needed to get house-wide coverage. I know quite a few people with two APs to get over this kind of problem and can see that roaming could be an important feature for them.
Confirmed roaming does NOT work for me either. Sveasoft firmware on Linksys WRT350N APs. The behavior seems to be that it will simply not reassociate to another BSSID (within the same SSID) even if the connection is lost entirely (i.e. the currently-connected AP is powered off). The only way to get it to reassociate if to navigate completely out of the wireless menu and then back in.
This should be looked at for 7.0.1.
My SB3 shows similar problems. I have two access points, and one of my SB3's is in a not so good signal area for both. It will eventually "lock in" to the weaker of the two, and then use it even at signal strengths below 20%. If I restart either access point, the SB3 will seamlessly switch to the other - so the switching works. But it is, IMHO, not aggressive enough about searching for a better signal when it's running at low signal levels. (On the good side, the newest firmware (86) seems very robust about dealing with the low signal and (presumably) lost packets that creates. There really are no external symptoms - it plays and controls very well. This, I think, is a distinct improvement from previous firmware).
I have been looking at adding support for Wireless roaming. This seems to work, when the wireless driver is told to perform a scan to look for new SSIDs. Following the scan it automatically re-associates with the BSSID in the associated network with the strongest signal strength. The wireless driver used in the Controller supports "background scanning", where it scans other channels during the power save cycles. Enabling this for 7.0.1 is neither trivial or low risk, so changing the target to 7.1. If you need this functionality as a workaround you can adding a /etc/init.d/rcS.local file, for example: echo "watch -n 30 iwlist eth0 scan&" > /etc/init.d/rcS.local chmod +x /etc/init.d/rcS.local Then reboot your controller. This will perform a scan every 30 seconds and will switch APs as expected. I don't know what the cpu/battery performance of this workaround is. With the current firmware when turning off an AP it does re-associate and continue working with another AP in the network. The problem Sean was reporting were possibly other connection problems that have since been fixed.
i don't know howcomplex this would be... but instead of having it scan every 30seconds, why not have it only rescan when a certain lower threshold is met? in other words, if one ap is 80% and the other in 90%, is it worth the switch? and is it even worth looking at whatever percent is totally robust to begin with?
Unfortunately I won't have time to look at this before the 7.1 code freeze, moving to 7.2.
punting to 7.3
It looks to me as though this problem also exists in the Boom and the Receiver. I have one of each, and a home network with two WAPs such as others have described, and see the same pathology -- once the unit locks a WAP, even with quite poor reception, it stays there, even if there is a much better signal available from a different WAP. They do reassociate if the WAP goes off the air entirely -- the problem is that they don't roam to the strongest WAP. Given the "rebuffering..." behavior caused by (I surmise) poor wireless reception, it would seem important to do a good job with this. Oh, it would also be very useful to list the MAC address of the WAP to which the unit is associated in its player information, along with the player's own MAC address, signal strength, and so on.
I think my Controller is roaming. Julius was helping me test bug 8418, I have a WRT54Gv2.2 with dd-wrt, and a WRE54G "connected" to it. They are both on channel 6, and they both have the same SSID, they are both set to no encryption because I haven't been able to get the WRE54G to work with the router with encryption, I'll work on that next week. I have the WRT54G on my desk, I put the range expander in the sales cube about 30 yards away. We connected a Controller to the SSID (dd-wrt) and it shows BSSID of 00:1C:10:68:79:64, the mac of the range expander. Then we walked to my desk, clicked the back button once and again chose the SSID dd-wrt to view network status, this time it shows BSSID 00:13:10:03:57:d5, the mac of the WRT54G on my desk. We went back and forth several times and repeated this, I also did this with another controller and it does the same thing.
BTW testing against 7.2 r2873.
I believe that the controller should "roam" if it looses the connection completely. Could this be happening in your case. The roaming complaints are about continuing to use a weak signal when a stronger one is available. (Ignorance warning - I'm not expert on this at all).
(In reply to comment #19) > (Ignorance warning - I'm not expert on this at all). Neither am I. Controller didn't seem to disconnect, the icon never changed from white. I could be crazy but I think this is working for me.
Regarding the "works for me" comments I'd be glad to test this myself again but is there some way to find out from the Controller (also the Boom and the Receiver) the MAC address of the access point it's currently associated with? I looked around and didn't find one, but possibly I've missed something. (This would be helpful since one my my access points doesn't have a way to list associated clients, grr Linksys mumble grr.)
OK, I did figure out how to do this with the Controller anyway (ssh'd to it and used iwconfig/iwlist) and it kinda sorta appears to be working although if it is, the Controller is pretty slow in hopping from a weak to a strong signal (as in, it takes several minutes to move). Is this bug specific to the Controller? Because from my PoV, the bigger problem is with the other wireless products (specifically in my case the Boom and Receiver). If the Controller has a marginal signal the failure mode is not as bad as if the actual player does (dropouts, track restarts, etc).
I think all wireless devices could theoretically benefit from this feature, although the clearest use-case involves the Controller. I certainly wouldn't mind seeing this in all the firmwares that can support it.
As Irelands dedicated Squeezebox installer we have come across this lack of roaming of the controller between APs in a number of occasions. It has typically been solved with selling an additional controller which is somewhat dedicated to a certain zone. HOWEVER we have lost a number of system installations to Sonos due to this issue. Therefore can I add our weight behind getting a fix resolved for this bug as it goes contrary to what these devices are marketed as i.e. whole house solutions - fine for a small/medium house but limited to larger ones or new houses with alot more foilbacked insulation hidden in the walls. Kindest regards, Nigel Cobbe Bespoke Wireless
Felix will be looking at this for 7.3 or 7.31.
So if I understand correctly, an experimental fix has been implemented which turns out to work surprisingly well. Felix will review how to change the fix to optimize connection quality.
..have been directed to this bug by Tech Support. I have a large house (10,000 sq. ft) with four WAPs on channels 1,3,6 and 11, all with the same SSID, four different BSSIDs, all running WEP64 security. If I walk from one area to another, the signal level indicator goes down and then, sometimes, will go up again in response to the stronger signal from the nearer WAP, but not always. Often I need to go to Home/Settings/Advanced/Wireless Network, whereupon the controller indicates "finding networks" and gives me a choice of my SSID. Selecting that shows the controller is now connected to the new WAP. More often than not, I need to back out to Home and then back in again to get the unit to connect. This is NOT my problem, however. When the unit loses connection and then reconnects, it frequently (maybe always, not sure) loses the ability to connect to a player, even one which is playing perfectly fine at the time. I can turn the unit off and back on, causing a reboot and it still cannot find the players (I have four in this system). I have sometimes solved this by removing the battery and replacing it, but sometimes even that does not work. The only step which always works is to force a factory reset and then reset up the controller and receiver (only one of my players is a Duet receiver; the others are older units). [As I wrote the above I found the unit was locked up in player selection after changing WAPs; in this case On/Off did not work, but removing the battery did.] Tech Support is asking me to move the WAP ethernet cables from a 24-port switch in my system directly to the router, which is logistically difficult because the cables don't reach, so I need some adapters and short cables to accommodate the change. So that will take some time for me to do. Meanwhile, should I be here, or do I have a separate bug? Rich Scholl If this is a separate bug, could you direct me to the correct place?
Well the team at Slim Devices should not feel too bad. I do a lot of work with Philips and their Pronto line of remote controls that use Wi-fi. They have exactly the same problem. From what I understand so doew Crestron and others. they do not publicize it but advise installers to install multiple WAP's and dedicate a controller to a WAP via proximity. I will sugegst what I suggested to philips who have done nothing yet: 1) Allow the unit to report which WAP it is connected to if that is possible 2) Have a setting that will re acquire a WAP if Signal strength drops below xxx for nnn seconds. 3) Have a way of settings a specific radio channel to force the unit to go to a specific WAP 4) Add some logging on WAP signal strength to enable some testing and debugging in the field as it is almost impossible to duplicate conditions in the laboratory. Log could be dumped to Squeezeceneter periodically if logging is turned on. Has anyone investigated whether it would be better or worse if all the WAP's are set to use the same channel as this is a permissible architecture but not often used. I have tried both and am currently with three WAP's at 1,6,11 all with the same SSID. There has been much discussion and conflicting opinions on this concept. In my home I have a WAP in every room where I use a Wifi based user device (actually three rooms, Theater, Master bedroom and Greatroom). I see no issues with the controller and I run all my players as wired with the exception of the Squeezebox and see no issue there. To be perfectly honest I use the Pronto as my primary music controller and not the duet controller, so my comments are general in nature.
Just to add my weight to hopes this one will be sorted soon - My property is a rambling old farmhouse with extremely thick walls, I need 3 wireless AP's to cover it all. The controller suffers what is best described as a nervous breakdown when attempting to roam (locks out, needs reboot etc) Stay in one room on one AP it's just fine. Richard Titmuss describes a temporary workaround in comment #12 - could this be published in a little more detail so it's possible to implement on a windows machine? I'm keen to show off my multi-room capabilities over the festive period, without the roaming it's just not possible. Thanks in advance.
Changing target to next release
With my brand new SB Duet I am experiencing almost identical issues to those described in Comment #27 but it's not due to roaming - just a lack of connectivity: When the Squeezebox Controller loses connection and then reconnects (if I'm lucky), it frequently loses the ability to connect to the single squeezebox player (also connected via wifi), even when is playing perfectly fine at the time. I can turn the controller off and back on, causing a reboot and it still cannot find the player. I am using a Safecom Safecom SWART2-54125 adsl router, connected to the PC via ethernet. I get it to reconnect by restarting the player with a 5 sec button hold. Running SC Version: 7.3 - 24282 SP Firmware: 55, Wireless Signal Strength: 88% SC Firmware: 7.3 R3476, 54Mb/s, WPA-PSK, SNR 60-65 As per other comments, all other wireless users (phone, laptop) have no issues. House is small timber frame construction so no issues with signal strength. I went for SB as the controller seems much faster and more attractive than the Sonos - but it's proving a difficult sell to the wife when it doesn't work if I'm not around to fix it....
Hi have two SB DUET receiver in bridget network mode in different rooms, one controller connects wireless via receiver, no wireless access point. SqueezeCenter 7.3.1. Everything is working fine as long as I stay connected to the first installed receiver. But when I move to the other room with the second receiver, the wireless signals goes very bad, because the controller always connects to the first receiver, it doesn't make a roaming to the closer receiver with the strong wireless signal. Is there a way to switch it manually WITHOUT doing a factory reset! This bug should be fixed as soon as possible. Otherways the multiroom concept with more than one receiver makes no sense! DEVELOPERS: please have a look to this issue!
Roaming and connection problems seem to occurr with all sorts of hand held remotes that use TCPIP for connectivity over Wi-Fi. I deal with the Philips pronto remotes and have similar problems. It is not a simple problem to solve. I have played with the idea of using multiple WAP's (Which I have) but setting them all on the same channel. In theory as you leave the range of one unit the radio may lock onto the next unit. I have heard mixed comments about this and am currently using three channels for my WAPs (1,6,11). ANy technical insight would be appreciated. The manufacturers (Logitech slim devices, Philips, etc) could help by doing two things. 1) Instrumenting on the info page data on the current wifi connection (Signal strength, Radio Channel, some identifier for the WAP being talked to as MAC address or something) This would allow users to better report conditions and help the devlopers resolve the issues more quickly 2) Add some manual easy way to force a re connection by the radio to the WAP. 3) Add some automatic way based on signal strenngth to cause the radio to remake the connection 4) allow one to force the radio channel to be used by the radio so it can only find a WAP that uses that channel. Philips has nodded politely when this was discussed in detail (they have the same issues) and I am sure Logitech Slimdevices will also. It would be nice if something other then understanding were to be provided, After all we are all trying to make your product work in the best possible way. Since logitech does not make a good wifi based TCPIP remote, maybe it is not in their interest to solve the problem so that others can also take their lead and inprove their products. As I have always said the best motivator in our world is self-interest!
Markus, Unfortunately what you're describing is the idea of roaming a receiver from the WiFi card on one Receiver to the WiFi card on another. This is actually not technically possible, unless perhaps you only had one Controller in the house. The issue is that the network created between two individual WiFi devices is an Ad-Hoc network. Ad-Hoc networks can only have the original pair of computers connected -- no more, no less. If the Receivers were operating in Infrastructure mode (normal WiFi Access Point mode) then this wouldn't be an issue -- but I do not believe the hardware is capable of that. The root of the ticket is actually for users who Roam from one Access Point to another Access Point in their house -- when the Access Point has the same name, and is generally on a different channel. This is the much more widely common method of extending WiFi networks through large (or brick) houses.
Punting to next release
We are now planning to make a 7.3.3 release. Please review your bugs (all marked open against 7.3.3) to see if they can be fixed in the next few weeks, or if they should be retargeted for 7.4 or future. Thanks!
The lua implementation I have so far fails a lot due to underlying issues, i.e. kernel crashing as seen in bug 11334. We need to fix that first then I can look at roaming code again. Punting to next release.
*** Bug 12062 has been marked as a duplicate of this bug. ***
I have had a good play with r5577 and can say that my SBC roams nicely between the two access points in my house. I have checked, and the BSSID changes as I move between areas. Thanks for getting this working. Keith
i am curious... in general, if you have two access points, should they have differing SSID's, or couldn't they both have the same SSID? i realize that for troubleshooting its probably easier to have differing ones, but is there a reason to do it beyond that?
Same network should have the same SSID so roaming is possible. You can still differentiate which AC you're connected to based on the BSSID or MAC address.
The more interesting question, at least to me, is should the WAPs be set to the same radio channel. I have seen many discussions on this with no firm reasoning one way or the other. It might depend on antenna patterns, degree of field overlaps, and relative signal strengths. One of these days I will get another pakedge WAP that have a somewhat proprietary methodology (WDS) for handing clients off between multiple WAPS as signal strength changes. The Pakedge WAP is IMHO the best one out there but it is not cheap.
Same channel means the Access Points will interfere when within range of each other. Of course this is kept to a minimum so same channel shouldn't be as much of an issue, but obviously there will be some overlap. I vote same SSID and non-interfering channels for multiple WAP networks.
FWIW, I've spent alot of time recently experimenting with my dual-Airport Extreme setup at home to improve the wireless signal. Although I'm running SqueezeCenter 7.4, I found that the Controller 7.4 firmwares just really hated my wireless setup. The best setup I have found now is to have two Airport Extremes hooked up via Ethernet. The "primary" one is setup with 5GHz and 2.4GHz on the same SSID using WPA2 passwords. The "secondary" one is setup with 2.4Ghz only on the same SSID using the same WPA2 password. Both routers have Multicast set to the lowest rate for the highest possible WiFi coverage. The primary routers TX power is set to 100%, the secondary one is set to 50%. As soon as I enabled two airports with the same SSID I noticed that my Jives (two of them) saw the Wifi signal quality drop significantly. The SNR is very low in most parts of the house (20-25) unless your standing right next to the primary airport, then it goes up into the high 50's. Even though the signal quality is much worse now on both jives (both 7.4 and 7.3 firmwares), there is some progress... they both will jump from one airport to the other as soon as the signal completely fails. Although its not completely seamless, its not too bad. It takes about 15 seconds with no signal for the jive to jump onto the new airport and get an IP address again. This is a huge improvement compared to the older firmwares, and is making up for the very odd signal quality problems that I'm seeing. (on a side note, EVERY other device in my house gets near 100% signal after the adjustment to the airports ... so I suspect there is still some issue going on with the jives. They used to have much better signal quality when I only had one airport -- it just didnt cover the whole house).
Reset priority before triage.
this is an administrative shuffle on priority fields to help make better judgment on the top end of the priority list. P4->P5, P3->P4, and P2->P3.
While we're waiting for a fix, is there anything that can be built into the controller to "force" it to look for a channel with a stronger signal? A rescan of the network simply finds the weaker signal again - I figure this is cached somewhere on the controller, and used as the preferred channel no matter what. My controller will hang on to a previous channel through several reboots, despite being adjacent to another access point with a far better signal. I'm using the recommended set-up of same SSID on different wireless channels, and have three access points to cover my property. The only way I can get it to reliably switch is to advertise a different SSID on each AP and manually change when I move from room to room - not ideal. A fix to this would be great so the controller roams properly, but without that a simple way to clear the controller's memory of the last channel and take another look at what's there to re-home would make roaming a little easier for those of us with this problem. Also, some diags of what channel the controller is currently using would be useful to help troubleshoot this - may already be there, but I can't find it. Happy to act as guinea pig for any further testing needed.
this works for me: settings->advanced->networking->choose network my current ssid appears in the list select it (press button) at that point, my controller switches to the best AP
Things are much better with the latest firmware(s) please make sure you are up to date with 7.4.1 r7915
Sorry, should have explained this a little better. Choosing, SSID is fine as you describe Marc, but it doesn't tell you which wireless channel it's using. In my scenario I'm attempting to roam between multiple wireless access points on different channels with the same SSID. So, it lists the SSID correctly, but it hangs on to the signal from the access point on the other side of the house (where it was last used) despite being inches away from a different AP with a way stronger signal on the same SSID (but different wireless channel). It still uses the weaker signal through several reboots Being able to interrogate both SSID & channel would be helpful, but ideally the controller should monitor channel strength and fail over gracefully (in the same way as an iPod touch does for instance) I'm on 7.4.1 r7915, and unfortunately this seems to be less stable in my case than 7.3 was.
I have exactly the same setup - two AP's, different channels, same SSID. One of my AP's (linksys) will tell me what mac addresses are associated, so I can tell which one the controller is talking to. If I bring the controller near to the AP is is NOT using, it does not roam, of course. When I go the networking and press choose network, I get a display indicating it is searching for networks. At that point, the controller switches to the new AP. Are you sure both AP's are configured correctly - same security settings, and if in use, correct mac filters? Has the controller been proven to be able to connect to both? (Temporarily change the SSID of one to experiment).
I can get on to all AP's separately with no problems under different SSID's. I've since had an oddity where the temporary SSID's I was using for testing that have since been deleted from the AP's still appear on the controller as "phantom" networks (even through a controller reboot) I'm now going back to basics - I've reloaded the firmware to the controller & set it back to factory settings & put all AP's back to the same SSID. I'll give it a thorough test tonight\tomorrow and report back with my findings. Thanks for all your help & suggestions - much appreciated.
Update to my update. My controller does not reliably connect to best AP unless I actually reselect my ssid on the choose network page. It does sometimes, but not always.
After much head-scratching I discovered an inconsistent wireless security configuration between the AP's. Two were set to WPA2(PSK) and one was set to WPA(PSK) - I figure the controller wasn't happy being constantly asked to authenticate in different ways. I dropped them all to WPA(PSK) and the connection can now be forced over to the stronger signal with a quick scan using the "choose network" function as Marc describes. This isn't 100% reliable, as it still sometimes finds the weaker signal, but a quick "I don't see my network" and another search seems to do the trick. I'll revisit this when I get some time by changing all the AP's to WPA2(PSK) as I'd rather run with the stronger encryption, but for now I'm just happy there's a consistent way to get this working in the absence of built in roaming.
Roaming of the controller has become difficult to test because there seems to be no way of viewing your connected BSSID (not SSID) anymore. I think it disspeared in v7.4.x - it used to be possible in v7.3.x.
It has moved in 7.4.x to Settings > Advanced > Diagnostics
(In reply to comment #56) > It has moved in 7.4.x to Settings > Advanced > Diagnostics The BSSID is not available in that location. Enhancement request filed at your request in Bug#15124.
I am having similar experiences. The controller will only connect to the stronger signal when the signal drops altogethers - which forces it to reconnect to both the wireless network and the Squeezebox Server. My setup is two Draytek APs, with matching SSIDs and channels, using WPA2 encryption - not sure what the answer is to the "same or different" channel debate but my APs will only do WDS on the same channel. So this is probably down to specific hardware and/or configuration. In this setup I would expect the controller to periodically check for available APs with the same SSID and move to the one with the strongest signal. This would not require it to reconnect to the network or Squeezebox Server. My netbook & laptop do this and the process is seamless - I can download a large file while walking around the house and the download continues while the laptop's wireless connection swaps back and forth between APs (using WirelessMon to monitor).
I've just installed an access-point connected to a Netgear switch with a wired connection back to my main wireless router, which in turn has a wired connection to my PC, the idea being to improve coverage in my house. My house has full network cabling so I can put access points pretty much anywhere. My Controller will connect to both the access point and the main wireless router quite happily (they share SSIDs etc), which I can verify by looking at the Devices connections in the router's system menu, to confirm how the Controller is connecting to the PC. But unlike my laptop, it will not roam. It will change to a more sensible connection if I switch the Controller off and back on, but I'd expect it to do this automatically. I will not purchase an extra Controller. And, as I'm about to look at really extending the music provision for the house through purchase of additional receivers, a controller with reliable roaming would be very helpful. I'm beginning to doubt whether the Squeezebox Duet set-up is really that scaleable, and so am beginning to think I should research other suppliers. Would be great if this could get fixed.
Seems that my WDS problem has to do with this!
Looks like this applies to the Radio too. http://forums.slimdevices.com/showthread.php?94914-SqueezeBox-Radio-and-Home-Server-over-2-wireless-routers