I am trying to make some Wireless Speakers work I bought today.
I have a home server with two NICs (internal for WAN and external for LAN).
I installed the speaker, downloaded the app and I can install it properly.
The only thing I cannot make happen is streaming of internet radio stations.
I spoke to google and only found the following:
HEOS speakers and controllers (apps, professional controllers) require communication with each other. Therefore, specific ports must be opened to allow this communication:
80 : HTTP
554: RTSP
49152: MediaRenderer UPnP “listening”
49153: Configuration UPnP “listening”
49154: MediaServer UPnP “listening”
Open range between 50000 to 64999 for MediaRenderer and 60006 for Media Server.
Furthermore, all UPnP requires multicast access to the 239.255.255.250:1900 along with the appropriate IGMP messages and control for multicast.
How do I translate this into firewall-cmd?
1.) Adding service rtsp to my internal zone
2) Opening ports 50000-64999 (tcp, upd or both?)
3) Opening ports 49152, 49153, 49154 (tcp, udp or both?)
3.) What is multicast access to 39.255.255.250:1900 along with the appropriate IGMP messages and control for multicast?
First, is there a firewall on your WiFi router that is in play? I found this article as well (same source): https://support-uk.denon.com/app/answers/detail/a_id/1159/~/network-ports
It specifies the ports over the network that must be on and whether they are TCP or UDP, but, it isn’t the same list of ports that you have in the first article (which I also found and does not mention the port type, just the number.
If the article that I found is more specific to the firewall on your WiFi router and the link that you found is more specific to the firewall ports that need to be open on your machine (which I suspect) then you may need to play with both. Since there is no mention of which port types the link you found, I’d go with both. RTSP is a known service type.
As for the multicast and IGMP message control, you may have to add a rich rule for this. Take a look at this discussion. It’s a little old, but may still apply:
If you are like me and don’t want to allow ports needlessly, you can start with just the TCP rule types in the above firewalld rules, and then add in the UDP rules if the they are needed. My guess is that these are speakers, and that you will need connection and not connectionless ports (TCP rather than UDP), but that is just a guess.
It is not working.
What would be a good tool to monitor my network and report/monitor the dropped packages?
I looked at ethtool and netstat, but I believe none of them shows me realtim what is dropped.
Wolfgang,
It will depend on “where” the packets are being dropped. I’ve not used this feature of firewalld before, but you can try this to log denied traffic and see if that will give you a clue as to what is not being allowed:
I just made the test to confirm that the problem is related to the firewall. I stopped the server and activated the router from the ISP. And voila I could stream radio stations on the speakers.
I did already what you suggest, but did not find conclusive glues there. I found some packages dropped but don’t see from where they come I only see that they were dropped at my Wifi Router (identified through their IPs) that is connected to the LAN NIC of my server.
I have an Mesh Router and additionally two wireless super mesh points connected to it.
Their IP shows up when I run dmesg | grep -i REJECT
[AmpliFi HD Mesh Router – Amplifi Wi-Fi]
I cannot find in the app anything that is related to firewall. Nevertheless I will send them a note to see what they have to say.
I am still trying to figure this out. What is mist completely in the speaker’s instruction is was this sentence:
Furthermore, all UPnP requires multicast access to the 239.255.255.250:1900 along with the appropriate IGMP messages and control for multicast.
After doing quite some searching and readings I stumbled over a few threads that could bring me hopefully the breakthrough… But before keying in wanted to check with the experts…
Solution one:
Finally some time to further investigate an try. Still not working btw.
I opened all the ports mentioned in the thread here. I also created a upnp.xml service in /etc/firewalld/services/ (see above), but I still cannot stream.
I enabled package drop logging and find these rejected packages for I239.255.255.250.
Not sure why they show IN=ppp0 (my external NIC, connection to IPS) when the speakers are connected to the LAN NIC?
So sorry @Smoky ! Just realized that no one has responded to this. I’m not sure if the issue is still outstanding, but you should be able to allow all traffic on your LAN with a rule like this:
Technically, the rules being there wouldn’t necessarily foul things up, but I never want to have things there that don’t make sense anymore. (clutter = problems trying to figure out things later)
If you added any other rules to your “internal” zone, you will want to also remove those.
Hope this helps, or at least I hope you have your problem solved by now!
Steve
thanks for responding. And yes it is still outstanding and very very important! (ask my wife and kids…)
I tried what you said but no luck.
I removed all the ports mentioned in the script to “reset” the firewall so to speak.
I need to do something else first and will pick this it again
Still, I enabled logging of dropped packages.
Here is what I am seeing (udp packages only, I think this traffic is udp, right?)
IP 79.152.10.78 belongs to my Internet Service Provider Telefonica ESPANA; I got thousands of REJECTS in the file from this IP
IP 5.161.93.136 belongs to a data center operator
enp2s0 is my internal NIC
IP 239.255.255.250 is used for UPnP. I found this info:
Organization: Internet Assigned Numbers Authority (IANA)
RegDate: 1991-05-22
Updated: 2013-08-30
Comment: Addresses starting with a number between 224 and 239 are used for IP multicast. IP multicast is a technology for efficiently sending the same content to multiple destinations. It is commonly used for distributing financial information and video streams, among other things.
OrgName: Internet Assigned Numbers Authority
OrgId: IANA
So to make sure I’m understanding, the enp2s0 is assigned to your “internal” zone, is that correct?
You are correct that these dropped logged packets are UDP.
Is ppp0 assigned to any zone?
The reason I ask those questions, is by default, if the “internal” zone doesn’t have an interface assigned those packet drops are going to be coming from the default “public” zone. Do this to be sure that your interfaces are assigned to the correct zone:
Before you add any other rules, see if the dropped packets changes at all after doing the above.
Also, it might be helpful for you to list out both the “internal” and “public” zones so we can see if anything else might be missing. You can do this with:
enp2s0 is the LAN side and assigned to the internal zone
enp3s0 is the WAN side and assigned to external zone (ipv4.method disabled)
ppp0 is a pppoe connection linked to enp3s0 (pppoe.parent enp3s0)
I checked the IP addresses of the radios and when running nmap -sn I could not see them in the listed.
When you look at the picture. For whatever reason, the radios got an IP and DNS assigned, but no DNS.
I changed the mode from DHCP to manual and radios now work.
All other clients on the LAN work fine. Why would the system assign IP but not dns?
I’m so glad this is finally working! I’m assuming that your router serves DHCP and DNS? If so, I couldn’t answer that question. I’m glad that statically assigning those devices (which allows for the static assignment of the DNS) works though!
I’m assuming that your router serves DHCP and DNS? If so, I couldn’t answer that question. I’m glad that statically assigning those devices (which allows for the static assignment of the DNS) works though!