OS: CentOS 8.0 (linux)
I am running the beta version as I wanted to use the latest 1.2 libtorrent-rasterbar library in case that fixes the problem. The problem exists in 4.1.8 and 4.1.9 and libtorrent 1.1.x as well (or may well be nothing to do with any of them).
First, everything is working. I can search for and download torrents, DHT shows 376 nodes.
I have a single port open on my firewall for both UDP and TCP, IPv4 and IPv6, port 30123.
The problem that I have is that my firewall logs many attempted accesses to tcp and udp port 1. I thought initially these might just be port probes or attacks but after some analysis these attempted connections are valid DHT (usually get_peers). I have noticed this (port 1 access) for over a year but have only just invested the time to examine it.
Sometimes there are two udp connects to port 1 followed by a tcp connect from the same client (all of which time out as they are blocked). That is, a client is deliberately trying to connect using DHT.
From netstat -a nothing (including qBittorrent) is listening on port 1 so there is no point in opening the firewall.
From packet traces some remote torrent clients are using port 1 (as an incoming port). My qBittorrent has perfectly reasonable conversations between 30123 (my local port) and port 1 on a remote torrent client. (There is nothing wrong with this). However, at my end I am not using port 1.
I have noticed my local qBittorrent also 'tries' port 1. I have a packet trace where it tries 3 times to send DHT UDP local:30123 to remote:33333 and gets no response and then tries remote:1 (port 1). Eventually it got a DHT reply to 30123. This is worrying and surely wrong.
Is port 1 a legitimate DHT fallback port or is the (local and/or remote) code broken?
Thank you for reading this far.
Does anyone have any ideas as to the cause of the problem?
Linux specific questions, problems.
1 post • Page 1 of 1