Ron F. wrote:
> The third rule limits the broadcast of a UPNP SSDP M-SEARCH packet to
> just one by dropping any such additional packet destined for output that
> has the (ip, port) pair, (or tuple as I have seen experts call it,) of
> (239.255.255.250, 1900) after the first such packet has been seen and
> registered in the ipset upnp - until the timeout period has expired!
> This rule looks for a match of this tuple to what has been saved in
> ipset upnp. When the timeout occurs, what is in the upnp set is dumped,
> and we start over. One broadcast packet should be enough to gather
> responses from all you upnp media renderers that respond to it, which is
> one reason I made the timeout to be 6 seconds. It might not be necessary
> to do this, and this is the least important rule we are adding - I just
> wanted a very clean method of conducting the procedure of collecting
> media renderers.
>
> I have found that for something complicated like what we have been doing
> here, that ufw, which is a simplified interface to iptables, and gufw,
> which is a GUI interface to ufw - are problematic. I have been using
> iptables directly, albeit I find that it can take a long time for
> iptables to list all the rules this way in a specified chain, and even
> longer to list all rules in all chains.
>
> ...
>
> OK, the question regarding the use of port 1900...
> Port 1900 is being used for outgoing UPnP SSDP broadcasts, and it can
> also be used by media renderers to broadcast their availability, but I
> think UPnPBridge is not using it for this purpose - at least not when
> running on a Linux-based machine. It is listening instead on whatever
> host source port was used in it's own broadcast. Given that, I am not
> sure how useful it is to have it open for INPUT to begin with.
>
> Additionally, I found that some Chromium-based browsers will also
> broadcast using port 1900! If we have used ipset to dynamically open
> ports to receive SSDP packets, then more ports get opened that we did
> not anticipate! This might not cause a problem but I don't like it, as
> it was an unexpected consequence of what we had set out to accomplish
> here. This was my reason for adding a rule to drop outgoing SSDP
> broadcasts that contain a user agent.
>
> Please note: I typed a lot of info in this post, and I make mistakes and
> blunders. If I made a mistake here, please forgive. I am not an IT
> professional, and I don't even play one on TV. I recommend duplicating
> my research before making such permanent changes to your own firewall.
>
> I am still engaged in investigation myself.
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.
Code:
--------------------
-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?
LMS 7.9.2 on PC, Xubuntu 18.04, FLACs 16->24 bit, 44.1->192kbps. 2
Touchs & EDO.
LMS plugin UPnP/DLNA Bridge to MF M1 CLiC (A308CR amp & ESLs) & Marantz
CR603 UPnP renderers.
Also Minimserver & Upplay to same & to upmpdcli/mpd PC renderers.
Squeezelite to Meridian USB Explorer DAC to PC speakers/headphones.
Wireless Xubuntu 18.04 laptop firefox/upplay or Android 'phone with
Squeeze-Commander/BubbleUPnP controls LMS/Minimserver.
------------------------------------------------------------------------
PasTim's Profile: http://forums.slimdevices.com/member.php?userid=41642
View this thread: http://forums.slimdevices.com/showthread.php?t=103728
_______________________________________________
plugins mailing list
plugins@lists.slimdevices.com
http://lists.slimdevices.com/mailman/listinfo/plugins
