starred/qBittorrent

Fork 0

mirror of https://github.com/qbittorrent/qBittorrent.git synced 2026-03-02 22:57:32 -05:00

Occasional UDP packets being sent with destination port 0 #16041

New issue

Open

opened 2026-02-22 02:44:28 -05:00 by deekerman · 3 comments

deekerman commented

2026-02-22 02:44:28 -05:00

Owner

Originally created by @LanceUMatthews on GitHub (Sep 5, 2024).

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

Start a packet capture using a capture filter such as port 0.
Start qBittorrent
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

Options → Connection → Peer connection protocol: is set to TCP and μTP
Options → Connection → Use 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

Originally created by @LanceUMatthews on GitHub (Sep 5, 2024). ### 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 `Options` → `Connection` → `Peer connection protocol:` is set to `TCP and μTP` `Options` → `Connection` → `Use 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_

deekerman added the

Network

Libtorrent

labels

2026-02-22 02:44:28 -05:00

deekerman commented

2026-02-22 02:44:33 -05:00

Author

Owner

@luzpaz commented on GitHub (Sep 5, 2024):

@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.

@luzpaz commented on GitHub (Sep 5, 2024): @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.

deekerman commented

2026-02-22 02:44:37 -05:00

Author

Owner

@LanceUMatthews commented on GitHub (Sep 10, 2024):

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:

Deleted the %LocalAppData%\qBittorrent\ directory
Deleted the %AppData%\qBittorrent\ directory
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:

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

@LanceUMatthews commented on GitHub (Sep 10, 2024): 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... ```ini [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` <pre> 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 </pre> # 255.56 seconds elapsed: DHT response received from `a.a.a.a` contains peer `g.g.g.g` with port `0` <pre> 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 </pre> # 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. <pre> 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 </pre> # 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.

deekerman commented

2026-02-22 02:44:40 -05:00

Author

Owner

@HanabishiRecca commented on GitHub (Sep 11, 2024):

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.

@HanabishiRecca commented on GitHub (Sep 11, 2024): > 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.