Port changing automatically upon installing qBit-master

[ghost]

qBittorrent version and Operating System

(type here)
4.3.0alpha1, w10

What is the problem

I had the "Use different port on each startup" option unchecked by default. I had previously changed the port a lot of times and forwarded the port in my router but never touched that "use random port on each startup" box.
Now after installing 4.3.0alpha my port changed automatically and I found that box was checked as well.
I also noticed that now Qbit is listening on different ports for TCP and UDP. Which is pretty weird as well.

If I didn't go into settings it might not have come into my attention that my port is now being randomized at startup without any notice.

Also if Qbit is listening on different ports for UDP and TCP when this randomization is used then which port is getting reported to the tracker? TCP or UDP? I haven't seen this kind of dual listening on any other client when using port randomization.

What is the expected behavior

Don't change users' port upon update without notice which he has set explicitly in previous version.

Steps to reproduce

Install Qbit-master and check your port settings(provided you didn't have that box checked already or have changed that settings previously)

[ghost]

@Chocobo1 @glassez @FranciscoPombal take a look at this if you get time.

[FranciscoPombal]

Probably a result of #11637.

However, to be sure, would you mind testing if this is really the culprit by compiling current master without this change and checking whether or not i reproduces?

Either way, this should get fixed once something like #11847 gets merged.

[ghost]

I just compiled master without #11637 and didn't face this issue. My port remained same and Qbit is listening on the same port for both TCP and UDP.

[ghost]

Probably a result of #11637.

However, to be sure, would you mind testing if this is really the culprit by compiling current master without this change and checking whether or not i reproduces?

Either way, this should get fixed once something like #11847 gets merged.

It will require a similar solution as #11847 but the dual listening issue with port randomization won't get fixed by that. Qbit will continue to listen on two different ports. Making such a bugged feature as default doesn’t make sense.

[glassez]

What's the problem with different ports for different protocols?

[ghost]

What's the problem with different ports for different protocols?

If qbit reports lets say the TCP port to tracker, then other peers will not make any incoming connection to the UDP port. This is problematic as the incoming protocol will then be limited to only TCP.
If it reports UDP port to tracker and the other end does not use UDP then the peer will fail to make any sort of connection.

[arvidn]

ideally both the UDP and TCP sockets listen on the same port. There's only one port reported to the tracker and to the DHT. It's generally expected that you can reach a peer via both TCP and uTP on the same port (and the DHT as well).

[FranciscoPombal]

@An0n666

It will require a similar solution as #11847 but the dual listening issue with port randomization won't get fixed by that. Qbit will continue to listen on two different ports. Making such a bugged feature as default doesn’t make sense.

You are right, I totally missed the second point you made about different TCP/UDP ports. That should definitely be fixed.

EDIT: I saw your report on the libtorrent issue tracker (arvidn/libtorrent#4312). Looks like it will get fixed on the libtorrent side, no changes will be required for qBittorrent.

[ghost]

Fixed by arvidn/libtorrent#4314

[ghost]

@FranciscoPombal I noticed another great issue with port randomization. When you connect with a bunch of peers from one port and then restart your client and try to connect with a different port, those peers will not accept the connection. This is due to the fact that peers do not open multiple connections with the same IP.

[FranciscoPombal]

@An0n666

@FranciscoPombal I noticed another great issue with port randomization. When you connect with a bunch of peers from one port and then restart your client and try to connect with a different port, those peers will not accept the connection. This is due to the fact that peers do not open multiple connections with the same IP.

restart

If it is the case that the old connection is still alive after the restart, isn't that a bug in qBIttorrent or maybe libtorrent? In other words, there could have been a "dormant" bug that is now revealing itself.
Peers do not open multiple simultaneous connection to the same IP, but IIRC there should be no problem in connecting, tearing down the connection, and then connecting again, even if the second connection happens with a different port.

@arvidn thoughts?

[arvidn]

The actual connections should have been closed, yes. If they time out, the other end may still thinks it’s open (uTP times out pretty quickly though). Another thing that can have an effect here is that the DHT, trackers and peers still maintain your old port in their lists.

[FranciscoPombal]

@An0n666
Can you provide more detailed test results please? For example, what is the shortest restart delay that reproduces the problem?

[ghost]

The thing is even when the connection is closed from my end, the other end might still keep my IP:Port in their peer list. So until the other end announces to tracker and gets new port of mine, I'll not be getting any incoming connections to my new port. The other end will keep retrying the dead port instead. And when they are in a situation of attempting connections to an IP address, they might not accept any "other" incoming connections from same IP simultaneously. The peers will eventually connect maybe 30-60 mins later but that's an unnecessary delay.

[FranciscoPombal]

@An0n666 I see. Looks like @arvidn is adding the very same recommendation to the libtorrent docs, with arvidn/libtorrent#4335 (the new comment in settings_pack.hpp). In light of this, it is probably wise to revert #12000 and partly revert #11637.

[arvidn]

Looks like @arvidn is adding the very same recommendation to the libtorrent docs

based on the comments in this ticket btw. If someone has a reason to believe this issue is caused by something other than binding to port 0 on every startup, please let me know!

[FranciscoPombal]

@arvidn Hmm, in that case, looking at arvidn/libtorrent#4329 it seems @An0n666 suspects the issue is due to the port bind while other people suspect it has to do with interface binding, the latter of which should be fixed with arvidn/libtorrent#4331. So it is not certain that the port randomization is a problem after all.

@An0n666 Do you mind testing with arvidn/libtorrent#4331 and restarting the client in quick succession so that we can we can further narrow this down and be sure that the problem you are experiencing has to do with the port randomization and not to the other libtorrent issue?

[arvidn]

any verdict on the listen port 0 issue?
I'm leaning toward the advice to "pin" the listen port either way.

[ghost]

I tested again and what I can say is that peers do connect eventually but when you restart the client, the connections come much slower than regular. If connections take longer, that means you'll get slower download/upload speeds for some time. Many will not like this behavior.

[arvidn]

that sounds right to me. it will take some time for your new port to propagate through the swarm

[FranciscoPombal]

Sounds like (partially) reverting those PRs is in order then. I will do so shortly.

[FranciscoPombal]

PR is up: #12044