Announce: UPnPBridge = integrate UPnP/DLNA players with LMS (squeeze2upnp)

[Ron F.]

Hi Ron F. I created a script using ufw commands to get my firewall back to what I normally use, allowing various ports and source IPs for non-LMS activities. I then reset my ufw and iptables firewalls completely and started again, ran my script and saved all the settings. I have, for now, completely disabled IPv6 since I don't understand it properly (I have previously seen IPv6 exchanges on my home network and had no idea what they were about). I then ran the ipset command, one iptables OUTPUT and 4 iptables INPUT commands (one each for my 4 main UPnP devices using -s to specify the IPs). This all works reasonably predictably now, and I saved these additional settings.

Using iptables -S I have noticed that port 1900 is already open to all sending to the broadcast port, and this rule is before the INPUT --match-set rules we added. I clearly don't understand the rules well enough, since I thought the first matching rule ended the filtering, but that doesn't seem to be the case.

-A ufw-before-input -d 239.255.255.250/32 -p udp -m udp --dport 1900 -j ACCEPT

My brain hurt for a while trying to understand your technique for limiting the broadcasts, but I understand it now, and I don't think I really need to do this. Nor do I need to worry about browsers, since for the most part my music server runs headless.

Having got UPnP sorted, I looked at using my experimental airplay and chromecast players. They seem to be even less predictable in port usage than UPnP, but I only implemented them to see whether they were any better for my purpose. Neither currently now works having removed all my generic ALLOW 30000:60000 rules. I will keep looking, out of interest, but I won't try too hard!

Philippe - As to documenting this for others I'm really not sure I know enough to be precise enough to provide reliable solutions to people who know as little or even less than I do. I'd be quite interested to know what others have done on linux to get their systems working. Do they use any firewall at all?

Hi PasTim,

I think your use of an individual INPUT rule for each UPnP renderer using the "-s" option makes perfect sense. I am going to experiment using that too.

I believe the chain, ufw-before-input, are rules that are applied first, before the rules created by using the ufw app are applied.

I don't have any Airplay or Chromecast players currently, but I will try to look at what might be involved with Chromecast.

[PasTim]

Hi PasTim,

I think your use of an individual INPUT rule for each UPnP renderer using the "-s" option makes perfect sense. I am going to experiment using that too.

I believe the chain, ufw-before-input, are rules that are applied first, before the rules created by using the ufw app are applied.

I don't have any Airplay or Chromecast players currently, but I will try to look at what might be involved with Chromecast.

HI Ron F.,

Thanks. It turns out that Chromecast is much the same as UPnP, including matching the INPUT messages. I had mistakenly left out the Chromecast IP address from the 49152:49158 playing range allowance so it didn't play properly.

Airplay looks like a challenge for another day, or week. Apple seem to like to do things differently, and prefer not to tell anyone much about it.

[Ron F.]

HI Ron F.,

Thanks. It turns out that Chromecast is much the same as UPnP, including matching the INPUT messages. I had mistakenly left out the Chromecast IP address from the 49152:49158 playing range allowance so it didn't play properly.

Airplay looks like a challenge for another day, or week. Apple seem to like to do things differently, and prefer not to tell anyone much about it.

Hi PasTim,

I had originally added this rule, ports that might be used by UPnPBridge - 49152:49158, using gufw. In retrospect, in fitting with the rest of the rules we created using iptables; it seems more appropriate to do the same here; I think it can go anywhere and order is not important for this one:

sudo iptables -A INPUT -p udp -m multiport --dports 49152:49158 -j ACCEPT

If you are running a headless server, then you don't need to filter outgoing packets to get rid of SSDP broadcasts that contain a user-agent. My home server however is also driving my TV via an HDMI cable, so the browser is often running. In the final analysis, as you correctly pointed out, many of the rules I have been testing are optional and probably not necessary. The real improvement is done by using ipset to open INPUT ports temporarily, and only those ports.

I had an amusing outcome running BubbleUPnP as a media renderer on my mobile phone last night, having added the netfilter module psad to my firewall. After several days doing this, psad decided that the renderer was a bad actor, and created rules it added to iptables on my server to block all further communication with my phone! I don't know if the cause was the app itself, or coincidentally something else running on my Android device. Nevertheless, it appeared that something on my phone had begun a port scan of my server. I am going to figure out what is really going on here.

[philippe_44]

Philippe - As to documenting this for others I'm really not sure I know enough to be precise enough to provide reliable solutions to people who know as little or even less than I do. I'd be quite interested to know what others have done on linux to get their systems working. Do they use any firewall at all?

I don't know, but I suspect they don't.

On your conversation with Ron F. about CC and AirPlay, CC uses mDNS for discover, so a multicast on port 5353 (from memory) and then a dynamic webserver on port starting 49152 as well. AirPlay is a different anymal, it uses mDNS as well for discovery but then it opens 3 UDP ports for the player to use (data, timing, control) upon streaming start which are random at this point

[Ron F.]

Darn it, I forgot that we need to accept TCP packets from the UPnP renderer! I am not sure that we need UDP too, but just in case:

sudo iptables -A INPUT -p udp -m multiport --dports 49152:49158 -j ACCEPT
sudo iptables -A INPUT -p tcp -m multiport --dports 49152:49158 -j ACCEPT

[philippe_44]

Darn it, I forgot that we need to accept TCP packets from the UPnP renderer! I am not sure that we need UDP too, but just in case:

sudo iptables -A INPUT -p udp -m multiport --dports 49152:49158 -j ACCEPT
sudo iptables -A INPUT -p tcp -m multiport --dports 49152:49158 -j ACCEPT

No UDP is needed on this range, this is a webserver

[Ron F.]

No UDP is needed on this range, this is a webserver

Of course, I should have remembered that!

[Ron F.]

By the way philippe, your UPnP plugin is working very nicely - a great piece of work.

-Ron

[philippe_44]

By the way philippe, your UPnP plugin is working very nicely - a great piece of work.

-Ron

Thanks

I'm also trying to "recruit" people interested by my new project, that we do with @sle118.

Tell me if you are interested at some point https://github.com/philippe44/SqueezeAMP

[PasTim]

Thanks

I'm also trying to "recruit" people interested by my new project, that we do with @sle118.

Tell me if you are interested at some point https://github.com/philippe44/SqueezeAMP

Hi Philippe,

In the past I might well have been interested. However, I'm having to back off most things to do with music - my hearing is failing fast and music now often sounds distorted - so I try to maintain just a little technical interest in LMS and a few really good plugins like yours. I am finding other types of things to play with instead