qbittorrent / qBittorrent

qBittorrent BitTorrent client
https://www.qbittorrent.org
Other
28.1k stars 3.96k forks source link

Occasional UDP packets being sent with destination port 0 #21298

Open LanceUMatthews opened 1 month ago

LanceUMatthews commented 1 month ago

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 DHT get_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

  1. Start a packet capture using a capture filter such as port 0.
  2. Start qBittorrent
  3. Observe captured packets

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

OptionsConnectionPeer connection protocol: is set to TCP and μTP OptionsConnectionUse UPnP / NAT-PMP port forwarding from my router is disabled

qBittorrent otherwise performs fine and the DHT: label shows 350+ nodes. I do not see any log entries related to these port 0 packets or the peers to which it is attempting to send them.

Log(s) & preferences file(s)

No response

luzpaz commented 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.

LanceUMatthews commented 1 month ago

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:

  1. Deleted the %LocalAppData%\qBittorrent\ directory
  2. Deleted the %AppData%\qBittorrent\ directory
  3. Created an %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.

255.44 seconds elapsed: DHT 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

255.56 seconds elapsed: DHT response received from 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

295.51 seconds elapsed: DHT 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

Summary

This same sequence of events occurred again with the same two peers above:

  1. 601.05 seconds elapsed: My machine sent a DHT Get_peers request to a.a.a.a
  2. 601.16 seconds elapsed: 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
  3. 602.23 seconds elapsed: My machine sent a DHT 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.

HanabishiRecca commented 1 month ago

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.