Why SSDP traffic in Debug?

Questions
1

Ok. Im a little confused/concerned about running in Debug in the editor. Why to I see alot of this:

DEBUG:DLIB: SSDP Update: Creating new socket on #00

DEBUG:DLIB: Skipping interface, unable to multicast (#00)

DEBUG:DLIB: SSDP Update: Destroying socket previously on #00

DEBUG:DLIB: SSDP Update: Creating new socket on #01 DEBUG:DLIB: Skipping interface, unable to multicast (#01)

DEBUG:DLIB: SSDP Update: Destroying socket previously on #01

DEBUG:DLIB: SSDP Update: Creating new socket on #02

DEBUG:DLIB: Skipping interface, unable to multicast (#02)

DEBUG:DLIB: SSDP Update: Destroying socket previously on #02

DEBUG:DLIB: SSDP Update: Keeping socket on #03, previously on #03

What I dont get:

  • This spams on every input (mainly windows specific related like focus and unfocus) when Im running my debug (and intermittently)
  • SSDP is generally used for UPNP - why would you be using this?
  • There are already debug ports open for Remotery and other tools, why is this even being opened? And continually trying?
  • This is a multicast protocol often used in “phone home” hacks, so routers will block it if it sees it (if youve setup UPNP firewall properly)

Surely this isnt necessary? And more importantly if it is, why arent the Debug outputs more clear? It says its just opening then closing ssdp multicast sockets - this is not a great look.

2

It looks like it is looking for UPNP device responses (redacted wireshark cap):

image
image1515Ă—851 37.4 KB

Im going to make the assumption this is to search for certain types of gaming devices to debug on?

If this is the case - this should be off by default. And really should only be enabled when the developer wants to do that sort of debugging. I can raise a bug if this is the case.

For me, this is not good practice (considering I also do work for defense and other companies). My reasoning, is that this can then become a data gateway for your collection (intended or unintended) of user devices, input changes, and more. Which I am not comfortable at all with.

A simple checkbox in the project pages would be ideal if possible. In fact if this is tied to Live Updates then disabling it should disable this? (it doesnt atm btw).

3

Correct. This is for letting the Editor know which running targets it can attach to. (name and port)
It allows you to easily attach to your Android, iOS or Nintendo Switch device, and let’s you do hot reloading.
A similar http connection is also made when you press “build and run”, with the difference that the Editor has another means of getting the active debug server port (i.e. no ssdp needed in that case).

In fact if this is tied to Live Updates

It is not to do with Live Update.

this can then become a data gateway for your collection (intended or unintended) of user devices, input changes, and more

Please explain a bit here. What is a “data gateway for your collection”?

How would you recommend this be improved? I’m not talking about the opt-in, but the actual implementation which you consider not good practice.

4

The “not good practice” is the need to run discovery when the user doesnt require it? And reconnecting continually? My concern would be it is a vector for data collection (because many routers allow ssdp through by default).

I mentioned opt-in, because that would seem to be the most appropriate for a developer - they choose to have this enabled when developing for android, IOS or Nintendo. Why would all other developers need it? And its mostly likely the easiest way to manage this.A simple way to handle it: have a property in Android, IOS and Nintendo sections in the project.

On gamedev networks they probably have better network security for this, and so it makes sense in that manner too. Alternatives could be to just use your already provided debug sockets/server?

Put simply, you are already running a server in the editor, if its trying to connect to running targets why wouldnt the targets simply attempt to connect to the debug server (simple local dns resolve will work)? Broadcasting notify to the targets over ssdp means uPNP devices will get it too - since people often have many devices on their network (TV’s, phones, media players, computers etc), you are notifying to all these as well.

As a final note, if you know about the XXE ssdp exploits, and others, there is (to me) an obvious reason to have it disabled by default. Im personally always quite wary of “extraneous” network traffic since many of the systems I work with are with defense, financial and game dev systems - so, for me, the less “unnecessary” traffic, the better.

If no-one really cares, then thats fine too. Everyone has different requirements when it comes to their networks and tools they use. And for me, Im only using Defold for a couple of remaining projects, so this might be all moot.

2 Likes
5

My concern would be it is a vector for data collection (because many routers allow ssdp through by default).

Again, I’m still not really sure what you mean with data collection. Are you saying that routers show this information outside of the network? By default?

I mentioned opt-in, because that would seem to be the most appropriate for a developer

I’m not discarding the opt-in approach, I just want/need to know more about the actual problem.

you are already running a server in the editor, if its trying to connect to running targets why wouldnt the targets simply attempt to connect to the debug server

That’s the thing, isn’t it?
How do different applications find each other on a network?
E.g. you start one app on your device (by tapping the screen on the device). How would it know where the editor is? And it may find many editors inside a company network. Or vice versa.
This is why we’re using SSDP for discovery.

E.g. I believe the thinking behind our feature+implementation is comparable to when a printer on a network broadcasts it’s existance, and your application may find it. Is that inherently insecure?

As a final note, if you know about the XXE ssdp exploits,

No, that’s why I asked for more information. Basically, how to improve on the situation.
E.g. after opting in, the feature is used, and if there is something to improve, it sounds like a good thing?

If no-one really cares, then thats fine too.

It’s not like no one cares, but it’s been part of the engine for 14 years now, and to my knowledge noone has mentioned any such issues until know. Which is why I’m curious about it.

Another thing we can also do, is to not start the ssdp code in the engine, when it’s being launched directly by the Editor, since as you say, that’s likely the bulk of the users.

2 Likes
6

Yep - many routers will disable propagation of uPNP packets, but Ive seen many have it enabled by default (TPLink being a classic example). Note 239.255.255.250 should also stop at your ISP esp if its link-local. IPv6 SSDP is potentially more likely. Remember its just a UDP broadcast (thats what multicast really is).. so if port 1900 is open.. it will go.

With discovery.. you already have the editor running the debug server - as I suggested above, there’s no reason you cant use a normal socket connect, and use local network dns lookup to find the server. Rather than the server broadcast (multicast) the network to do so.

Alternatively, leave the broadcast, but make it specific for your app (port and multicast ip). This way it minimizes any sort of potential issues with a known protocol. Routers will block it, and devices wont respond to it.

If it hasnt really been an issue, its prob not of interest to most ppl. Myself, I just find it odd - its the only SSDP packet traffic on my local network - hence why it stood out.

1 Like
7

It’s the reverse problem, isn’t it?
The server(s) has to somehow (dns?) announce on the network to be found by the client app.
(E.g. for a large company, there may be 100 editors running.)
And, the selection (and connection), would be on the client app (the game on the device), so select which of the servers to connect to.

Is this a more common practice?
I don’t mind migrating to such a setup if that’s the “common practice” now (it is 15 years later after all).
I’d be curious to know how Unity/Unreal solve this problem.

8

Im not sure on Unity/Unreal - I havent seen any SSDP when running them, they might need to have modules enabled to do so. From memory (long time since I used UE and Unity server debug - 10+yrs) it was their own ports and debug system. I dont think it was a generic protocol.

So in some of the sims Ive built, we often have multiple classrooms with maybe 10-15 clients that need to connect to one or more master simulation systems. These clients when configured simply connect to a domain name - so the lookup occurs on the dns server, not broadcasting. In Defold case you could simply have “defold.local” or something like that to lookup local defold running servers via dns. The benefit here, is clients could also listen to dns announces as well (thus dont need to poll).

In one case, we ran a mini dns server with the simulator server (because it was on an offsite lan which didnt have its own domain servers). In this way, accessing any servers from a client is quite trivial, and is via a local domain name (rather than config IPs everywhere). You can even use direct tcp connects rather than udp based traffic (esp useful for certain types of remote networks that have limited routers and switches).

In the game business, we did a similar thing many years ago (local dns) but Id imagine there are all sorts of solutions. Multicast solutions are common, but Ive not seen too many SSDP (in my exp, but there could be plenty).

One of the drawbacks of multicast/broadcast is that it is udp. Which means network propagation can be problematic (network loops usually needing RDP solves and switches/routers passing the packets) - esp in bigger networks that are domain controlled.

9

It seems like the modern replacement for SSDP, in our case, would be mDNS: Multicast DNS - Wikipedia

2 Likes
10

Ive seen a few mDNS based setups. Seems to work well.

A normal local dns is easy too, either using one of the open DNS’s or micro ones. The main benefit of DNS, is that if you are in an enterprise network env, there will be usually a local dns server running, so you can just use that (makes resolution etc pretty simple - server registers with dns, all clients can use the local dns name directly).