Bugzilla – Bug 3625
Confusing message indicates discovery failure
Last modified: 2011-03-16 04:39:17 UTC
I recently upgraded from 6.0.2 to 6.2.2 and switched from a Debian Stable (Woody) to a Gentoo system for storing my music files. My playing device is an orginal Squeezebox. After making the switch I was unable to discover the Squeezebox with SlimServer. After tracing the discovery sequence for both 6.0.2 and 6.2.2 I noticed that the discovery reply from the server includes the hostname of the server and that the only discernable difference between the two discovery replies was the system name. For 6.2.2, I could see the discovery request from the Squeezebox reaching the Slimserver, and the Slimserver's reply (I can make the Wireshark trace available if you would like), but the Squeezebox never tried to open the necessary TCP/IP socket. When I edit the Discovery.pm file to hardcode a 4 digit hostname, the discovery sequence works. My belief is that there is an error in the way Discovery.pm formats the reply that is causing my Squeezebox to ignore the reply. The documentation states the message should look like: 'D' - Discovery response Field Value/Description 0 'D' as in "discovery" 1 reserved 2..5 server's IP address, or 0.0.0.0 6..7 server's port 8..17 reserved Both 6.0.2 and 6.2.2 appear to be violating this definition by using the system's hostname rather then the server's IP address. When you look at a discovery packet using the SLIMP3 protocol analyzer included with Wireshark, it displays an IP address for the field (and a wrong one at that), but if you look at the data section, you can see the hostname is sent instead of the IP address. Examining Discovery.pm, that is exactly what the code appears to do. All works fine as long as the hostname is less than 4 characters, but as soon as the hostname is longer than that, the reserved bytes are written with information other than zero and the Squeezebox doesn't recognize the Discovery acknowledgement. Additionally, since the information in bytes 2 through 5 of the message are never the correct IP address, it would appear that the Squeezebox doesn't actually use this information to make the subsequent TCP/IP connection.
Richard, were you looking at an issue that may or may not be related to this?
Mark, could you please attach the traces to the bug report. Thanks.
Created attachment 1346 [details] A Tcpdump trace where the discovery protocol works because I've hardcoded the hostname to be "disk" in Discovery.pm
Created attachment 1347 [details] A Failed Discovery Sequence using an unmodified Discovery.pm
Mark, thanks for the network traces. The discovery responses you seen in the trace are correct, for Squeezebox and later models the packets include the server hostname (just the first 16 characters) and not the ip address/port number. The documentation (and wireshark disector) are out of date. It is not clear to me from the traces why this is not working with the hostname 'scooby'. Chris, can you try to recreate this please?
Okay let's take it back to basics. First, I should point out that since you seem to be the only person having this problem, that if you're okay with your hacked Discovery.pm workaround, then that may be our solution. Slimserver 6.2.2 was out for a long time, and since you're running it after the release of 6.3.0, I'm guessing you have a (perfectly reasonable) philosophical preference for older, stable releases. Therefore I'm reluctant to ask you to upgrade past your comfort zone. Factor in the notion that we're currently spending our development effort on the 6.5 beta. It's nothing personal, but it's pretty unlikely we'd decide to go back and fix a bug in 6.2.2, if that's what this turns out to be. With that said, I would like to understand this issue. It does _sound_ like a bug from your description. The only thing that gives me pause is that we have many SB1 users, and they used 6.2.2 for a good long time, and nobody previously reported it. If you're interested in continuing to try to figure this out, I'd like to verify what firmware version you have on your SB1. This is available under settings -> information -> player information if you're connected to a slimserver, or from the settings menu if you're not. The latest firmware for the SB1 is version 40. Is your unit using a wired or wireless network connection? I'd also like to verify how you're seeing the lack of discovery. I assume you're going to 'Setup networking' -> selecting wired or wireless -> connecting okay to your wireless router or wired ethernet and getting an ip address? -> Showing the 'Looking for Slimserver...' message, then saying it couldn't find one and asking for an IP address for the server? Does it work okay if you give it the Slimserver static IP address? Please let me know how you'd like to proceed.
Thanks for your help. I did a little more testing and found an important conjunction to make the problem happen. I also tested with 6.3.1 on Linux and Windows and saw it happen in both places. To make the problem happen: i. Start Slimserver. ii. Plug in the Slimserver 1 (SS1). iii. When it asks it you want to set up the network, hit the down arrow until it shows Done with setup. iv. Hit the right arrow to start the discovery. The above sequence is how I conducted the traces. However, the following sequence causes the it to work properly: i. Start Slimserver. ii. Plug in the SS1. iii. When it asks to set up the network, right arrow through all the ethernet settings (leaving them the same as before). iv. When it asks to "select your slimserver" select scooby. My guess is that the NVRAM on the device is saving not only the ip addresses, but the name of the Slimserver it last used. It wasn't the fact that I changed the hostname to four characters that solved the problem, but rather I changed it to the one the slimserver "remembered" that it was supposed to talk with. Unfortunately, the fact that the SS! appeared to be conducting a discovery for the slimserver confused me into thinking it would talk with any. If it had tried to speak directly with the old one, it would have been clearer what the problem was.
aha! I'll change this bug to be a SB1 firmware bug, then. However, for any other customers stumbling across this bug, as I mentioned, chances are very slim it will ever get fixed.