mirror of
https://github.com/qbittorrent/qBittorrent.git
synced 2026-03-02 22:57:32 -05:00
qBittorrent does not check if ports are open and does not reopen ports after router reboot #9845
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#9845
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 @whoodini on GitHub (Mar 5, 2020).
Originally assigned to: @FranciscoPombal on GitHub.
Please provide the following information
qBittorrent version and Operating System
qBittorrent 4.2.1 on Windows 10 1909.
If on linux, libtorrent-rasterbar and Qt version
(type here)
What is the problem
qBittorrent does not check if the ports are open and does not reopen the ports after router reboot.
Nor does Random button in Options -> Connection open the ports. It changes the port but does not open it in router (router is a mikrotik).
I need to manually restart the whole qBittorrent in order for it to open the ports.
What is the expected behavior
I would expect the qBittorrent to check the ports every x (60 min) and try to open/reopen them again. Router might have rebooted or lost connection or was a power outage.
Steps to reproduce
Simple, just reboot your router.
Extra info(if any)
Fixed ports and no reboots would be a fix but not the correct one.
I do weekly reboots and random ports.
ty
@ghost commented on GitHub (Mar 6, 2020):
Why not just forward the ports manually?
@whoodini commented on GitHub (Mar 6, 2020):
I do not think that predictability is good thing in some cases. I think random would be better in my case.
Besides, routers have UPnP, it is a good thing, it works and we should use it.
Im not an expert on networking, but imo and fwik manual/fixed ports are used when: one does not know how to do it/one does not care/one wants to be done quick, equipment is incompatibile, equipment is old or needs high reliability no matter the costs.
@Seeker2 commented on GitHub (Mar 6, 2020):
qBitTorrent sometimes doesn't even activate UPnP on the selected port...and instead activates UPnP on a different one: https://github.com/qbittorrent/qBittorrent/issues/11816
(This is likely triggered when using random ports...)
Incoming connections is not guaranteed proof UPnP port forwarding is working -- uTP connections (which use UDP packets) can use a version of STUN to bypass NAT routers under some conditions.
Only incoming TCP peer/seed connections is proof of an unfirewalled incoming path to qBitTorrent through local networking (routers, firewalls, etc).
@whoodini commented on GitHub (Mar 6, 2020):
I can see in my router if the ports are open, how many are open and which ports are open. I can also see bytes and packets.
Currently I see in IP -> Firewall -> NAT, 2 opened ports:
protocol:6(tcp) dst port:49692 opened by: upnp "local-IP": qBitorrent/4.2.1
protocol:17(udp) dst port:50105 opened by: upnp "local-IP":qBitorrent/4.2.1
and qBitorrent/4.2.1 lists "Port for incoming connections: 25897" its a random one.
PS. qBitorrent execution log reports:
05.03.2020 23:43 - UPnP/NAT-PMP: Port mapping successful, message: successfully mapped port using UPnP. external port: UDP/50105
05.03.2020 23:43 - UPnP/NAT-PMP: Port mapping successful, message: successfully mapped port using UPnP. external port: TCP/49692
05.03.2020 23:43 - Successfully listening on IP: fe80::70a5:ebad:9c24:1563%9, port: UDP/52083
05.03.2020 23:43 - Successfully listening on IP: fe80::70a5:ebad:9c24:1563%9, port: TCP/49695
05.03.2020 23:43 - Successfully listening on IP: 0.0.0.0, port: UDP/50105
05.03.2020 23:43 - Successfully listening on IP: 0.0.0.0, port: TCP/49692
05.03.2020 23:43 - UPnP / NAT-PMP support [ON]
there is no mention in the log about the port 25897.
PPS. I can confirm with canyouseeme.org and ipvoid.com/udp-port-scan that the truly opened ports are the ones reported by the router. Why does the IPv6 have different ports?
@Seeker2 commented on GitHub (Mar 6, 2020):
I thought (normally?) the same port was supposed to be used for both UDP and TCP -- so incoming TCP and uTP peers/seeds go to the same destination.
Most trackers only hand out a single port per ip address...and it could be the wrong one with multiple port destinations that are TCP or uTP specific.
@mschumacher69 commented on GitHub (Mar 7, 2020):
How can I check in qBitorrent if the port is open or not?
@FranciscoPombal commented on GitHub (Mar 7, 2020):
@arvidn does libtorrent support periodically checking UPnP?
@arvidn commented on GitHub (Mar 8, 2020):
This really seems like a fringe use case. Why is this important? Is it common to restart routers?
yes, but it's disabled. A long time ago, libtorrent would request a UPnP port forward that expired in 1 hour, and then refresh it. Some routers don't support port forwards with expiration times, so they would send a 725 error code back. This would make libtorrent retry with a permanent lease duration.
However, it turned out that there are also UPnP routers that don't support returning the 725 error code. To make it work on those, I just disabled the expiration time logic and always mapped permanent port forwards.
Maybe we're in a time now where we don't need to care about shitty UPnP implementations (although, I'm not convinced there really are any good ones, it's just a shitty protocol in general).
Perhaps I should restore the periodic refreshing of the port map.
Here's the code in libtorrent.
@FranciscoPombal commented on GitHub (Mar 8, 2020):
@arvidn
If they are shitty, yes. And my guess would be that many people have shitty ISP-provided routers.
Still, even if it is a fringe case, it seems wrong for libtorrent to break down like this due to a router restart.
IMO the best approach would be:
@arvidn commented on GitHub (Mar 8, 2020):
In the long run, I would like to remove support for UPnP, now that the world is moving towards PCP (which is a much more reasonable protocol).
Would anyone be interested in giving this patch a try? It's simply restoring the 1 hour expirations of UPnP port maps. https://github.com/arvidn/libtorrent/pull/4406
@Seeker2 commented on GitHub (Mar 8, 2020):
"This really seems like a fringe use case."
...That gets reported pretty often: https://github.com/qbittorrent/qBittorrent/issues/11759#issuecomment-596001851
A LOT of people are too lazy or unable to manually port forward and configure firewalls, so sadly UPnP is still needed for now.
@FranciscoPombal commented on GitHub (Mar 8, 2020):
@arvidn
It will take a looooong time before UPnP usage becomes insignificant enough to be ignored.
The patch is a good idea, but I still think exposing an option to set this to zero would be ideal, to also not leave the users with only shitty UPnP implementations at their disposal completely SOL
@arvidn commented on GitHub (Mar 9, 2020):
If I understand correctly, the two opposing sides to my patch are:
Since I have no idea which one is more common, it makes sense to have an escape hatch from whichever becomes the default. Not having it work automatically, though, probably means that most people affected by a bad router won't ever notice, let alone do something about it.
I don't want to hold up the 1.2.5 release by this. I will make this change for 1.2.6.
@Seeker2 commented on GitHub (Mar 9, 2020):
UPnP mapping to the wrong port or ports still needs to be dealt with though, even if this issue temporarily goes untouched.
UPnP remapping ports probably shouldn't be done or even allowed faster than every 1-5 minutes, or it might cause bigger problems with a router's internal resource consumption (extra load on its weak CPU and limited ram).
Were there to be a default remapping of the port via UPnP, I'd recommend only once per day...with advanced option to change it.
If the router replies it's already forwarded (due to UPnP requests?) and/or incoming TCP connections continue to arrive, do not remap via UPnP.
uTP could be incoming due to STUN, so only if it can be determined that's not happening should it be used to indirectly determine if UPnP port-forward/firewall bypass is still working.
@whoodini commented on GitHub (Mar 9, 2020):
@arvidn
PCP (standardized in 2013, already 7+ years old) does not seem to be taking off too soon, maybe you will do a implementation of it in 10-15 years (if it does not die first or gets replaced by something else).
Yes this is the most common cause.
I know the speeds that my qBittorrent should reach and whenever does not go as it is supposed to, I go and investigate. I do not know what kind of equipment you guys run but im confident that most of the users using qBittorrent have the default or SOHO comercial type and not the business kind.
Like I said im done with default or SOHO types, im now into business entry level type of equipment (Mikrotik) and im sure I wont be upgrading again.
@Seeker2
No, this is not my case (I do know how to do manual port forwarding), I would like to use UPnP and qBittorrent with the intention of having my port changed whenever the router reboots again, out of security concerns, do you know how difficult is to track fragmented traffic through different ports and IPs.
@FranciscoPombal
I think the same.
Taking into account all the different router manufactures and their dodgy implementations, can qBittorrent use a service to check for port forwarding and report it back to user into UI?
PS As far as I understood, UPnP supports queries. You could query the router to check if it has opened the ports and if not, open them (maybe even check for lease duration). Link
@arvidn commented on GitHub (Mar 9, 2020):
libtorrent has supported PCP since version 1.2.
My router supports it (granted, it's fairly new).
I would be surprised if PCP would die before UPnP. It's a much simpler protocol for both clients and servers, as a result, it works reliably.
@whoodini commented on GitHub (Mar 9, 2020):
It seems it is true. UPnP supports queries and much more.
I think photos speak for themselves.
No worries, I have restarted the device after the screenshots were made. new dynamic wan IP, new dynamic lan IP, new dynamic port, as it should be.
I see no implementation of UPnP lease duration in windows or router, nor did I come across one before.
@arvidn commented on GitHub (Mar 9, 2020):
port maps with expiration times can be found here, search for
NewLeaseDuration.@FranciscoPombal commented on GitHub (Mar 9, 2020):
Yes this seems reasonable. IMO you should cater to the "good" implementations by default. As for the config change not happening automatically, for the users who have routers that don't support temporary leases: that's fine. It can simply be documented, even in the qBittorrent wiki FAQ for example:
"If you're having trouble with UPnP, it is possible your router is shitty and does not support temporary leases. In that case, disable them by selecting the xyz checkbox...."
@ghost commented on GitHub (Mar 9, 2020):
Why go for periodic leases? Why not just query the UPnP device and check if the port is forwarded or not every 5 mins?
@arvidn commented on GitHub (Mar 10, 2020):
Because if your network breaks/your computer reboots/your client crashes/... the router will still remove the port map. It won't "leak".
@whoodini commented on GitHub (Mar 10, 2020):
The whole point of this issue is to query UPnP:
if no open ports, open new ports.
if there are opened ports BUT old ports, delete them.
if there are opened ports AND are the actual ports we need, keep moving these are not the ports you are looking for.
I found several UPnP "explorers", they can read UPnP scheme and request XML files.
@arvidn commented on GitHub (Mar 10, 2020):
That's not my reading. That seems to be your suggestion of a solution. The problem is that some routers reboot and lose their port mappings sometimes.
If you think that solution is better than what @FranciscoPombal and I have proposed, please post your arguments. The cost of your solution is significant complexity and increased risk of bugs and maintenance burden, most likely falling on me (along with finding someone actually do the work of implementing it).
@FranciscoPombal commented on GitHub (Mar 10, 2020):
For now, and more specifically, for the current issue at hand, the proposed solution above will do. Seems like @whoodini's solution is more comprehensive, but at a much greater cost. Something like that can always be implemented in the future.
@arvidn commented on GitHub (Mar 11, 2020):
I've updated the PR. Please give it a try! https://github.com/arvidn/libtorrent/pull/4406
@NotTsunami commented on GitHub (Mar 15, 2020):
For those with issues, I have a PR up on the qBittorrent side that you can use to play with the value yourself, it
currently inherits the new libtorrent default of 1 hourretains the previous default of permanent leases (duration set to 0). To test it prior to merge you will need to use the latest libtorrent RC_1_2 branch and change the libtorrent references in the PR to version 1.2.5 as libtorrent 1.2.6 has not been released yet.@FranciscoPombal commented on GitHub (Apr 4, 2020):
This has been fixed in 4.2.3, since this version now includes the libtorrent commit that changes the upnp default lease duration to 1 hour. Customization of the duration (including the possibility of disabling it, like previously) will come with the next release of qBIttorrent that ships with libtorrent 1.2.6 (most likely 4.2.4)