Home of the Squeezebox™ & Transporter® network music players.
Page 256 of 283 FirstFirst ... 156206246254255256257258266 ... LastLast
Results 2,551 to 2,560 of 2826
  1. #2551
    Senior Member
    Join Date
    May 2006
    Location
    Silicon Valley
    Posts
    581
    Quote Originally Posted by PasTim View Post
    Thanks. It's really down to Ron F. for finding this in the first place.

    I'll have a think. I have a couple of details I want to look at further. I also don't know how applicable this solution is to other linux platforms, let alone Windoze.
    You can do this if you would like PasTim, but I am still testing as well. I want to make darn sure the interaction between the rules created to solve this port issue, and the existing rules originally created using ufw, is completely solved using your solution. I do think this solution will work on any Linux server, if netfiter's iptables and ipset are installed, but I doubt however that it will be of any relevance to Windoze. I have not owned one of those machines since 2007, and I don't know how it's firewall works. I could be mistaken, but isn't UPnP originally a Micro.... creation in the first place, so maybe their firewall handles it correctly to begin with?
    Living Room: SB Touch + DIY PSU > CI Audio VDA.2 DAC + VAC.1 PSU > VRX.1 cables > Emotiva XSP-1 Gen 2 preamp + XPA-DR2 amp > Blue Jeans cables > B&W 804 speakers
    Laptop: System76 Galago + Ubuntu 16.04 + Squeezelite + Vivaldi/Material Skin > Emotiva Little Ego DAC > Grado PS500 headphones
    Phone: Pixel 3a Phone + SB Player + Material web app > Bluetooth > Bose SoundLink Revolve
    Server: Puget Systems Serenity + Ubuntu 18.04 + LMS 8.0
    Music: Personal FLAC, Radio Paradise FLAC, Qobuz, Spotify

  2. #2552
    Senior Member
    Join Date
    Nov 2010
    Location
    Hertfordshire, UK
    Posts
    3,048
    Quote Originally Posted by Ron F. View Post
    You can do this if you would like PasTim, but I am still testing as well. I want to make darn sure the interaction between the rules created to solve this port issue, and the existing rules originally created using ufw, is completely solved using your solution. I do think this solution will work on any Linux server, if netfiter's iptables and ipset are installed, but I doubt however that it will be of any relevance to Windoze. I have not owned one of those machines since 2007, and I don't know how it's firewall works. I could be mistaken, but isn't UPnP originally a Micro.... creation in the first place, so maybe their firewall handles it correctly to begin with?
    I'm going to put this project to one side for a few days at least. It now seems that some of my UPnP renderers need this check for random 5 digits port numbers to be discovered, and some don't.

    I was trying to see if I could further qualify the devices that respond to the multicast to 239.255.255.250 by adding a "-s" (or possibly a "-m iprange") clause, and found that two out of my 3 UPnP renderers were found even without the INPUT clause at all. I am slightly unsure whether the -s clause works - the device that seems to need the INPUT clause seems to be somewhat temperamental in being discovered.

    As it stands all 3 of my devices work at the moment. If I recall correctly you are using a mobile. I have an LMS player on my mobile, so don't need UPnP for it. However, it might be useful for me to have another player to test. What renderer are you using?
    LMS 7.9.3 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.

  3. #2553
    Senior Member
    Join Date
    May 2006
    Location
    Silicon Valley
    Posts
    581
    Quote Originally Posted by PasTim View Post
    I'm going to put this project to one side for a few days at least. It now seems that some of my UPnP renderers need this check for random 5 digits port numbers to be discovered, and some don't.

    I was trying to see if I could further qualify the devices that respond to the multicast to 239.255.255.250 by adding a "-s" (or possibly a "-m iprange") clause, and found that two out of my 3 UPnP renderers were found even without the INPUT clause at all. I am slightly unsure whether the -s clause works - the device that seems to need the INPUT clause seems to be somewhat temperamental in being discovered.

    As it stands all 3 of my devices work at the moment. If I recall correctly you are using a mobile. I have an LMS player on my mobile, so don't need UPnP for it. However, it might be useful for me to have another player to test. What renderer are you using?
    Hi PasTim,

    I have been using the BubbleUPnP app on my Android phone as a mediarenderer, purely for testing purposes. I am doing this, because I have been considering purchasing a streaming DAC in the future, and before I spend any money, I wanted to know what all might be involved in getting it to work properly. I have been wondering if the original ipset timeout of 3 seconds, is simply too short? I want to do some experimentation with this, but since UPnPBridge is sending out an SSDP M-Search broadcast every 30 seconds or so, the window on the input port will be opening and closing, twice a minute. I imagine that is OK, just thinking about it.
    Living Room: SB Touch + DIY PSU > CI Audio VDA.2 DAC + VAC.1 PSU > VRX.1 cables > Emotiva XSP-1 Gen 2 preamp + XPA-DR2 amp > Blue Jeans cables > B&W 804 speakers
    Laptop: System76 Galago + Ubuntu 16.04 + Squeezelite + Vivaldi/Material Skin > Emotiva Little Ego DAC > Grado PS500 headphones
    Phone: Pixel 3a Phone + SB Player + Material web app > Bluetooth > Bose SoundLink Revolve
    Server: Puget Systems Serenity + Ubuntu 18.04 + LMS 8.0
    Music: Personal FLAC, Radio Paradise FLAC, Qobuz, Spotify

  4. #2554
    Senior Member
    Join Date
    May 2006
    Location
    Silicon Valley
    Posts
    581
    Quote Originally Posted by Ron F. View Post
    Hi PasTim,

    I have been using the BubbleUPnP app on my Android phone as a mediarenderer, purely for testing purposes. I am doing this, because I have been considering purchasing a streaming DAC in the future, and before I spend any money, I wanted to know what all might be involved in getting it to work properly. I have been wondering if the original ipset timeout of 3 seconds, is simply too short? I want to do some experimentation with this, but since UPnPBridge is sending out an SSDP M-Search broadcast every 30 seconds or so, the window on the input port will be opening and closing, twice a minute. I imagine that is OK, just thinking about it.
    Hi PasTim,

    I find that the position of the INPUT rule in iptables that refers to the ipset upnp, does not seem to matter. What does matter however is the position of the OUTPUT rule - still don't know why. I am also using a timeout for the set of 6 seconds now which seems to be working better. The one thing I would like to do however is have the set expire immediately after an SSDP Notify packet is received; there is no reason to keep the port open at that point! In other words, cause an immediate timeout. I don't know how to do that yet.

    Note: Using Wireshark to watch the communication between LMS/UPnPBridge and my mediarenderer, BubbleUPnP, I have noticed a couple of things:
    1. Sometimes it takes up to 8 seconds for BubbleUPnP to send the NOTIFY response back to UPnPBridge after it sends a SSDP M-Search broadcast! That is not good; it should be done in 1 second, so if we use a timeout of 3 seconds, set in ipset, we are going to have an issue right there.
    2. I see that when BubbleUPnP sends it's NOTIFY response, it might repeat it as many 100 times! Ouch again.
    3. I see that the server sends 4 SSDP M-Search messages approximately every 20 seconds, maybe BubbleUPnp is trying to generate responses to each of these broadcasts.

    -Ron
    Last edited by Ron F.; 2019-08-23 at 18:37.
    Living Room: SB Touch + DIY PSU > CI Audio VDA.2 DAC + VAC.1 PSU > VRX.1 cables > Emotiva XSP-1 Gen 2 preamp + XPA-DR2 amp > Blue Jeans cables > B&W 804 speakers
    Laptop: System76 Galago + Ubuntu 16.04 + Squeezelite + Vivaldi/Material Skin > Emotiva Little Ego DAC > Grado PS500 headphones
    Phone: Pixel 3a Phone + SB Player + Material web app > Bluetooth > Bose SoundLink Revolve
    Server: Puget Systems Serenity + Ubuntu 18.04 + LMS 8.0
    Music: Personal FLAC, Radio Paradise FLAC, Qobuz, Spotify

  5. #2555
    Senior Member
    Join Date
    May 2006
    Location
    Silicon Valley
    Posts
    581
    Quote Originally Posted by PasTim View Post
    I'm going to put this project to one side for a few days at least. It now seems that some of my UPnP renderers need this check for random 5 digits port numbers to be discovered, and some don't.

    I was trying to see if I could further qualify the devices that respond to the multicast to 239.255.255.250 by adding a "-s" (or possibly a "-m iprange") clause, and found that two out of my 3 UPnP renderers were found even without the INPUT clause at all. I am slightly unsure whether the -s clause works - the device that seems to need the INPUT clause seems to be somewhat temperamental in being discovered.

    As it stands all 3 of my devices work at the moment. If I recall correctly you are using a mobile. I have an LMS player on my mobile, so don't need UPnP for it. However, it might be useful for me to have another player to test. What renderer are you using?
    I do not understand how your server can accept responses from your UPnP renderers unless some INPUT rule is present that allows this to happen, or the firewall has been disabled altogether? I use sudo iptables -S to get a list of the rules that are currently in force. I found sometimes my phone was temperamental in being discovered too, and increasing the timeout parameter when creating the ipset upnp, seemed to help with that. I will play with the "-s" option that you mentioned, but it should work. Additionally, although this might not be all that helpful, I think I found a simple way to limit the number of SSDP M-Search broadcasts that go out periodically to just 1 each time; I added this rule at the end of the rest of the setup:
    sudo iptables -I OUTPUT 4 -d 239.255.255.250/32 -p udp -m set --match-set upnp src,src -j DROP
    Since it is also #4, it will be placed BEFORE the previous #4 rule, and it does have to go prior to drop the outgoing packet in time.
    Last edited by Ron F.; 2019-08-23 at 23:28.
    Living Room: SB Touch + DIY PSU > CI Audio VDA.2 DAC + VAC.1 PSU > VRX.1 cables > Emotiva XSP-1 Gen 2 preamp + XPA-DR2 amp > Blue Jeans cables > B&W 804 speakers
    Laptop: System76 Galago + Ubuntu 16.04 + Squeezelite + Vivaldi/Material Skin > Emotiva Little Ego DAC > Grado PS500 headphones
    Phone: Pixel 3a Phone + SB Player + Material web app > Bluetooth > Bose SoundLink Revolve
    Server: Puget Systems Serenity + Ubuntu 18.04 + LMS 8.0
    Music: Personal FLAC, Radio Paradise FLAC, Qobuz, Spotify

  6. #2556
    Senior Member
    Join Date
    Nov 2010
    Location
    Hertfordshire, UK
    Posts
    3,048
    Quote Originally Posted by Ron F. View Post
    I do not understand how your server can accept responses from your UPnP renderers unless some INPUT rule is present that allows this to happen, or the firewall has been disabled altogether? I use sudo iptables -S to get a list of the rules that are currently in force. I found sometimes my phone was temperamental in being discovered too, and increasing the timeout parameter when creating the ipset upnp, seemed to help with that. I will play with the "-s" option that you mentioned, but it should work. Additionally, although this might not be all that helpful, I think I found a simple way to limit the number of SSDP M-Search broadcasts that go out periodically to just 1 each time; I added this rule at the end of the rest of the setup:
    sudo iptables -I OUTPUT 4 -d 239.255.255.250/32 -p udp -m set --match-set upnp src,src -j DROP
    Since it is also #4, it will be placed BEFORE the previous #4 rule, and it does have to go prior to drop the outgoing packet in time.
    I don't understand quite a bit of this stuff. I'll need to track what's going on in more detail. My firewall is definitely on. I have a suspicion that some renderers are sending out unsolicited "I'm here" messages, but I'll see. Given that I have multiple players I don't think I want to try to drop the entries when I get one match.

    However, I will give testing a rest for a while. Something else may occur to me when I'm not thinking about it.
    LMS 7.9.3 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.

  7. #2557
    Senior Member
    Join Date
    May 2006
    Location
    Silicon Valley
    Posts
    581

    UPnP SSDP M-SEARCH Broadcast

    I might have discovered something PasTim...

    This whole business with the Linux firewall began with the desire to allow UPnPBridge to find mediarenderers on the local network by punching a hole in the server's firewall just big enough to allow that to happen. Using iptables and ipset, this appears to be possible. However, I have found that the use of ipset has an unintended consequence: it is not application specific and it allows other running programs to take advantage of this and send a UPnP SSDP M-SEARCH broadcast of their own, and open more ports than we had intended! I have found that Chromium-based browsers, such as Opera and Vivaldi, (which I personally use,) were doing this. I don't like this; I only wanted a port for receiving Notify responses to be opened for the UPnPBridge plugin. I note that Firefox does NOT behave this way - kudos to Mozilla.

    Solution: yet another rule to be added to iptables. I found that all browsers add a USER-AGENT field to their SSDP payload, and we can use this to drop their outgoing broadcast before it gets sent, and before they open another port using the ipset we created for UPnP.

    sudo iptables -I OUTPUT 4 -d 239.255.255.250/32 -p udp -m udp --dport 1900 -m string --algo kmp --string 'USER-AGENT' -j DROP

    In testing, this appears to have solved the issue for me. OK, so now, disregarding the need for persistence across a reboot, I have the following list of commands, to modify my netfilter-based firewall to allow UPnPBridge to find my mediarenderers by opening a port for only a few seconds, (maybe just a bit longer than that,) for it to pick up responses, and then the port is closed. This search is repeated every 20 seconds. I might put all this into a bash script:

    sudo ipset create upnp hash:ip,port timeout 6
    sudo iptables -I OUTPUT 4 -d 239.255.255.250/32 -p udp -m udp --dport 1900 -j SET --add-set upnp src,src --exist
    sudo iptables -I OUTPUT 4 -d 239.255.255.250/32 -p udp -m set --match-set upnp src,src -j DROP
    sudo iptables -I OUTPUT 4 -d 239.255.255.250/32 -p udp -m udp --dport 1900 -m string --algo kmp --string 'USER-AGENT' -j DROP
    sudo iptables -I INPUT 4 -p udp -m set --match-set upnp dst,dst -j ACCEPT

    I will continue testing!
    Last edited by Ron F.; 2019-08-24 at 21:02.
    Living Room: SB Touch + DIY PSU > CI Audio VDA.2 DAC + VAC.1 PSU > VRX.1 cables > Emotiva XSP-1 Gen 2 preamp + XPA-DR2 amp > Blue Jeans cables > B&W 804 speakers
    Laptop: System76 Galago + Ubuntu 16.04 + Squeezelite + Vivaldi/Material Skin > Emotiva Little Ego DAC > Grado PS500 headphones
    Phone: Pixel 3a Phone + SB Player + Material web app > Bluetooth > Bose SoundLink Revolve
    Server: Puget Systems Serenity + Ubuntu 18.04 + LMS 8.0
    Music: Personal FLAC, Radio Paradise FLAC, Qobuz, Spotify

  8. #2558
    Senior Member
    Join Date
    Nov 2010
    Location
    Hertfordshire, UK
    Posts
    3,048
    Quote Originally Posted by Ron F. View Post
    I might have discovered something PasTim...

    This whole business with the Linux firewall began with the desire to allow UPnPBridge to find mediarenderers on the local network by punching a hole in the server's firewall just big enough to allow that to happen. Using iptables and ipset, this appears to be possible. However, I have found that the use of ipset has an unintended consequence: it is not application specific and it allows other running programs to take advantage of this and send a UPnP SSDP M-SEARCH broadcast of their own, and open more ports than we had intended! I have found that Chromium-based browsers, such as Opera and Vivaldi, (which I personally use,) were doing this. I don't like this; I only wanted a port for receiving Notify responses to be opened for the UPnPBridge plugin. I note that Firefox does NOT behave this way - kudos to Mozilla.

    Solution: yet another rule to be added to iptables. I found that all browsers add a USER-AGENT field to their SSDP payload, and we can use this to drop their outgoing broadcast before it gets sent, and before they open another port using the ipset we created for UPnP.

    sudo iptables -I OUTPUT 4 -d 239.255.255.250/32 -p udp -m udp --dport 1900 -m string --algo kmp --string 'USER-AGENT' -j DROP

    In testing, this appears to have solved the issue for me. OK, so now, disregarding the need for persistence across a reboot, I have the following list of commands, to modify my netfilter-based firewall to allow UPnPBridge to find my mediarenderers by opening a port for only a few seconds, (maybe just a bit longer than that,) for it to pick up responses, and then the port is closed. This search is repeated every 20 seconds. I might put all this into a bash script:

    sudo ipset create upnp hash:ip,port timeout 6
    sudo iptables -I OUTPUT 4 -d 239.255.255.250/32 -p udp -m udp --dport 1900 -j SET --add-set upnp src,src --exist
    sudo iptables -I OUTPUT 4 -d 239.255.255.250/32 -p udp -m set --match-set upnp src,src -j DROP
    sudo iptables -I OUTPUT 4 -d 239.255.255.250/32 -p udp -m udp --dport 1900 -m string --algo kmp --string 'USER-AGENT' -j DROP
    sudo iptables -I INPUT 4 -p udp -m set --match-set upnp dst,dst -j ACCEPT

    I will continue testing!
    Hi Ron F. I'm not sue I understand the 3rd line - how does it limit the searches to just one? I also have other servers (eg minimserver) and worry that more things I need will be stopped. As to the browsers, is this doing any harm? It's still only port 1900 is it not?

    Meanwhile, I on your suggestion of using iptables -S, I found that iptables has held onto some rules that I deleted using ufw. ufw status does not show these rules, but iptables does (some 30000:60000 rules), which explains why some devices continued to be discovered. Weird. More things to look at.
    LMS 7.9.3 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.

  9. #2559
    Senior Member
    Join Date
    May 2006
    Location
    Silicon Valley
    Posts
    581
    Quote Originally Posted by PasTim View Post
    Hi Ron F. I'm not sue I understand the 3rd line - how does it limit the searches to just one? I also have other servers (eg minimserver) and worry that more things I need will be stopped. As to the browsers, is this doing any harm? It's still only port 1900 is it not?

    Meanwhile, I on your suggestion of using iptables -S, I found that iptables has held onto some rules that I deleted using ufw. ufw status does not show these rules, but iptables does (some 30000:60000 rules), which explains why some devices continued to be discovered. Weird. More things to look at.
    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.

    For example, to list all firewall rules with line numbers so that they can be referred to later:
    sudo iptables -L --line-numbers

    To list just those input rules that you created using gufw or ufw:
    sudo iptables -L ufw-user-input --line-numbers

    To delete an existing rule, such as one from your ufw-user-input chain, that probably contains your ACCEPT rule for ports 30000:60000:
    sudo iptables -D ufw-user-input XX # where XX is the line number you saw in the list for ufw-user-input

    By design, rules added or deleted using iptables are not persistent:
    sudo apt install iptables-persistent netfilter-persistent

    To save:
    sudo netfilter-persistent save

    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.
    Last edited by Ron F.; 2019-08-25 at 09:41.
    Living Room: SB Touch + DIY PSU > CI Audio VDA.2 DAC + VAC.1 PSU > VRX.1 cables > Emotiva XSP-1 Gen 2 preamp + XPA-DR2 amp > Blue Jeans cables > B&W 804 speakers
    Laptop: System76 Galago + Ubuntu 16.04 + Squeezelite + Vivaldi/Material Skin > Emotiva Little Ego DAC > Grado PS500 headphones
    Phone: Pixel 3a Phone + SB Player + Material web app > Bluetooth > Bose SoundLink Revolve
    Server: Puget Systems Serenity + Ubuntu 18.04 + LMS 8.0
    Music: Personal FLAC, Radio Paradise FLAC, Qobuz, Spotify

  10. #2560
    Senior Member
    Join Date
    Nov 2010
    Location
    Hertfordshire, UK
    Posts
    3,048
    Quote Originally Posted by Ron F. View Post
    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.3 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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •