UPnP not working with my FRITX!Box

Test the UPNP of router with:

upnpc -l
upnpc -a 192.168.1.142 1234 5678 TCP

And all works like expected (ie. NAT rule created on router).

Try to run Syncthing in debug mode (STTRACE=upnp syncthing), and here the log:

There are a lot of error (500) in SOAP request.

Thanks!

Could you capture the upnpc and Syncthing requests using Wireshark so we can compare them?

According to your log your router doesn’t accept the request becauseof a ConflictInMappingEntry.

1 Like

thanks to your answer (ie ConflictInMappingEntry), I focused on router side…I had just installed the Fritzbox, found and install a router update and all is gone: now it works perfectly:

New NAT port mapping: external TCP address *.*.*.*:33681 to local address [::]:22000

For future search, below 07.27v of FRITZ!Box UPNP with Syncthing not work.

Thanks for your speedy answer!

After all, it is not the Fritzbox that opens UPnP connections, but merely allow that to any clients. If this possibility exists, the clients open the corresponding ports.

Since you are talking about v7.27, the current version is actually v7.29 and in some weeks there is v7.39. Which Fritzbox do you actually use?

sorry, I don’t figure out what you mean. In my case I had enabled UPnP on Fritz!Box for that host but it refuse to open the port (when Syncthing ask it). Anyway, in my case the issue persist because now the port is open but not appear in the list “Internet > Permit access”, but only in “Diagnostics > Security”. And It seems work only on wire but nothing on wifi

So, I think some strange limited compatibility between Fritz and Syncthing. Indeed, if I use upnpc -a IP PORT EXT_PORT TCP it works like a charm.

Do you have Fritz!Box? Maybe can suggest me where I wrong…if it’s not a bug.

Since you are talking about v7.27, the current version is actually v7.29 and in some weeks there is v7.39. Which Fritzbox do you actually use?

7590…since 2 days. When I installed it I had version 6.[something], now v7.29 as you said.

In Home > Internet > Shares > Port Shares there is a column “Independent Port Sharing”. For each device, it shows how many ports are active. I also have the Fritzbox 7590, but all of them have “0 active”, so no special ports are opened. I suspect that the communication runs over https and the relay servers. There is no other explanation for this.

Maybe your issue is Provider and Connection related, I´m use the german Telekom without any problems.

Exactly what I said! But try to go in “Diagnostics > Security > Port Sharing” and see section “Home Network Devices”…There I have the port opened by Syncthing :slight_smile:

It’s quite strange…I think Syncthing use not so “standard” (for Fritz!Box) steps to request the port opening through UPnP.

Indeed with cmd upnpc -a ip port external_port protocol the Fritzbox works like expected.

What issue? Now, on my side Syncthing is able to open the port: New NAT port mapping: external TCP address IP:33681 to local address [::]:22000

I don’t know why the issue remain on wifi device, could you test?

In the next days I’ll try to capture with Wireshark the difference between Syncthing and upnpc, maybe can be useful for developers.

Fritz routers are rubbish. My ISP sends them to me, I have had three over the years and are only used for diagnostic when requested by them. Get yourself an Asus RT-AX58U, does everything the Fritz does and more.

1 Like

Same issue, It was sent by my ISP (mandatory…but not for free). Now I have it and I cannot spent other money, but thanks for suggestion of the ASUS.

I have also open a ticket to AVM…We will see what happen

Unfortunately, it’s not that simple, it depends on what is used. Internet connectivity, depending on the connection type, DECT and telephony, as well as all other components combined, only the Fritzbox has that.

I find the current Fritzboxes already quite good. The professional routers are perhaps a bit better, but for that you have to operate additional devices, e.g. a DSL modem, etc. That would also be the case with the ASUS RT-AX58U.

1 Like

This is normal. “Dynamic” mappings (UPnP or PCP) [called automatic or independent in the English UI] never show up there, only static/manual ones. That page does however show, if dynamic mappings are enabled for some device. Note the number behind the checkbox is broken, see below.

You’re correct that the ports displayed under “Diagnostics > Security” are authoritative.

This has been broken since forever, sadly. That counter only counts dynamic UDP port mappings, but Syncthing opens TCP mappings. TCP mappings do work as expected however, just that UI element is broken.

Can be numerous things. If your NIC(s) use different MAC addresses for Ethernet/WiFi, it is considered to be a different device for the FBox, so ensure you have granted permissions to the WiFi-device too. Additionally, ensure that under WiFi - Security, devices are allowed to communicate with each other (otherwise multicast may be broken, which might prevent UPnP discovery). Also, if you switch connection types restarting Syncthing may help to trigger a fast re-discover of NAT devices.


I should also note that I have numerous AVM devices here (including Boxes 7590, 7530, 7582, 7490, 7390 and 6600) and as far as my testing goes (haven’t checked all boxes), Syncthing creates correct UPnP mappings on both Ethernet and WiFi for me, so I can’t reproduce this issue with my devices here.

Exactly!

But it’s report the correct count if I try to open port 6660 on TCP with:

$ upnpc -a 192.168.1.100 6660 6660 TCP
upnpc : miniupnpc library test client, version 2.1.
 (c) 2005-2019 Thomas Bernard.
Go to http://miniupnp.free.fr/ or https://miniupnp.tuxfamily.org/
for more information.
List of UPNP devices found on the network :
 desc: http://192.168.1.1:49000/igddesc.xml
 st: urn:schemas-upnp-org:device:InternetGatewayDevice:1

Found valid IGD : http://192.168.1.1:49000/igdupnp/control/WANIPConn1
Local LAN ip address : 192.168.1.100
ExternalIPAddress = 95.246.178.22
InternalIP:Port = 192.168.1.100:6660
external 95.246.178.22:6660 TCP is redirected to internal 192.168.1.100:6660 (duration=0)

Try yourself, you will see “Independent Port Sharing: 1 enabled” (in “Internet > Permit Access > Port Sharing”) and the right port also in “Diagnostics > Security”.

I have to made more deep tests and debug about this issue.

Hey, thanks for your detailed answer…I’m glad to not be the only one with this issue. Make me know if you do further tests.

Huh, you’re right. With miniupnpc TCP mappings suddenly work in the UI and are correctly displayed. Have never seen that before, the UPnP libraries I normally use only show up in the UI if UDP is used?

UPnP is a weird protocol…

In any case, best thing would probably to setup up static port forwards and not rely on UPnP.

Maybe something “strange” done by Syncthing…because with miniupnpc Fritzbox works good.

Ahahah…ok, but it’s not issue related :wink:

And in my case, I have different devices (PC, notebooks and smartphone) and the last ones are not always ON and use dynamic ip with dhcp (I don’t like reserve IP for something not always online)

So, I believe I figured out what’s going wrong:

When you use miniupncp, it’s fairly straightforward what happens:

Miniupnc first retrieves UPnP device descriptions, checks if all is good, gets external IP etc and then adds the mapping. Once it has the mapping it retrieves it to check, then it terminates.

Note that miniupnc only uses IGDv1 here, not v2.


Syncthing on the other hand does this:

Syncthing both tries to discover IGDv1 and IGDv2 devices. The Fritz!Box answers both (for compatibility probably).

Syncthing then also does the usual data-fetching and then adds a mapping via IGDv1. This is successful.

However, after successfully getting a port mapping, Syncthing doesn’t stop here. Syncthing now attempts to add the same port mapping via IGDv2. The Fritz!Box refuses this, with error code “ConflictInMappingEntry”. This is correct as the port is already mapped. Syncthing retries a few times then giving up, reporting success as the first IGDv1 attempt was successful.

However, the failed IGDv2 attempts apparently trigger a bug somewhere in Fritz!OS UPnP stack, as this causes the mapping to disappear from some UI elements. I can reproduce this by manually creating conflicting entries using a different port mapping tool (GitHub - kaklakariada/portmapper: A tool for managing port forwardings via UPnP). As soon as I try to create conflicts, the UI removes the port mappings, even though they are technically still there and can be retrieved via UPnP. I wasn’t able to reproduce using miniupnc - maybe it has internal guards against conflicting entries.

Note that the issue does not appear to be v1 vs v2: I can still reproduce by adding the same mapping via v1 twice: The UI bug appears as soon as you try to create conflicts using either version.

1 Like

Although the FritzBox behaves buggy, i’d expect Syncthing to try the more modern IGDv2 first and only try to fallback to IGDv1 if this fails.

IPv6 UPnP support would also be super nice.

Clear and detailed explanation of the issue, thanks!

So, at the end I think we have two bugs one both sides.

  • Syncthing should try with IGDv2 and only after failed the attempt, give a chance to IGDv1.

  • Fritzbox should fix some not well identified UI trouble.

I have open a ticket with AVM Fritzbox some days ago, now I’ll attach your detailed debugging session, I’m sure it will help the AVM guys.

I don’t know if could be open an issue also for Syncthing on GitHub.

1 Like

I don’t think Syncthing is doing anything wrong here, it looks for all IGD devices and tries to map a port on all of them.

IPv6 support would still be nice for all the people suffering from CGNAT :wink:

The UI bug on Fritz!Box is been fixed. The patched version, still as beta (or Lab), 07.39-96137 solve the problem and report the UPnP port opened by Syncthing in the “Internet > Permit Access” page.

Thanks to all for the support!

1 Like