Issue 57

upplay doesn’t find my Yamaha renderer unless I turn off my firewall. Might be a dynamic port issue, since the standard (fixed) UPnP ports are open: 1900/2689/3702/5120/8200-8202. Or it might be something else. IIRC I saw a similar issue with gnupnp tools a while back.

No problem finding the (minidlna) server, firewall or no firewall.

Happy to acquire pcap traces if that might help localize the problem.

upplay doesn’t see my pogoplug-archlinux renderers even with the firewall down. (I’m using rygel as the render service on the pogoplugs.) Not sure that it’s relevant, but I’ve told rygel to fix its http service port at 8202, or more to the point: not use dynamic ports.

FWIW BubbleUPnP (Android) sees the pogos and the Yamaha.

Does the machine where upplay runs have multiple network interface (a vpn would count)? One limitation of libupnp, on which libupnpp and upplay are based, is that it uses only one network interface. This is a frequent cause for upplay not finding stuff. In this case, you need to select the right interface in the upplay preferences. This does not match your symptoms exactly, but it’s the first thing to check.

Four network interfaces, if you count the two VMware nets. But I leave wifi disabled, and in any case the first thing I did, even before disabling the firewall, was to set the network interface in preferences.

The startup diagnostic dump says that it’s looking at port 49152 on interface enp3s0, which is indeed my wired network:

I block all ports by default, and open only those ports which are requried. 49152 is defaulted. Hmm, wonder what happens if I open it…

Nope, no joy.

The debug printout says that it’s trying to open connections to my Dlink APs on random high number ports to retrieve root.sxml and simplecfg.sxml, which attempts fail because the ports are blocked by the firewall. More to the point, it doesn’t see the renderer, either.

UPnP dynamic port assignment might not be the only issue, but it is surely one issue.

I’m not too sure what may be happening, but beware that libupnp does not reuse its port, so that a restart before the expiration window will use the next available port: 49152, 49153, etc.

Upplay is trying to access the DLINK AP because the device responded to the discovery phase, and upplay is trying to download the device description files to see if it has UPnP AV or OpenHome services, this is quite normal.

I must not have been clear.

The fact that upplay sees my Dlink APs says that my computer has gotten through at least the initial phases of UPnP discovery.

That’s expected, because multicast is enabled and the static well-known UPnP ports (1900 etc) are opened in my laptop’s firewall.

But when upplay tries to connect to discovered UPnP hosts to fetch content, it uses a dynamically selected quasi-random high-number port … which can’t work because all those ports are blocked by my firewall (this isn’t quite true, but close enough).

Why not unblock high number ports? Since UPnP uses high number ports selected at quasi-random, I’d have to open all the high-number ports in my firewall … which is functionally equivalent to turning off my firewall.

I ran into this issue two or three years ago with rygel (or possibly gupnp, I don’t remember). I gather that UPnP *permits* the use of static content ports - typically 8000 to 8002. At any rate the gupnp developer was kind enough to provide a startup option that allowed me to nail down the ports. Coherence allows you to set the port number for content out of the box.

Executive summary: as best I can tell the UPnP underpinning of upplay is incompatible with a quasi-static firewall running on a client computer. If it’s possible to provide an option that allows me to specify static content ports, then we could see if that’s the only problem (or I could set up a client sans firewall to poke a bit further.)

By the way, I just checked my Rπ rygel installs, and indeed, rygel has a configuration option that allows a user to fix the content port:

port=8202

What port are we talking about here ? Do you mean the source port of the HTTP connection ? Because I don’t see how upplay could influence the destination ports which are chosen by the media server and renderer. Its own port for incoming connections (eventing) is not random, it’s the first available port from 49152 upwards.

If we are talking about the source port, first it is very unusual to set this, it’s normally chosen by the kernel in the ephemeral range and second, I can’t do anything about it because libupnp aka portable upnp, does the socket creation (that is, it does socket(), and connect() and no bind()ing whatsoever).

Or I’m missing something. Please specify what connection you are talking about (Soap, eventing, desc file download, whatever), and what of the 2 involved ports is being an issue.

Well, perhaps I’m confused. I don’t have time to take network traces just now, but it would be easy to track the set of exchanges.

Would that be of interest? Sometime in the next few days?

Having specific traces to review would minimize the ambiguities of English text.

Sure, I’ll look at the traces when you have them !