Open LanceUMatthews opened 1 month ago
@LanceUMatthews any way you can show the evidence of this, that would be super helpful. TIA for the detective work of tracking the bug down.
I hope sharing the relevant packets of a packet capture in text format with identifiers anonymized is sufficient. I don't have IPv6 enabled on this network at the moment so that's why all the peers have only IPv4 addresses.
I started with a new configuration for qBittorrent:
%LocalAppData%\qBittorrent\
directory%AppData%\qBittorrent\
directory%AppData%\qBittorrent\qBittorrent.ini
file with the following contents...
[BitTorrent]
Session\Port=54321
...so I could know in advance what port to forward in the firewall and leave everything else as default.
I started a Wireshark packet capture on the local machine and then started qBittorrent, for which I accepted the initial legal prompt and let sit idle. Over the course of 70 minutes I captured only two packets with destination port 0
, but I think there's enough information in the overall capture to understand what's going on.
Get_peers
request sent to a.a.a.a
Internet Protocol Version 4, Src: 10.0.0.2, Dst: a.a.a.a User Datagram Protocol, Src Port: 54321, Dst Port: 61585 BitTorrent DHT Protocol Request arguments: Dictionary... Key: a Value: Dictionary... id: bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb info_hash: cccccccccccccccccccccccccccccccccccccccc Terminator: e Request type: get_peers Transaction ID: c111 Version: 11111111 Message type: Request Terminator: e
a.a.a.a
contains peer g.g.g.g
with port 0
Internet Protocol Version 4, Src: a.a.a.a, Dst: 10.0.0.2 User Datagram Protocol, Src Port: 61585, Dst Port: 54321 BitTorrent DHT Protocol ip: 192.168.1.1 Key: ip IP: 192.168.1.1 Port: 61846 Response values: Dictionary... Key: r Value: Dictionary... id: dddddddddddddddddddddddddddddddddddddddd nodes: 8 Key: nodes Value: 8 nodes Node 1 (id: eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee, IPv4/Port: e.e.e.e:32404) Node 2 (id: ffffffffffffffffffffffffffffffffffffffff, IPv4/Port: f.f.f.f:3073) Node 3 (id: gggggggggggggggggggggggggggggggggggggggg, IPv4/Port: g.g.g.g:0) Node 4 (id: hhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh, IPv4/Port: h.h.h.h:32908) Node 5 (id: iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii, IPv4/Port: i.i.i.i:36987) Node 6 (id: jjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjj, IPv4/Port: j.j.j.j:6881) Node 7 (id: kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk, IPv4/Port: k.k.k.k:1688) Node 8 (id: llllllllllllllllllllllllllllllllllllllll, IPv4/Port: l.l.l.l:6881) p: 61846 token: 22222222 Terminator: e Transaction ID: c111 Version: 33333333 Message type: Response Terminator: e
Get_peers
request sent to g.g.g.g
on port 0
Prior to this packet being sent, my machine sent 7 Get_peers
packets to different peers in 5-second intervals starting at 260 seconds elapsed.
Internet Protocol Version 4, Src: 10.0.0.2, Dst: g.g.g.g User Datagram Protocol, Src Port: 54321, Dst Port: 0 BitTorrent DHT Protocol Request arguments: Dictionary... Key: a Value: Dictionary... id: bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb info_hash: mmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm Terminator: e Request type: get_peers Transaction ID: c222 Version: 11111111 Message type: Request Terminator: e
This same sequence of events occurred again with the same two peers above:
Get_peers
request to a.a.a.a
a.a.a.a
sent a DHT response to my machine with mostly the same list of nodes as before, including g.g.g.g:0
Get_peers
request to g.g.g.g
on port 0
In both instances it is clear that qBittorrent is sending a packet to destination port 0
simply because that is the port specified for that peer in the DHT.
In both instances it is clear that qBittorrent is sending a packet to destination port
0
simply because that is the port specified for that peer in the DHT.
I guess you have answered your own question. Some DHT node sends bogus info and your client attempts to connect.
Providing actual IPs would have been useful though. If this is a broadcast/multicast address, it could make your router (depending on configuration) to retransmit the packet across the network.
qBittorrent & operating system versions
qBittorrent: 4.6.6 x64 Operating system: Windows 10 Pro 22H2 Build 19045.4780 x64 Qt: 6.4.3
Installer:
qbittorrent_4.6.6_x64_setup.exe
What is the problem?
During a packet capture on my router I noticed UDP packets with destination port
0
being sent from the address and port used by qBittorrent running on another machine. A capture by Wireshark running on that machine shows a roughly even split between DHTget_peers
requests and what Wireshark calls "DNPv100" / "DOF Protocol Stack".My router is not passing these packets to the internet, though even if it did I would not expect them to ever get a response given the invalid port. With the capture running for a little while it appears to be many of the same hosts being queried repeatedly and, curiously, several of them are IPv4 addresses where the last 1-3 octets are
0
.Steps to reproduce
port 0
.With 135 torrents loaded sometimes there are several of these port
0
packets sent in the same second, sometimes several in a span of 1-2 minutes, and sometimes there is ~5 minutes between them.Additional context
Options
→Connection
→Peer connection protocol:
is set toTCP and μTP
Options
→Connection
→Use UPnP / NAT-PMP port forwarding from my router
is disabledqBittorrent otherwise performs fine and the
DHT:
label shows 350+ nodes. I do not see any log entries related to these port0
packets or the peers to which it is attempting to send them.Log(s) & preferences file(s)
No response