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?

[dunxd]

If I manually set the port in my routers IPv6 to forward to my device, then curl -6 https://portcheck.transmissionbt.com/9008; echo does return 1. So the issue is that some (at least mine) routers don't support UPnP or NAT-PMP for IPv6.

My suggestion would be that the Settings screen listening port check can handle a third outcome:

• All checks pass - green
• All checks fail - red
• One of the checks fails, the other passes - amber - ideally the text tells you if IPv4 or IPv6 failed.

[ckerr]

@dunxd this Transmission UI suggestion is still off-topic in the portcheck repo, same as it was when you suggested it a few hours ago here 😸 This is a web service that has no concept of Transmission's UI.

[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.