Bugzilla – Bug 8618
Cannot connect to SqueezeNetwork probably due to Airport Extreme
Last modified: 2012-02-27 17:33:14 UTC
The problem is when you select SN as music source, it just goes "connecting" until it fails. There is no pin # or anything. It is probably blocked by the airport extreme(maybe udp or non common tcp ports blocked by default ?). I heared from several different people that their SB stopped working with SN as soon as they installed an airport extreme. I didnt have the time to fully scan and test the router over there, so we installed a Netgear NAS in the basement and got it work through SC that way, and I dont have an airport extreme here to test. I'll see if I can get one. It would be nice though if you have experience with the airport . I was using SC7.01 (and 2448 on sbc) and the problem wasnt with switching from SC to SN as I tried to connect to SN first a few times, and since that didnt work I then tried SC, which worked .. And the airport was also updated to the latest fm. Quick correction I did connect it once to SC to perform the update to 2448 before going to do the installation on one unit, and did a factory reset. I then tried with older and newer firmwares with the same problem. In the end I left it on 2448 with SC on a NAS in the basement .. I also tried it with 2 other devices, one of them fresh out of the box, and had the same problem. I tried all 3 from another location and they were all working fine with SN ..
I would be astounded if there was something about the Airport Extreme that allowed a Squeezebox controller to connect to the network, but not to the SqueezeNetwork servers. The primary advantage of using ethernet and 802.11b/g: once you're on the network, the network obeys the laws of networks. If a PC on the network can connect to SqueezeNetwork there is absolutely no reason the Controller shouldn't be able to. I'm not saying this to say we aren't going to look at this, because we certainly are. It also sounds like you've been thorough, which puts you head-and-shoulders above many bug submitters. All I'm saying is this seems very likely to be something other than another incompatibility with the Airport Extreme. I'm just not sure what yet.
Thanks for your comments Christopher. Correct me if I'm wrong, but when you go to SN in a browser you just use a common tcp80 port, and if I connect to SC it will discover it on udp 3483, connect and stream through tcp 3483, send infos through tcp 9000 all on the LAN. It will then play music from the internal drive or network, and internet radios through whatever port they are on (Maybe the radios I tried where on port 80, I didnt try them all). So until then no udp and only tcp port 80 used in direction of the WAN, and the music is working fine. Whereas with SN you'd have to connect to another tcp port then 80. This could be a problem, although it does sound weird that the airport express would do that, it is possible .. I just remembered though that in the mail I sent to Dan, I think I also mentionned that it gave an error message that it couldnt find www.squeezenetwork.com when I tried to access mp3tunes through SC. I was able however to ping SN from SC, so no DNS pb from SBC apparently, but more probably a connection problem. How does the connection process works from SBD to SN ? I found this in the SBC code: from /usr/share/jive/jive/slim/SlimServers.lua, which would indicate that it connects on port 9000 ? is that the only required port other than 80 to play SBD through SN ? ".. function _discover(self) log:debug("SlimServers:discover()") -- Broadcast discovery for _, address in pairs(self.poll) do log:debug("sending to address ", address) self.js:send(t_source, address, PORT) end -- Special case Squeezenetwork if self.jnt:getUUID() then _cacheServer(self, self.jnt:getSNHostname(), 9000, "SqueezeNetw ork") end .." I also looked (grep -rn :) for 3483, but I only saw a reference in that same file, it was alocated to the local PORT variable, which was used only with SC .. ?
I borrowed an airport extreme from the local MAC store here. Connecting to SN works fine even switching between SC and SN works fine with SC7.01 and 2448 when I was in bridge mode. However when I changed the airport express to router mode (NAT), I wasn't able to connect Duet to SN anymore (SC works fine). I guess this is the mode most people use .. A weird thing I noticed is that the airport gave 169.254.x.x ips to SBC and SBR, and from the airport conf it should have given a 10.0.x.x ip. Other than that it connects ok, I can ssh on the remote on that ip from a 192.168.x.x lan, and I can ping the other machines in the 192.168.x.x lan. I did notice from the remote though that: (if nslookup without giving a dns ip it just shows 0.0.0.0 as dns server) # nslookup www.google.com 192.168.1.1 Server: 192.168.1.1 Address 1: 192.168.1.1 nslookup: can't resolve 'www.google.com' # ping 192.168.1.1 PING 192.168.1.1 (192.168.1.1): 56 data bytes --- 192.168.1.1 ping statistics --- 4 packets transmitted, 0 packets received, 100% packet loss # ping 192.168.1.6 PING 192.168.1.6 (192.168.1.6): 56 data bytes 64 bytes from 192.168.1.6: seq=0 ttl=64 time=91.336 ms And 192.168.1.1 works fine as a DNS and gw from 192.168.1.6 . But somehow 192.168.1.1 can't be reached from the 169.254.x.x lan but 192.168.1.6 can ?! route infos: # route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0 0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 eth0 usually 0.0.0.0 dest should have the gw ip in gw?! I tried to add a default gateway to the 192.168.1.1 default gateway but that didnt help still couldnt ping the gw or outside # route add default gateway 192.168.1.1 # route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0 0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 eth0 0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 eth0 # ping www.google.com ping: bad address 'www.google.com' # ping 192.168.1.1 PING 192.168.1.1 (192.168.1.1): 56 data bytes --- 192.168.1.1 ping statistics --- 2 packets transmitted, 0 packets received, 100% packet loss # ping 192.168.1.6 PING 192.168.1.6 (192.168.1.6): 56 data bytes 64 bytes from 192.168.1.6: seq=0 ttl=64 time=143.437 ms 64 bytes from 192.168.1.6: seq=1 ttl=64 time=363.485 ms --- 192.168.1.6 ping statistics --- 2 packets transmitted, 2 packets received, 0% packet loss round-trip min/avg/max = 143.437/253.461/363.485 ms # ping 212.40.5.50 PING 212.40.5.50 (212.40.5.50): 56 data bytes --- 212.40.5.50 ping statistics --- 2 packets transmitted, 0 packets received, 100% packet loss At the installation place I could ping the gw or outside, just not connect to tcp port 9000 (or whatever other port) to SN. But this might show already that the airport isn't 'always' working correctly in router mode .. ?! I'll test some more after lunch ..
ok. It might not handle "double NAT". It apparently needs a public IP in order to do NAT correctly. I can't test that here now ..
Felix, should this have been addressed in bug 7415?
Dan, the fix for bug 7415 was only for SB Classic, SB Receiver and Transporter and I believe QA also tested SB Controller with SB Receiver. Maybe some wired combination of settings in Airport Extreme causes this bug?
bug 7415 talks about connecting to time capsule wifi. There is no problem connecting to the wifi here. The problem is the connexion to SN .. Ok I was able to force the airport express through the double nat error. ...and able to connect Duet right away to SN. So I wasn't able to reproduce the error in bridge or NAT mode .. I wonder if its not related to some providers that offer firewall services to their users .. with or without them knowing about it .. ?
I meant Airport extreme and not express...
Steven: Can you have a look at this please.
Remco, are you still having issues using your Duet directly with SqueezeNetwork on your Airport Extreme? Looking through your comments it seems that your Duet was not getting proper IP and DNS address from your Airport Extreme and possibly falling back to using self assigned addresses in the process. This could result in Duet being unable to connect directly to SqueezeNetwork but still function normally with a SqueezeCenter on the local network. This all sounds like an Airport Extreme configuration issue and not a Duet issue to me and I am inclined to close this as works for me. Dan, have you had any reports similar to this one?
Closing this as works for me. If you still see this issue please reopen and add additional comments.
Closing resolved bugs - if you feel this bug still exists please first re-test with the latest SW/FW version. If you are able to reproduce then feel free to reopen and attach new logs / steps to reproduce.