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.
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.
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.
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.
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 :
Found valid IGD : http://192.168.1.1:49000/igdupnp/control/WANIPConn1
Local LAN ip address : 192.168.1.100
ExternalIPAddress = 184.108.40.206
InternalIP:Port = 192.168.1.100:6660
external 220.127.116.11: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.
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.