Minissdpd debian что это
Every UPnP device and UPnP client (or control point in UPnP terminology) needs to listen to SSDP packets broadcasted to the multicast group 239.255.255.250 (or FF02::C / FF05::C in IPv6) port 1900. So when several UPnP devices are running on the same computer, or several UPnP control points are trying a discovery process on the same computer, there is concurence to open a socket for listening on the UDP port 1900. Also from the point of view of a control point software, it is usefull to get history of the SSDP NOTIFY packets sent on the network during a few past minutes.
I first coded MiniSSDPd as a small daemon used by MiniUPnPc (a UPnP control point for IGD devices) to speed up device discoveries. MiniSSDPd keep memory of all UPnP devices that announced themselves on the network through SSDP NOTIFY packets.
More recently, some MiniUPnPd (an implementation of a UPnP IDG) users complained about the non-possibility to run MiniUPnPd and MediaTomb (an implementation of a UPnP Media Server) on the same computer because these two piece of software needed to open UDP port 1900. I then added to MiniSSDPd the ability to handle all SSDP traffic recieved on a computer via the multicast group 239.255.255.250:1900. You may be interested in reading this forum thread about all this.
MiniSSDPd receive NOTIFY packets and store information contained for later use by UPnP Control Points on the machine.
MiniSSDPd receive M-SEARCH packets and answer on behalf of the UPnP devices running on the machine.
Running and using MiniSSDPd
Recent versions of MiniUPnPd and MiniUPnPc are designed to take automaticaly advantage of MiniSSDPd running on the same computer. Juste make sure that MiniSSDPd is started before any other UPnP program on the computer.
Other software must be patched in order to take advantage of MiniSSDPd. I made a pach for MediaTomb which add the Device in MiniSSDPd : mediatomb_minissdp-20081006.patch. More recently I made a patch for MiniDLNA : minidlna_1.0.18_minissdp1.patch.
Using MiniSSDPd in your program
Communication with a running MiniSSDPd process is done through a Unix socket. The path of this socket is usually /var/run/minissdpd.sock. Here is some sample code to open a unix socket :
struct sockaddr_un addr;
int s;
const char * minissdpdsocketpath = «/var/run/minissdpd.sock»;
s = socket(AF_UNIX, SOCK_STREAM, 0);
if(s
Request are sent to the Unix socket. The first byte of the request is the request type.
Strings sent or recieved are not zero-terminated but prefixed by their length in a variable length format. Use following macros to encode and decode to this format :
Control Points request (request type 1, 2 and 3)
A control point sends one of these requests to MiniSSDPd in order to receive a list of UPnP devices and services meeting the requirements. The request type byte is followed by a string (an empty string for type 3). Request types :
For these three request types, the responses is as following :
UPnP Device submit (request type 4)
These «request» type is used by UPnP devices that declare themselves and their services that way. The first byte is 4 and is followed by four Strings :
There is no response.
Thomas Bernard
Use the forum or contact me by email: miniupnp _AT_ free _DOT_ fr
I stopped MiniSSDPD, will something bad happen?
I have been trying to harden my Debian system by stopping and disabling the 20 or so unnecessary services listening by default. One of them is called «minissdpd». Apparently this provides «discovery» services to plug-and-play devices, whatever that means. Seems kind of crazy to me that something intended to help local peripherals needs to be listening to Chinese hackers on the other side of the world. What does discovery services even mean?
I looked in some vulnerability database, and sure enough minissdpd had a whole slew of vulnerabilities listed. How can they have this enabled in the default distribution? Seriously, its like install Debian, get hacked.
Anyway, my main question is: now that I have disabled this service, is something bad going to happen (like plug something in and it won’t work)?
3 Answers 3
I would say there’s no issue with disabling this service, assuming you have no need for UPnP (Universal Plug and Play). This is a service which allows for devices to «auto discover» one another on your network and advertise services that they can either provide or are looking for to consume.
I first coded MiniSSDPd as a small daemon used by MiniUPnPc (a UPnP control point for IGD devices) to speed up device discoveries. MiniSSDPd keep memory of all UPnP devices that announced themselves on the network through SSDP NOTIFY packets.
More recently, some MiniUPnPd (an implementation of a UPnP IDG) users complained about the non-possibility to run MiniUPnPd and MediaTomb (an implementation of a UPnP Media Server) on the same computer because these two piece of software needed to open UDP port 1900. I then added to MiniSSDPd the ability to handle all SSDP traffic recieved on a computer via the multicast group 239.255.255.250:1900. You may be interested in reading this forum thread about all this.
As explained by @slm, it is probably not needed, so:
my main question is: now that I have disabled this service, is something bad going to happen (like plug something in and it won’t work)?
Hello Tyler & all 🙂 In summary, MiniSSDPd is optional. Either deactivating it or fully removing it, would not break anything.
The device discoveries will still work fine. But they might be slower though. If you deactivate or remove MiniSSDPd your Debian would have stronger security. So it depends on your needs.
Below is the same answer as above. But with details if you’re interested in those.
Speaking for myself only. I do NOT trust MiniSSDPd. Because it has a very weak security history. Catastrophically weak security history in fact. Find the examples & sources below. I deactivated my MiniSSDPd. Because to me security is more important than speed.
The good news is that starting with Debian 10 Buster. MiniSSDPd is deactivated by default.
For those not familiar with MiniSSDPd, in summary what it does is that it speeds up device discoveries. For example, if you plug a new device on your Debian, it will be detected faster. The challenge with MiniSSDPd is that, for example, routers, printers, and other devices can be remotely commandeered by a new attack that exploits a security flaw in the Universal Plug and Play network protocol. And MiniSSDPd has a very long history of weak security.
Minissdpd debian что это
Presumably after an update to the version of minissdpd running on my two Debian testing boxes, am seeing a lot of log spam from minissdpd picked up by logcheck, in the shape of entries like
I’ve seen references on the miniupnp forum and in other places to changing the configuration for miniupnp to treat network ranges as part of the LAN, but can’t see how to do this for minissdpd. Posted this query on the miniupnp forum but not had a response, so thought I would try here as likely to be more Debian testing users here.
Minissdpd config (/etc/default/minissdpd) shown below:
#2 2018-02-16 15:56:47
Re: Minissdpd on Debian Testing spamming log files
Try specifying name of the interface you’re using to connect to your LAN, like eth0 or wlan0 or enp0s25, whatever ip addr tells you as the argument to MiniSSDPd_INTERFACE_ADDRESS.
If that doesn’t work, try listing all interfaces you have, e.g.
under the `other options` key.
#3 2018-02-16 16:40:33
Re: Minissdpd on Debian Testing spamming log files
Thanks, trying it now. When I read the comments in the config file it seems so straightforward lol.
#4 2018-02-17 18:13:49
Re: Minissdpd on Debian Testing spamming log files
Hmmm that has fixed the problem with traffic originating from my LAN which is awesome. However am now seeing traffic coming from 192.168.100.* range. Not sure if this is my router (a superhub 3 from Virgin) which is showing traffic from people connecting to the WiFi as part of their mesh style service or something else. Not seeing that hosts with that IP range connected to the router when I look at their monitoring pages.
Debian User Forums
minissdpd.service not working on Debian Bullseye
minissdpd.service not working on Debian Bullseye
#1 Post by hihu » 2020-05-03 08:06
Re: minissdpd.service not working on Debian Bullseye
#2 Post by Head_on_a_Stick » 2020-05-03 09:10
Why? You do understand that bullseye is a development branch, right? Only people who are interested in helping find and fix bugs and problems for the next Debian stable release should be using that.
What is the content of /etc/default/minissdpd?
Can we also see the full output of
Black Lives Matter
Re: minissdpd.service not working on Debian Bullseye
#3 Post by hihu » 2020-05-03 15:28
Re: minissdpd.service not working on Debian Bullseye
#4 Post by cuckooflew » 2020-05-03 16:05
Solution in all cases is: Create a correct /etc/default/minissdpd.
Re: minissdpd.service not working on Debian Bullseye
#5 Post by Francewhoa » 2020-09-27 01:40
Feel really free to use minissdpd or not. For much strong securité, I suggest to NOT use minissdpd.
In summary what minissdpd does is that it speeds up device discoveries. For example, if you plug a new device on your Debian, it will be detected faster. The challenge with MiniSSDPd is that, for example, routers, printers, and other devices can be remotely commandeered by a new attack that exploits a security flaw in the Universal Plug and Play network protocol. And MiniSSDPd has a very long history of weak security.
MiniSSDPd is optional. Either deactivating it or fully removing it, would not break anything.
If it is deactivated, the device discoveries will still work fine. But they might be slower though. If you deactivate or remove MiniSSDPd your Debian would have stronger security. So it depends on your needs.
Below is the same answer as above. But with details if you’re interested in those.
Speaking for myself only. I do NOT trust MiniSSDPd. Because it has a very weak security history. Catastrophically weak security history in fact. Find the examples & sources below. I deactivated my MiniSSDPd. Because to me security is more important than speed.
The good news is that starting with Debian 10 Buster. MiniSSDPd is deactivated by default.
