mirror of
https://github.com/qbittorrent/qBittorrent.git
synced 2026-03-02 22:57:32 -05:00
The port reported to Tracker will be "0" even the proxy and anonymous mode are both turned off. #7138
Labels
No labels
Accessibility
AppImage
Bounty
Build system
CI
Can't reproduce
Code cleanup
Confirmed bug
Confirmed bug
Core
Crash
Data loss
Discussion
Docker
Documentation
Duplicate
Feature
Feature request
Feature request
Feature request
Filters
Flatpak
GUI
Has workaround
I2P
Invalid
Libtorrent
Look and feel
Meta
NSIS
Network
Not an issue
OS: *BSD
OS: Linux
OS: Windows
OS: macOS
PPA
Performance
Project management
Proxy/VPN
Qt bugs
Qt6 compat
RSS
Search engine
Security
Temp folder
Themes
Translations
Triggers
Waiting diagnosis
Waiting info
Waiting upstream
Waiting web implementation
Watched folders
WebAPI
WebUI
autoCloseOldIssue
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/qBittorrent#7138
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @partment on GitHub (Apr 12, 2018).
qBittorrent version and Operating System
4.0.4 on Windows 10 x64
What is the problem
The port reported to Tracker will be "0" even the proxy and anonymous mode are both turned off.
This lead to qB will not work in Private Tracker.
What is the expected behavior
The port reported to Tracker should be incoming and outcoming port.
Steps to reproduce
Just contact to Tracker
@partment commented on GitHub (Apr 12, 2018):
The Private Tracker will response "Invalid Port".
And get back to the backend of the Tracker it indicates that the port qB sent is "0"
@partment commented on GitHub (Apr 13, 2018):
Update : This problem will only happen with tracker using https as protocol.
@partment commented on GitHub (Apr 13, 2018):
Here's the tracker's logs.
@Supralateral commented on GitHub (Apr 23, 2018):
It really would be more helpful if you can provide more information. I can't reproduce this, on the same version/OS as you
Was this a one-off? Does it happen to one tracker, or all? What are your settings for the client? Anything disrupting your network? Have you done anything to troubleshoot?
@partment commented on GitHub (Apr 24, 2018):
This problem happens everytime on every tracker that used https as protocol and not the highest priority.
Here's my solution.
I let the Tracker accept http connection and adjust the priority of Tracker into highest like this.
If I adjust the priority of Tracker into second like this. It will be not working.
Notes:The private tracker will not allow port "0" as a peer. You only can reproduce this on the private tracker don't accept port "0".
@Supralateral commented on GitHub (Apr 24, 2018):
Okay, I can replicate this after adding another tracker. It seems to fail most of the time, but not always. Sometimes the start event will announce the correct port for the second tracker, but the stop event & any subsequent announce will be port=0.
It's not an issue with the HTTPS protocol: I'm seeing failures when both trackers are HTTP.
It looks like the port just isn't (generally) announced for anything other than the initial tracker.
Related: #8606 #5445 #5221
Are you using a SOCKS proxy? I am not, but I do have qBt set to use a specific network interface
Also, this is a private tracker that enables DHT/PEX/LSD and also lets you add new trackers to announce to? That's certainly an interesting take on the definition of private!
@partment commented on GitHub (Apr 24, 2018):
I am not using any kind of proxy such as SOCKS4 or SOCKS5 and the network interface is set to "any interface".
This tracker is allow to use DHT/PEX/LSD because it is just used to collect upload data from certain member in the group.
@KozakaiAya commented on GitHub (Apr 29, 2018):
Same issue here.
@colinhd8 commented on GitHub (Aug 15, 2018):
Same issue here
4.4.1 on ubuntu 18.04
@DJATOM commented on GitHub (Sep 13, 2018):
It seems libtorrent 1.1 is the culprit. 1.0 works fine when 1.1 fails to works as intended. Tested on qBittorrent EE fork with libt 1.0 and it just works.
@KozakaiAya commented on GitHub (Sep 13, 2018):
libt 1.1 seems to have a lot of unintended behaviors (like tracker announce and disk IO issues). I do hope qBittorrent won't drop the support for 1.0 branch in further versions.
@Chocobo1 commented on GitHub (Sep 14, 2018):
It still occurs with qbt v4.1.2 right?
@KozakaiAya commented on GitHub (Sep 14, 2018):
As far as I know, in dual-stack network environments, any qbt version compiled with libt 1.1 (and other BT clients baesd on libt, like Deluge) cannot announce both IPv4 and IPv6 address to the tracker. Writing the tracker's IPv4 address in the 'hosts' file on OS can help solve the problem but I don't think it's a permenant solution because the tracker's IP address may change.
For the IO issues, I actually haven't encountered this issue because I always run BT clients on HDD and it's not that fast. According some of my friends who use qbt on SSD, there still hashing speed problems even on libt 1.1.8. Related Issue: https://github.com/qbittorrent/qBittorrent/issues/9061
@Chocobo1 commented on GitHub (Sep 14, 2018):
@KozakaiAya
I see, however the announce issue you described seems to be not related to the opening post.
I'm concerned about the issue from OP, if the problems still occurs, we should ping @arvidn for it.
For the IO performance, we should see some improvements in the next release (v4.1.3), feel free to file an issue if it is still a problem.
@cbgilbert commented on GitHub (Oct 16, 2018):
Same issue here, using the official 4.1.3 release, windows 10.
I tried https and http tracker, and enabled/disabled socks5 proxy. The 4 results are the same.
@Supralateral commented on GitHub (Oct 20, 2018):
Not to be confused with enabling the "Disable connections not supported by proxies" option, which intentionally announces the port as 0.
@partment commented on GitHub (Nov 7, 2018):
I've done some researchs on libtorrent's source code.
It seems like the problem is come up with the if statement to decide what port will be sent.
In the "src/http_tracker_connection.cpp" has the following code.
i2p ? 1 : tracker_req().listen_portat line 124.If you disable the anonymous mode, this statement will request the port you assigned from
tracker_req().listen_portSo I'm wondering whether this request has some bugs?
Hopefully someone can get some further investigations.
@partment commented on GitHub (Nov 20, 2018):
This problem has been solved by this PR.
https://github.com/arvidn/libtorrent/pull/3452
@colinhd8 commented on GitHub (Nov 20, 2018):
Good news. Thanks.