I am currently working on a Raspberry Pi based robotics project that I would like to connect to a realtime customized control panel/dashboard, mostly for debugging purposes. I created a test setup where each instance of the robot "operating system" can be seen as a separate device in the dashboard, with a unique session and device ID associated to each. In theory you can connect multiple robots to the same dashboard and see what they are up to in realtime.

To summarize the setup:

  • The robot itself runs on a mix of C++ and Python (Raspberry Pi + ESP32)
  • The dashboard server runs on NodeJS, and takes care of connecting to the robot, and forwarding data to the dashboard client
  • The dashboard client is available from the server and receives realtime updates every 10ms via an UDP socket

Currently the robot will broadcast an UDP message on the local network every minute, so that it can be discovered by the dashboard server. Once the dashboard server notices one of these "pings" it will send out connection information to the robot (e.g. port to send the realtime data to). When the robot and dashboard server are connected, the robot will send out a serialized version of all relevant internal data/variables every 10 milliseconds. Think of information like motor position, speed, camera input, obstacles etc.

This method of connecting seems to work fine for now, but I was wondering if there is a better/more mature way of making the robot announce itself to the local network, and then connecting to one or more dashboard instances. I read about SSDP (as part of UPnP) as a good but also dangerous way of making devices announce themself to a network. Would it be recommended and common practice to use SSDP for this case, or are there better alternatives that are more futureproof (also security wise)? The robot can be considered an IoT device, but from the different online sources that I have read so far, IoT devices using UPnP and SSDP are considered a security risk that many end users are not aware of. Is this truly the case?


1 Answer 1


No, don't support flawed protocols. UPnP is flawed. We just need to stop using it or else it will haunt us for a long time.

UPnP is way too complex. I once wrote a firewall in C and needed a NAT traversal protocol to allow devices behind the firewall to ask for ports to be opened for them.

Port control protocol (PCP) is easy. Trivial, in fact. Maybe that's why there is an RFC for it? RFCs generally require that a normal human (as opposed to superhuman) can implement the protocol in a reasonable amount of time. QUIC is maybe pushing it a bit these days, but most stuff defined in RFCs is easy to implement -- in fact, trivial.

I also tried to implement UPnP and concluded that there's no reasonable way to implement it.

Maybe some existing library could work for some definition of "work", but then I have to have a dependency on a hugely complex library that surely has at least 100 different security vulnerabilities. In fact, security vulnerabilities in UPnP libraries are plentiful. Do you want your software to not be vulnerable? The only way in the case of UPnP is to simply write everything from the scratch yourself.

The problem is that UPnP requires a complex library on top of a complex library on top of a complex library on top of a complex library on top of a complex library. There's no way you could implement it in a day, like you can implement PCP. The largest difficulty is its use of SOAP. If you ever encounter something using SOAP, run away -- hard! Fast! It's going to kill you unless you are very good in escaping.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.