Bugzilla – Bug 14789
don't connect to SC/SBS instances that are not supported (password protected server)
Last modified: 2011-11-06 23:24:26 UTC
My Radio's Switch Library menu always shows two local servers. One is my SBS 7.4.x server; the other is an SC 7.3 server. I haven't bothered to read up on mDNS/Rendezvous, but I think the SP clients should be smart enough not to offer to connect to servers that are too old. Outside mDNS/Rendezvous, you could simply have SBS include an X-Squeezebox-Server-Version response header and have the SB client not list any SC/SBS instance that omits that response header or has an incompatible value. Even servers that have username/password auth enabled could freely disclose their SBS version number. The HTTP response header approach would also work for those whose firewalls block the discovery process and manually enter SBS server addresses.
This has been an issue for a long time, even with ip3k clients. But I haven't noticed any problems recently with Touch and Radio. I'm constantly bringing different servers online and shutting them down and the Switch Library list is always fresh. For the most part it should only offer to connect with servers that are online. But you don't want to drop known servers _too_ quickly or intermittent problems may prevent some servers from being listed. Remote servers should probably always be listed. If a server has been added via Settings > Advanced > Networking > Remote Libraries, then list it until the user removes it.
The list is fresh, it just includes servers running older versions of SqueezeCenter that the SqueezePlay client should not connect to. E.G., Radio should only list servers running SBS >= 7.4. Radio should never try to connect to any servers running SC 7.3 or older.
If you try to connect a player to an older server that can not support it, the player will display a message stating such. Not showing a server may confuse some of out more 'typical' customers more then what currently happens. Also, I don't know how many of our Radio customers will be running multiple servers in their environment. I'll mark this bug as Future for now, to let the debate on the merits of this enhancement request to continue.
"If you try to connect a player to an older server that can not support it, the player will display a message stating such." That sounds like a nice idea (though it would waste a user's time if the old server needed a username & password), but it's not what I see with Radio firmware 7.4.1 r7866. If I select the SC 7.3 host, Radio prompts me for the login info, and then shows a screen with "Software Update" in the title bar and one option labeled "Help". When selected, this item tells me to contact Logitech support, and to be prepared to share all the technical gobbledygook info from the Diagnostics page. And the Diagnostics page says nothing about the version of the SC instance I'm trying to connect to.
OH, that may be a bug then, if you turn password protection off (power cycle your radio after you do that) do you get the 'I cant connect to that server' message? If so, then file a separate bug for password protected server fails to block connection properly.
...and if I back out of the Software Update page, it actually seems that I can use my 7.3 host; at least I've been able to browse my 7.3 collection and queue up an album. Volume control is a little weird (likely due to the change in the CLI for mixer volume in SBS 7.4), and the text+icon layouts are messed up. Who knows what else I'll run into.
Peter: comment 6 is bug 14421
Re: comment 5. 1st attempt, having already connected to the 7.3 server, I turned off password security and cleanly (power -> Goodbye + power -> boot) cycled Radio. It brought me back to the software update screen described in comment 4. 2nd attempt: leaving Radio up, I started a 7.4.0 instance and used Switch Library to connect to it. I left-arrowed out of the firmware update screen (Radio is running 7.4.1 firmware) and chose Switch Library. This time I got the message you describe. 3rd: powered down Radio via button, rebooted it. Got the firmware update screen again (guess it remembered the 7.4.0 server). Left arrow + Switch Library -> proper warning screen. So your analysis is spot-on. Password protected SBS instances are not handled properly. I still think the architectural solution proposed in this request is a better fix. Entering credentials on Radio is a hassle. Make the gear smart enough to know not to ask me to log in to a server it shouldn't connect to. Let me amend my proposal: detect servers that are "too old" and display the message described in comment 5 *before* prompting for username and password.
Michael: would this be yours to address?
This is not behaving as James described in his comment #3. When trying to connect a Baby to a 7.3.x server, the player is telling me "We couldn't connect to serverxyz. Make sure your computer is turned on and connected to wyour local network, and that Squeezebox Server is currently running.". This is wrong. SP should tell the user that it's trying to connect to an incompatible version. This is a SP bug, not SBS. We can't fix old software versions already installed on the user's computer.
Michael, there's a usability problem with the current system. If SC/SBS is password-protected, SqueezePlay cannot ascertain whether SC/SBS is compatible until the user enters their username/password. If SBS included its version info in its HTTP response headers, SqueezePlay could see that info even without authenticating the user. If missing, obviously it's an older version of SC/SBS, and incompatible. If present, SP could decide if the server was compatible before asking the user to enter login credentials.
Michael: Please open a new bug on your findings, that is not in the scope of this bug. Is the bug yours to address? or Tom's?
I've split the 'user gets wrong error message about old server version' bug into a separate issue in bug 14835. Let's continue to focus on the username/password issue in this bug. Thanks!
Reverting description to what it used to be...
Moving lower-priority bugs to next target
Tom is no longer available to us
Unassigned bugs cannot have a priority.