Tips on how to make UPnP work

Support
1

I wonder if someone could share some tip on how to make UPnP work. I know this is a router-specific thing. But then again, if someone has any tip whatsoever, I’d be humbly grateful.

This is what I’ve done so far:

  • Enabled UPnP on syncthing
  • Revised every single router (D-Link DSL-2730E) setting: there was only one UPnP-related, enabled it
  • Issue 2035 shows how to trace syncthing UPnP usage, which I did running: STTRACE=upnp syncthing &> >(tee upnp.log) No message said that a port had been mapped. Here they are:
[2L7Y5] 2015/04/14 21:10:11.588524 upnp.go:97: INFO: Starting UPnP discovery...
[2L7Y5] 2015/04/14 21:10:11.588552 upnp.go:146: DEBUG: Starting discovery of device type urn:schemas-upnp-org:device:InternetGatewayDevice:2...
[2L7Y5] 2015/04/14 21:10:11.588613 upnp.go:166: DEBUG: Sending search request for device type urn:schemas-upnp-org:device:InternetGatewayDevice:2...
[2L7Y5] 2015/04/14 21:10:11.588656 upnp.go:178: DEBUG: Listening for UPnP response for device type urn:schemas-upnp-org:device:InternetGatewayDevice:2...
[2L7Y5] 2015/04/14 21:10:14.588920 upnp.go:219: DEBUG: Discovery for device type urn:schemas-upnp-org:device:InternetGatewayDevice:2 finished.
[2L7Y5] 2015/04/14 21:10:14.589156 upnp.go:146: DEBUG: Starting discovery of device type urn:schemas-upnp-org:device:InternetGatewayDevice:1...
[2L7Y5] 2015/04/14 21:10:14.589332 upnp.go:166: DEBUG: Sending search request for device type urn:schemas-upnp-org:device:InternetGatewayDevice:1...
[2L7Y5] 2015/04/14 21:10:14.589454 upnp.go:178: DEBUG: Listening for UPnP response for device type urn:schemas-upnp-org:device:InternetGatewayDevice:1...
[2L7Y5] 2015/04/14 21:10:17.589580 upnp.go:219: DEBUG: Discovery for device type urn:schemas-upnp-org:device:InternetGatewayDevice:1 finished.
[2L7Y5] 2015/04/14 21:10:17.589744 upnp.go:124: INFO: UPnP discovery complete (found 0 devices).
  • Installed upnp-inspector (Xubuntu 14.10): it sees my router, but I couldn’t see any messages indicating that syncthing managed to map a port. The information shown looked Greek to me!

I know UPnP is not working: if I enable UPnP, and disable fixed port forwarding, syncthing on my desktop doesn’t connect to my mother’s desktop, which is behind another NAT router.

As I said, I know this not syncthing’s problem, surely it’s my router’s, but if someone has already struggled with this and could share any pointers…

Paulo

EDIT:

  • After starting syncthing, checked current tcp connections in LISTEN state, and noticed that it’s listening on tcp6 but not on tcp:
paulo@monk:~/tmp$ netstat -tln
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State      
tcp        0      0 127.0.0.1:8080          0.0.0.0:*               LISTEN     
tcp        0      0 127.0.0.1:5941          0.0.0.0:*               LISTEN     
tcp        0      0 127.0.1.1:53            0.0.0.0:*               LISTEN     
tcp        0      0 127.0.0.1:631           0.0.0.0:*               LISTEN     
tcp        0      0 127.0.0.1:8888          0.0.0.0:*               LISTEN     
tcp        0      0 127.0.0.1:5037          0.0.0.0:*               LISTEN     
tcp6       0      0 :::22000                :::*                    LISTEN     
tcp6       0      0 ::1:631                 :::*                    LISTEN
  • Indeed, checked whether port 22000 is opened using CanYouSeeMe.org, and it is closed
  • Both local and global discovery are enabled

Not sure what I’m missing here. I suspect it’s something shamefully obvious…

2

Looks like it’s simply not getting search responses when looking for the UPnP devices. Not sure why. Do you have a firewall on the machine you are running synchting on, even a local one? Try turning it off.

The tcp6 socket is normal (it means IPv4 and IPv6), and the port being closed is an effect of UPnP not doing it’s thing and there not being a manual port forward.

3

If you are running windows, there ia a known bug which sometimes causes windows to drop the broadcasts.

On linux, I guess try getting a commandline/somw other upnp client and see if it can discover the device to start with. If it can, then probably using wireshark to see if syncthing is sending the broadcasts is your next best bet.

It also might be your firewall preventing ssdp discovery.

4

Oh, of course, you’re right. Disabled the firewall:

paulo@monk:~/tmp$ sudo ufw disable
Firewall stopped and disabled on system startup
paulo@monk:~/tmp$ sudo ufw status
Status: inactive

but the results were the same.

This modem-router (D-Link DSL-2730E) was leased by my ISP provider (GVT) and has a custom built firmware: I’m suspecting UPnP is firmware-disabled. I’ve written to D-Link inquiring about it. I’ll post back when I get any news.

In the meantime, I’ll try to grab another (proper) router to test.

Oh dear, I didn’t know that, my ignorance, thanks for explaining.

upnp-inspector can see the router. I’ll search for alternatives.

I had wireshark running during the tests, but didn’t dig into the output. Will follow your suggestion and look more closely.

Thank you so much, @calmh and @AudriusButkevicius for your patient and useful tips.

5

Could be that the router doesn’t understand/like our discovery packets for some reason. The wireshark trace (pcap) of upnp-inspector and then starting syncthing would be interesting, we could check for relevant differences.

6

Bingo, I think your suggestion nailed the problem, @calmh ! Here’s what I did:

  1. Started a wireshark capture with filter udp port 1900
  2. Started upnp-inspector, waited for devices to show up. Took around 10s:
  3. Stopped capture. Here’s the pcap file
  4. Stopped upnp-inspector
  5. Started another wireshark capture, same filter
  6. Started syncthing with STTRACE=upnp syncthing &> >(tee syncthing.log) Waited for syncthing to finish UPnP discovery.
  7. Stopped capture. Here’s the pcap file
  8. Stopped syncthing. Here’s the output log

The impression I get: the router takes around 10s to reply to the SDDP search requests, and syncthing times out too quickly, way before the replies arrive. If that is the case, do you want me to open an issue on the syncthing tracker ?

EDIT: Just for reference, here’s the article from wireshark’s Wiki I used to get the correct filter for capturing SDDP traffic.

EDIT 2: Found a more useful UPnP viewer, Ubuntu package gupnp-tools, utility gupnp-universal-cp shows detailed information about all UPnP devices on the network and their control points:

7

You can try building syncthing with a longer timeout, and see if that helps. We block our functionality until we complete UPnP so I don’t 10 seconds is a good default value.

8

Wouldn’t it be the case of exposing this UPnP timeout as a configuration parameter ? Currently config.xml has these UPnP-related parameters:

<upnpEnabled>true</upnpEnabled>
<upnpLeaseMinutes>0</upnpLeaseMinutes>
<upnpRenewalMinutes>30</upnpRenewalMinutes>

EDIT: Would it make sense to add this as a feature request on the issue tracker ?

9

I already have a patch for that.

10

Hey, great to know ! Problem solved, then. Will this patch be applied to 0.10 and 0.11 ?

11

Not sure. Probably v0.11 only, as 0.10 is a maintenance release for now.

12

I guess only v0.11 will get the fix

13

That’s one lazy router… :grin:

1 Like