Peer listening port reports closed, but router shows port opened by UPNP and Canyouseeme.org can see serviec

[dunxd]

What is the issue?

The Peer listening port is reported as closed in Transmission settings on MacOS 13.2.1.

However, my router shows the port as being opened by Transmission.

MacOS firewall is allowing incoming connections for Transmission.
### Which application of Transmission?
Canyouseeme.org shows that the port is visible

Files are transferring ok, so it may be the test in the settings panel that is not working correctly.

Which version of Transmission?

4.0.1

[ckerr]

• What does https://portcheck.transmissionbt.com/your-port-number-here (with your-port-number-here replaced with the port you've opened) say?

• What version of Transmission

• What desktop UI are you using (e.g. transmission-mac, transmission-qt, transmission-gtk)

[dunxd]

Sorry - hit save before finishing draft.

I am using transmission-mac 4.0.1.

https://portcheck.transmissionbt.com/60953 shows a page only showing 0.

[dunxd]

I've used the Randomize button to generate a new port. This is updating my router UPNP settings correctly, and canyouseeme.org can see the new port, but portcheck.transmissionbt.com/{portnumber} still shows 0.

[titer]

In case this is an IPv4 vs IPv6 problem, these two commands in a Terminal would test them separately:

curl -4 https://portcheck.transmissionbt.com/{port-number}; echo
curl -6 https://portcheck.transmissionbt.com/{port-number}; echo

[dunxd]

IPv4 version returns 1
IPv6 version returns 0

I don't believe my router supports UPNP via IPv6. If I manually open the IPv6 port on my firewall, the IPv6 command returns 1 and the Settings page shows the port is open.

However, if I want to randomise my port each time Transmission starts, manually forwarding doesn't work well.

Torrents are still working fine, I guess over IPv4, so perhaps this is cosmetic.

[kelson42]

@titer @ckerr After our efforts to get that problem with IPv6 fixed, I finally wanted to test with my own Transmission-GTK 3.00 (bb6b5a062e) Ubuntu client and was pretty surprised and disappointed that actually it was still failing for me!
But thank you @dunxd, you have pretty much nailed it and I believe to be exactly in the same situation: 2 public IPs, one in IPv4 and one in IPv6 and portcheck.transmissionbt.com seems to work only with IPv4:

$ curl -4 https://portcheck.transmissionbt.com/9008; echo
1
$ curl -6 https://portcheck.transmissionbt.com/9008; echo
0

Like for @dunxd, it seems that something is wrong between Transmission and my Fritz!box as the port seems not open (or relayed) properly in IPv6 but works properly in IPV4. But I guess Transmission can work perfectly work (in IPv4), so the check should not be reported as a failure.

Maybe the portcheck.transmissionbt.com should be smarter (probably not) or then the transmission client should be. Not sure exactly what is the current logic, but I could imaging something like: test specifically IPv4 and if fail then test specifically IPv6. Not sure how exactly how behind the door the software works and if both values are relevant or not.

So at the end not sure where the ticket should stay, here or moved to Transmission software itself?

[titer]

AFAICT there is no ticket open about this in the transmission repo, so maybe move this one there?

If useful, the server-side component could be exposed with v4-only and v6-only hostnames to make it a little easier to test one or the other. But ultimately, I believe the problem reported here could only be addressed with changes on the application side, making it run two separate checks instead of just one

[kelson42]

@ckerr I guess your expertise will be needed to:

• Better qualify the problem: it's not clear to me how exactly the Transmission client (should) behave in such a situation
• Make a software proposal to fix the Transmission client (at least the UI level)
• Transfer to repository transmission/transmission (if you agree) OR rewrite from scratch the ticket (probably better)

[dunxd]

See my comment above that was marked as off-topic. suggesting how the client UI might deal with different results from checking IPv4 and IPv6 connectivity. At the time of posting this issue, I thought the issue may be with portcheck but it seems it is more of a client UI issue so would make sense to transfer to transmission\transmission since I included the screenshots and discussion shows this isn't an issue with portcheck.

[beroset]

See also transmission/transmission#5607 (comment)

[kelson42]

@ckerr Can we transfer this ticket to transmission/transmission because the portcheck works properly IMHO.

[theirongiant82]

This is still broken in 4.0.4, even if you use static port mapping without uPNP.

Transmission will run for a while and report the port as open, but after a few days I start to see a warning from the tracker that my port is blocked. So this is not just a UI bug, and it's more than a port check failing. Does Transmission self-report closed ports to trackers? Or does the tracker find out due to multiple unsuccessful attempts?

The only workaround is to quit & relaunch the app.

Edit: I curl'ed portcheck:

$ curl -4 https://portcheck.transmissionbt.com/12345; echo
1
$ curl -6 https://portcheck.transmissionbt.com/12345; echo
curl: (7) Couldn't connect to server

My ISP does not assign IPv6 addresses. I have an Asus AX88U router that should support IPv6 WAN addresses.

[zkrige]

Port forwarding is setup and curl -4 https://portcheck.transmissionbt.com/33335; echo shows "1"

transmission 4.0.4 just doesnt connect and downloads are extremely slow, app shows port is closed

transmission 3.0 downloads are fast and app shows "port open"

[dunxd]

The problem as far as I can see it is that the UI shows a problem if IPv6 is enabled on the client, but for some reason cannot connect (i.e. the router blocks it) even if IPv4 is working perfectly. This makes troubleshooting really hard.

In my opinion the UI should show seperate indicators for IPv4 and IPv6 connections, so it is possible for users to see what is not working and take appropriate action. Many users won't care of IPv6 is working or not, if IPv4 is, so this false indication of a global problem is wasting people's time.

You might want to completely disable IPv6 on your client as well as on your router, since I think if it is enabled on the client then Transmission always shows a problem.

[theirongiant82]

Except it's not a false indicator. Ports appear open for about 24 hours after restarting Transmission. During that time, Transmission reports the port is open.

If a torrent is added after 24 hours or so, the tracker reports that it cannot reach my client and to try unblocking ports. Transmission now shows the port as closed.

They're already open from the firewall. I have to assume that Transmission sends its open ports in the announce.

[dunxd]

I'm not saying it will fix your problem, but if you don't need it turn IPv6 off on your computer. That's one less thing to worry about and it's only when you do this that the port indicator in Transmission is helpful for troubleshooting.

Have you tried the other methods mentioned above to manually troubleshoot?

[theirongiant82]

Disabling IPv6 across a LAN isn't practical in homes with Apple HomeKit, Google Home, and other popular IoT platforms that use IPv6 for broadcast and control. Even HomePods and other smart speakers used for audio playback will utilize IPv6 on LAN. So does the AppleTV, a popular accessory for those watching movies and TV shows. AirPlay and Mirroring rely on IPv6 to establish the session.

I would assume that at least 20% of your Mac users have something in their house that depends on IPv6, and disabling that stack just to fix Transmission would be unacceptable.

[dunxd]

You seem to be mistaking me for the developer of Transmission. I am a user like you.

I suggested a step you could take to troubleshoot the problem you added to the Issue I created last year.

I'm not suggesting that every user of Transmission should turn off IPv6 on their client. I am suggesting that you turn it off on the computer you run Transmission on to see if that is any way related to the problem you are having. You can of course suit yourself, but in that case I suggest you create your own issue instead of hijacking this one.