Portcheck broken for ipv6 capable systems.

[ploink]

Portcheck has been broken for ipv6 capable systems since the DNS AAAA record was added back in 2017 #381. When the system resolves the AAAA record and uses ipv6 for the portcheck request, it receives "400 Bad Request" because the server side script at that URL is not ipv6 capable.

We are in 2022 now and worldwide ipv6 adoption is at some 38% according to google so this affects many users.

There are several options to approach this:

1. It would be great if someone could update the script to make it ipv6 capable and preferably opensource it, but even then it would only check for the ipv4 or ipv6 port depending on the network connection, never both.
2. If we remove the AAAA record so only an A record is available for portcheck, then it will work again for all users, but only for the ipv4 port.
3. Rename the AAAA record to portcheck6.transmissionbt.com and make sure that portcheck only has an A record and portcheck6 only an AAAA record. This will have the same effect as removing it, but will also provide for a future upgrade path for checking both ports separately, depending on the hostname being used.
4. Change the transmission source code so it explicitly uses ipv4. Having a quick look at the source code I think this may be difficult and it would not make older versions work. Also, the implementation for macosx seems to be different, adding to the workload.

[ile6695]

Since redundant DNS records aren't harmful, there could be more records:
portcheck6.transmissionbt.com
portcheck4.transmissionbt.com
portcheck.transmissionbt.com

This way there would be a possibility to have options 1 and 3 at the same time.

[ploink]

True, but I would prefer not to have both A and AAA records for the same name because it is ambiguous, you don't know if v4 or v6 is being tested. When a user tests "THE port" he/she usually assumes v4 unless otherwise specified.

[ploink]

Is this how it is supposed to work in BT spec?? Is checking for open port part of the spec?

I dont know. Port checking is a feature of Transmission for which I am reporting the issue. I have not read the BT spec and I dont think it is relevant for me to do so.
Transmission checks if "the port" is open by making a request like https://portcheck.transmissionbt.com/80 where the "80" is the port number being checked. In this case it returns "1" if you run a webserver on port 80 and the request was made using ipv4. If the request is made using ipv6 it always returns "400 bad request".

That does not make sense. ipv6 cannot have open (or closed ports for that matter). It does not use NAT. Or you mean firewall closed ports?

I thought "Opening a port" in IPv4 world translates to "creating a NAT port forward mapping in the router" and in IPv6 world it means "creating a pinhole in the firewall". Sorry for not being specific enough.

But the DHT in ipv4 is separate from DHT in ipv6. Just like when you connect to the site you only use ipv6 or ipv4... What?

The issue is not related to DHT.

When a user tests "THE port" he/she usually assumes v4 unless otherwise specified.

Wrong, ipv6 is preferred, just like ipv6 DNS ip address is preferred just like AAAA record should be done first (the last one is often not the case, and the second is still broken in linux only). So the user must assume ipv6, unless it is broken in some way.

If most users have intimate knowledge about ip6 networking and its implementation in transmission, then indeed I am wrong. Otherwise maybe you need to educate them so they make the correct assumption. Even if the user is educated and on ipv6 capable network, then it is still very relevant to test the ipv4 port for connecting with the other 62% who are not so lucky to have ipv6.

Rename the AAAA record to portcheck6.transmissionbt.com

That is not how it works. You cannot rename AAAA record to portcheck6.transmissionbt.com because AAAA record is an IPv6 (and only ipv6) address. You need to create a new subdomain in the zone and then assign AAAA record there.

I tried to be brief and to the point without telling the dns admin in detail how to do his/her job.
It depends on the UI. The admin panel of my particular dns provider DOES allow me to just rename the subdomain for any record. It is a simple list of (subdomain - record type - value) and any of those three can be edited.
In reality portcheck.transmissionbt.com is a CNAME alias but that is also just detail that any capable dns admin can solve:

$ host portcheck.transmissionbt.com
portcheck.transmissionbt.com is an alias for vm4.transmissionbt.com.
vm4.transmissionbt.com has address 87.98.162.88
vm4.transmissionbt.com has IPv6 address 2001:41d0:c:5ac:5::1

[ploink]

You need to remove AAAA record from portcheck.transmissionbt.com, create a new subdomain portcheck6.transmissionbt.com and assign only AAAA record there, like on https://ipv6.test-ipv6.com then you need to write a new code on both sides to check both DHT presense and for ipv6 checking whether the port is filtered by firewall and for ipv4 whether the port is hidden behind NAT implemented again in the firewall...

I am confused by this reply. The issue is not related in any way to DHT or firewall problems.
I am just reporting a bug in BT's port checking feature. Others have reported the same bug, like #1190. The bug has been persistent for five years, affecting many users, but keeps getting ignored, dismissed, closed and misunderstood. Why??

[Pentaphon]

Yeah I have IPv6 and the port checker just hangs at "testing TCP port" forever...

[sethk]

@ploink The way this issue is being misunderstood is infuriating!

I'm guessing that the client needs some new behavior along the lines of:

• If bound to IPv4 address, send open port check to IPv4 address of portcheck.transmissionbt.com.
• If bound to IPv6 address, send open port check to IPv6 address of portcheck.transmissionbt.com.
• Report the results separately if necessary.

That part should be easy. The hard part is getting whoever runs portcheck.transmissionbt.com to update their script like you've said. It's hosted somewhere in France I think. How can we figure out who the responsible party is?

[sethk]

I sent an email to dev@tran[...]bt.com asking who maintains that endpoint.

By the way, I disagree that portcheck.transmissionbt.com should only have an A record in DNS, or that it should be split into portcheck{4,6}.transmissionbt.com, etc. The way it's set up now seems perfectly compatible with how it should work. DNS clients are free to limit the types of records they are querying for to A or AAAA, or discard the results that aren't relevant to them. Without looking, I'm guessing the client just creates a generic HTTPS request for that endpoint. Instead what it needs to do is bind the source of the request(s) to the same IP address(es) that are being sent to the trackers with the local port, and to report the the results in turn.

[ploink]

@ValZapod Thank you for your comments. Can you propose a solution to make portcheck work properly?
Ideally, when the user presses the "test port" button as in this image, transmission should verify two things:

1. If the host can be reached by ipv4-only peers.
2. If the host can be reached by ipv6 capable peers over ipv6.

In case this is a #WONTFIX issue then I propose just removing the portcheck completely from transmission as there is no point in keeping broken stuff that does not work and just frustrates many users.

[sethk]

If bound to IPv4 address, send open port check to IPv4 address of

How would that part work? You cannot get ipv4 address per Happy Eyeballs. Ipv6 will be preffered on all steps.

I'm thinking of two ways:

• Generate two different destination URLs after performing name resolution, e.g. https://87.98.162.88/... and https://[2001:41d0:c:5ac:5::1]/...
• Use a platform-specific way of explicitly binding the source address for the HTTPS connection. This would also fix dual-homed connections.

[ploink]

Sorry pressed wrong button on my mobile.

[sethk]

There is no way to get A record when ipv6 is working AFAIK. No, you need two domains.

Can you be more specific about the environment you're referring to here? Of course you can query for A or AAAA records by sending DNS queries over either IPv4 or IPv6...

[sethk]

Use a platform-specific way of explicitly binding the source address for the HTTPS

You would need a TLS certificate for ip addrress, hard to get, only RIRs have access, like https://1.1.1.1 https://[2606:4700:4700::1111]

We can ignore the authenticity failure on the client side, or if we really care, check for subject name/alternate name of portcheck.transmissionbt.com, but really the IP URL solution isn't as good as binding the HTTPS socket to the local address that we're sending to trackers (or which is being used for NAT).

[ploink]

No, you need two domains.

I agree. I only looked briefly at the source some time ago, but I guess transmission is just using a simple url library for the request that does not support specifying the protocol to use (like you can do with "curl -4" and "curl -6"). Using two hostnames that resolve to predictable protocol versions is the least complex.
Edit: it is also more transparent to the user when (s)he enters either v4/6 URL manually in a web browser for testing.

[sethk]

Of course you can query for A or AAAA records by sending DNS queries over either IPv4 or IPv6...

That is also false. Happy Eyeballs mandate that you must first ask DNS server that has ipv6 address and first ask AAAA record, first is respected by Windows, but not last.

Wait, what? I think we must be talking about two completely different things or entirely different OSI layers... Transmission is not a web browser, so it doesn't need to implement Happy Eyeballs, and I don't believe it currently does for any of the other communication it uses. It talks to peers and trackers using IPv4 and IPv6, is capable of listening on both addresses at once, registers itself with the trackers as both types of host addresses...

[sethk]

No, you need two domains.

I agree. I only looked briefly at the source some time ago, but I guess transmission is just using a simple url library for the request that does not support specifying the protocol to use (like you can do with "curl -4" and "curl -6"). Using two hostnames that resolve to predictable protocol versions is the least complex. Edit: it is also more transparent to the user when (s)he enters either v4/6 URL manually in a web browser for testing.

Are you talking about Transmission for macOS using the (now deprecated) NSURLConnection API?¹ That does seem like a problem, and it should use the libtransmission way of doing it that is cross-platform and uses raw socket calls.²

1. transmission/macosx/PortChecker.mm

   Line 116 in d5533ee

   NSURLRequest* portProbeRequest = [NSURLRequest requestWithURL:[NSURL URLWithString:CHECKER_URL([[timer userInfo] integerValue])]

2. transmission/libtransmission/rpcimpl.cc

   Line 1358 in 1782dc6

   static char const* portTest(

[ploink]

Are you talking about Transmission for macOS using the (now deprecated) NSURLConnection API?

Yes that was the source google found for me. It may be complicated to achieve what you want to do, but I am not a C programmer so I am not sure..

The simplest solution for now imho is tweak the dns but that appears to be impossible and I am getting doubts about portcheck in general.
I mean, do you really want to press a button that sends an "hello I am here" to some obscure closed-source unmaintained server for which nobody claims responsibility? I'll just block it in my outgoing firewall or make it resolve to 127.0.0.1 in /etc/hosts, that 'll fix it.

[sethk]

@ploink I see you've changed your mind about whether this needs to be fixed. I personally would find it useful, especially if it can show a separate status for IPv4/v6. Either way, I don't think the broken behavior should remain.

[sjackson1236]

I'm using transmission on an apple silicon m2 air, and I have an xfinity router. I did a port forward for 51413 on TCP since that's what the portforward site said this app uses. after that, I also set the port in transmission to 51413 and unchecked randomize. it then said "port is open" and my files are being seeded, though nothing in actually uploading to anyone. I then checked the settings again and "port is open" was changed to "port check site is down." my router does have IPv4 and v6.

so basically, it says i'm seeding, but nothing is actually being uploaded, and "port is open" is not coming back. thanks for any help you can provide.

[pleasantone]

I would strongly encourage that we just do the dual dns entry feature, it's the simplest:

portcheck.transmissionbt.com should resolve to resource records that include both an A and an AAAA record (leave it alone for backwards compatibility with old versions).

portcheck4.transmissionbt.com should resolve to only an A record.
portcheck6.transmissionbt.com should resolve to only an AAAA record.

as far as any SSL certificate crap, a new cert can be generated that all three names in the subject alternate field.

This requires the transmission daemon to do TWO port checks to confirm v4 and v6 availability but the underlying code is entirely "library and cross-platform independent."

[sethk]

I would strongly encourage that we just do the dual dns entry feature, it's the simplest:

portcheck.transmissionbt.com should resolve to resource records that include both an A and an AAAA record (leave it alone for backwards compatibility with old versions).

Yes, now does anybody know who runs that host and the web API it vends? That's the real problem here.

[kelson42]

@JohnClay @mikedld @ckerr You know the answer? Any chance to get the code of the checkport service in a dedicated git repository?

[ckerr]

Courtesy response to at least let you know I've seen the ticket -- I didn't set up portcheck.transmissionbt.com and TBH don't remmber who did. Maybe @livings124 does.

[livings124]

I don't remember unfortunately

[kelson42]

@ckerr @livings124 This is a pretty unusual situation to have a service up since 15 years and nobody knows (anymore) who is in charge, what is run and how to upgrade it! AFAIK IP belongs to OVH and is rented by Kimsufi.com

I see two ways to deal with the problem:

• Making a bit of archeology, but looking to the git with git log -S "PortCheck.php" --source --all, it seems both of you have done most of the dev work. So if you can not find information in your email archive about that, I guess there is nothing much to do.
• Relaunch a new service properly (new infrastructure, code in repository) and once this is ready update the appropriate DNS entries.

Would you consider to relaunch a new service - strictly controlled - behind `portcheck.transmissionbt.com?

[ckerr]

My best guess for who would know how to alter the service is @titer

[diegorodriguezv]

I just checked this again and the problem persists. If I disable IPv6 in my router transmission shows "Port is Open". If I enable it again and wait a few minutes it shows "Port is closed". I had tried back in October 2020 with the same results and reported it in #1190. I don't really think that I can help much to solve this problem except by thanking everybody who has helped diagnose it and by reiterating that this is a very important feature for users, especially not very tech-savvy ones.

[titer]

Hey, sorry for having overlooked this for so long (yes, I am still alive) - I just added a repo for the portcheck service and checked in the decade-old implementation -> https://github.com/transmission/portcheck

It is fairly small and would need little effort to add IPv6 support, I may do it later this week unless someone else wants to give it a shot first

[kelson42]

@titer Thank you very much, we might consider moving this ticket there then!?

[ckerr]

I think that's a good idea since this isn't something that can be fixed in the transmission/transmission codebase. Someone please open a new issue in that repo 🙇

I'm going to close this one. I see there are a lot of people watching this ticket, so, everyone, go sub to the new one...