Bugzilla – Bug 16057
Firewall issue during "serverdiscovery" Opening ports as suggested in manual is not enough
Last modified: 2011-08-23 06:18:36 UTC
Created attachment 6771 [details] iptables -L from my server I finaly got me a Touch. I have a long standing problem with all Squeezeplay based devices way of finding the server since I got my controller, this persist with desktop Squeezeplay on any OS . So i can reproduce this with Squeezeplay Controller Radio and now Touch. Fault description: When I setup my Touch and after the mysb.com stuff I choose to go to my music, normally this should make your Touch/Radio/controller/squeezeplay find your local library instead i get the "install sqeezebox server bla bla message" If I then disable the servers firewall it works splendidly, I can then activate my firewall again and all works just fine. Until next reboot then it cant find my library again ? My workaround that works 100% is this: On any squeezeplay device I go to. Settings > Advanced > Networking > Remote Libraries > Add New Library Here I set my servers ip number 192.168.1.5 From this point it's works perfect the device always find the library and most important I can do this with my firewall on, it works indefinitely. My controller(s) is prof of that, since 2008 at least Here is the ports that are open on my server: TCP 9090 UDP 9090 TCP 9092 UDP 9092 TCP 3483 UDP 3483 TCP 9000 UDP 9000 And the diagnostic display in any Squeezeplay device looks just as it should do. Server is ClarkConnect 4.2 ersion: 7.6.0 - r30558 @ Tue Apr 13 02:05:20 MDT 2010 Hostname: hal.home.lan IP: 192.168.1.5 HTTP Port: 9000 OS: Red Hat - EN - utf8 Platform: i686-linux Perl Version: 5.8.8 - i686-linux-thread-multi Database Version: DBD::SQLite 1.29 (sqlite 3.6.22) Total Players Recognized: 3 The firewall is what came with the linux kernel, It's configured trough cc4.2 web-UI Everything in my network has static-IP the dhcp server in my router is confined to adresses above .100 . If you misstrust ClarkConnects web-UI I attach a file with ther iptables -L output. Some linux wiz might see whats wrong in it. Clearly open port 3483 and 9000 is not all that it takes to get the server discovery trough the firewall
I suspect your firewall software isn't really opening those ports -- see http://forums.slimdevices.com/showpost.php?p=534369&postcount=5 You should try something like iptables -I INPUT -p udp --dport 3483 -j ACCEPT iptables -I INPUT -p tcp --dport 3483 -j ACCEPT to prepend rules that will accept broadcast packets, and see if that solves the problem. If not, you might want to add a line toward the end of your INPUT chain (just before that DROP rule) that sends packets to the LOG chain so you can see more about what's being rejected. BTW, where is this manual of which you speak? Perhaps it would benefit from a slight edit noting that your firewall needs to allow *broadcast* packets to port 3483, if it does not do so already.
Created attachment 6772 [details] iptables -L -v -n Ok heres another attachment. It really opens port 9000 as the web-UI works from allover my network ? I don't know how to make lasting changes to my firewall should i put that example in a script somewhere ? The UI is simple add a port choose TCP or UDP thats it nothing about broadcast or anything like that ?
tried the rules you kindly suggested they work. iptables -I INPUT -p udp --dport 3483 -j ACCEPT iptables -I INPUT -p tcp --dport 3483 -j ACCEPT will they survive a reboot of the server ? I think not ? Does a typicall windows firewall automagically accepts "broadcast packets at 255.255.255.255" ? what did I just do ?
Ok so both source and destination "0.0.0.0/0" will make the port open for broadcast
adding the suggested rules to the file rc.firewall.local In ClarkConnect 4.2 did it thanks. One of the quirks with ClarkConnect it's made for routers and servers. Firestarter in Ubuntu makes the portsettings with destinations 0.0.0.0/0 Much more user friendly. This explains why my samba share is so reclusive ;) you must know the ip you can not browse for it. Thanks again, for the linux lesson
*** Bug 16047 has been marked as a duplicate of this bug. ***
(In reply to comment #6) > *** Bug 16047 has been marked as a duplicate of this bug. *** I see the same thing, and NMAP shows 3483 as being open. jarmac:~ jar$ sudo nmap -n -sU -p 3480-3490 192.168.1.9 Starting Nmap 5.20 ( http://nmap.org ) at 2010-04-14 12:59 EDT Nmap scan report for 192.168.1.9 Host is up (0.00024s latency). PORT STATE SERVICE 3480/udp open|filtered unknown 3481/udp open|filtered unknown 3482/udp open|filtered unknown 3483/udp open|filtered unknown 3484/udp open|filtered unknown 3485/udp open|filtered unknown 3486/udp open|filtered unknown 3487/udp open|filtered unknown 3488/udp open|filtered unknown 3489/udp open|filtered unknown 3490/udp open|filtered unknown MAC Address: 00:22:68:66:D6:1B (Hon Hai Precision Ind. Co.) I also have things connected to 3483, so it must be open: tcpdump udp port 3483 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes 19:18:25.998894 IP jarmac.slim-devices > 255.255.255.255.slim-devices: UDP, length 16 19:18:29.000805 IP jarfx.slim-devices > 255.255.255.255.slim-devices: UDP, length 16 19:18:29.001587 IP jarmac.slim-devices > jarfx.slim-devices: UDP, length 21 19:18:39.746408 IP 192.168.1.112.filenet-tms > 255.255.255.255.slim-devices: UDP, length 37 19:18:39.753360 IP 192.168.1.112.filenet-tms > jarfx.slim-devices: UDP, length 37 19:18:39.753555 IP jarfx.slim-devices > 192.168.1.112.filenet-tms: UDP, length 71 19:19:25.998948 IP jarmac.slim-devices > 255.255.255.255.slim-devices: UDP, length 16 19:19:29.002516 IP jarfx.slim-devices > 255.255.255.255.slim-devices: UDP, length 16 19:19:29.003152 IP jarmac.slim-devices > jarfx.slim-devices: UDP, length 21 19:19:39.787344 IP 192.168.1.112.filenet-tms > 255.255.255.255.slim-devices: UDP, length 37 19:19:39.793802 IP 192.168.1.112.filenet-tms > jarfx.slim-devices: UDP, length 37 19:19:39.794011 IP jarfx.slim-devices > 192.168.1.112.filenet-tms: UDP, length 71 19:20:25.998971 IP jarmac.slim-devices > 255.255.255.255.slim-devices: UDP, length 16 19:20:29.003691 IP jarfx.slim-devices > 255.255.255.255.slim-devices: UDP, length 16 19:20:29.004531 IP jarmac.slim-devices > jarfx.slim-devices: UDP, length 21 19:20:39.830828 IP 192.168.1.112.filenet-tms > 255.255.255.255.slim-devices: UDP, length 37 19:20:39.837103 IP 192.168.1.112.filenet-tms > jarfx.slim-devices: UDP, length 37 19:20:39.837313 IP jarfx.slim-devices > 192.168.1.112.filenet-tms: UDP, length 71 19:21:25.998913 IP jarmac.slim-devices > 255.255.255.255.slim-devices: UDP, length 16 19:21:29.000742 IP jarfx.slim-devices > 255.255.255.255.slim-devices: UDP, length 16 19:21:29.001499 IP jarmac.slim-devices > jarfx.slim-devices: UDP, length 21 I used the same fix on Controller: Settings > Advanced > Networking > Remote Libraries > Add New Library But this should be on a menu accessible from the setup process. If Controller can't find any client, setup dies. I.e., you can't get past that point.
Yes the port is open *but* probably not for broadcast messages. So it will only listen if the player sendss something directly to <server ip> at port 3483 . What a squeezebox does is saying "hello" with a broadcast call at port 3483 any thing thast listening could then pick it up, but as my server was configured it would only do that if adressed directly. Try the "iptables -L -v -n" or"iptables -L" command Examples wrong (my servers is named hal ) "iptables -L" ACCEPT tcp -- anywhere hal.home.lan tcp dpt:3483 "iptables -L -v -n" ACCEPT tcp -- * * 0.0.0.0/0 192.168.1.5 tcp dpt:3483 Examples OK ! this is how it should look: "L" ACCEPT tcp -- anywhere anywhere tcp dpt:3483 "iptables -L -v -n" ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:3483 As I now understands it a port rule have "source" and "destination" settings . If destination and source is "anywhere" the server can see broadcast calls on that port. All Linux has virtually the same firewall built in to them what however differs is the interface various distros provides for users. The firewall itself accommodates endless configuration possibilities, real experts can do a lot of things with it and set any kind of weird rule they want. I Just used the rule provided by peter and found out where in my distro there is config file that you can put this rule in. Iptables is not an easy thing to use, but if you want you can configure the firewall with this tool only.
Mikael & James, is there written documentation somewhere that you think should be edited to make the firewall requirement more clear? Thanks.
Thinking about it, it's not that easy You have to get your head around quite a lot on how networking and "broadcast" works before even understanding the issue at hand. How to explain ? James did u get it ? But change all manuals to "open port 3483 udp/tcp make sure that the rule accepts broadcast's" or similar If that was in there it at least would get make think "what is broadcast" ? This will send you off googling and maybe you fix it. And it's it is only some linux distros ui that handles ports this way ? Is this abug with those firewall applications ? Is there a faq where we can document this. And also logitechs support should now, they got pretty stumped by this when i contacted them when setting up my duet
The OpenSUSE firewall GUI does not have a dpt:3483 option anywhere. I have never heard of it before. And, the current documentation that says "open 9000 and 3483 to TCP and UDP" is clearly inadequate. And OpenSUSE does not use iptables. It has its own SuSEfirewall2, which is what I need to configure. It may configure iptables. And I am still confused about what is broadcasting to what. Outgoing traffic is not blocked (I think) by my firewall, so the server should be able to announce itself to the world. Also, there is no easy way to test whether the configuration is working. # iptables -L -v -n | grep 3483 70 3940 LOG tcp -- * * 0.0.0.0/0 0.0.0.0/0 limit: avg 3/min burst 5 tcp dpt:3483 flags:0x17/0x02 LOG flags 6 level 4 prefix `SFW2-INext-ACC-TCP ' 78 5784 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:3483 11494 563K ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:3483 So, it would appear that I am configured properly I think.
Ok James so you seems to have onther bug too. Hopefully Peter would have any insight. I'm not that good at linux. Afaik, you can always use iptables even if the OS has another UI. Your own use of the command shows that it is installed. But figuring out where you should put these extra rules to try what worked for me. I'm not familiar enough with SUSE to say. But if you have a "rc.firewall.local" file on the system I'll would try there. Also I think it is the player that broadcast it's presence ? I'n my case the rule was set to only accept packet sent directly to my servers adress, that support this theory. In the meantime you could always add the server on the controller: Settings > Advanced > Networking > Remote Libraries > Add New Library For the reciever part you might need the net::udap script. If your unlucky Search the forum (scripts is done by robin bowes)
Well, I think the server is set up properly, and I have no control over the squeezebox or controller software. So I still think there is a bug in the server software, or else it is in the receiver's firmware. The see my Mac server, but not my Linux one. And, yes, by accident I found out how to add the library. But unless you jump through many hoops, (like adding controller ads a player), it is impossible to set up controller if your server is on Linux. Setup gets stuck when it looks for players.
I don't see the fix here. It is still an issue for me.
Created attachment 7420 [details] OpenSuSE firewall config file for squeezeboxserver This file contains configurations for OpenSuSE to set up the firewall correctly for squeezeboxserver.
sorry messed up my comment. The OpenSuSe firewall config file must be added in the directory /etc/sysconfig/SuSEfirewall2.d/services Once the file is there then squeezeboxserver can be selected as a service to be "opened" in the normal firewall yast2 GUI.
(In reply to comment #16) > sorry messed up my comment. > > The OpenSuSe firewall config file must be added in the directory > > /etc/sysconfig/SuSEfirewall2.d/services > > Once the file is there then squeezeboxserver can be selected as a service to be > "opened" in the normal firewall yast2 GUI. Finally a fix. I did it. Hope it works, but it should. I wonder why the standard SUSE firewall yast does not allow broadcast to be set.