Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Topics - Switeck

Pages: [1]
Generic / Chilling effects on qBitTorrent...
« on: July 23, 2017, 04:36:38 am »
These represent a threat to all of us:
AV false-flagging open source BitTorrent software as malware is nothing new, but it still causes a chilling effect that scares away a LOT of people.
I've seen it a few times in the last couple years, and I don't know yet whether to blame it on a campaign to shut qBT down, sheer incompetence, or both.
Google arbitrarily refusing to allow ads and ad revenue for BitTorrent software projects is more severe.

"Witness, the decline of society."
Where free speech and free expression ...that isn't liked by others ...can get shut down silently through back-door means.

Generic / Warning: If you're using a VPN or proxy...
« on: June 08, 2017, 10:53:53 am »
DON'T port forward your router to BitTorrent clients using a VPN or proxy and DISABLE both UPnP and NAT-PMP in their settings!
"Is removing for UPnP/NAT-PMP/Firewall Exception required for true privacy?"
"Yes, disabling those features is required for true privacy."

A consequence of this is you probably won't get any incoming connections...
"Yesterday I checked out a few different SOCKS Proxy programs and NONE of them support incoming connections."
...But if you do, they may now know your real IPv4 address.

Many proxies (or proxy-like entities such as Tor) don't support UDP packets, which udp trackers, DHT, and uTP peers/seeds all use.
Tor is terrible for torrents, and at best only fit to proxy http tracker updates separate from the torrent peer-to-peer traffic.

If these BT clients are set up for private trackers only...have DHT, PEX, LPD/LSD, duplicate ips (on the same torrent), and peering disabled. Private torrents disable those on a per-torrent basis anyway but if DHT and LSD/LPD are enabled they will still run in the background passing OTHER peer/seed traffic using your BT client as a pass-through. Out of all of those only PEX doesn't make additional ip connections -- it reuses already-connected peer connections to send ip lists of other peers/seeds on the same torrent.

If DHT and PEX are not running, getting magnet links to work can be extremely difficult -- either they have to include working tracker/s embedded in the magnet link or you have to manually add trackers in the hopes of finding one that tracks that torrent.

VPNs and Proxies also put a heavier load on a computer's networking and CPU than without, so IF your VPN or proxy is regularly crashing...
It may be a good idea to reduce global max connections, per torrent max connections, and half open connection max.
If the BitTorrent clients are running through wifi, that may overload the wifi from time-to-time. It's a far bigger cpu load for the modem/router/gateway to have to handle busy wifi than busy ethernet at the same speeds.
In any case, limit upload speed to slightly below the max upload speed that your connection can sustain while using the VPN or proxy...otherwise, you're just begging for it to randomly crash.

Not leaking your local internet ip+port is difficult -- you may need to look into internet kill switches and special setups for individual BT clients for that:

Deluge and qBitTorrent are surprisingly BAD at working with VPNs and proxies...
"If binding to the specified network address fails, the dæmon silently ignores the setting and binds to, thus using any available network interface."
"This is a problem because I (and I guess, many people who might want to use it) want my p2p traffic to go exclusively through my VPN. Another use case is people with a 3G connection; you might want to bind to wlan0 when you're at home and traffic is free, but definitely don't want it to go through the cell interface."
"So Deluge will only download given a working proxy; it's just not using that proxy."  FIXED (supposedly) in Deluge 1.3.15!   "to prevent bugs with accidentally unsetting the proxy values Deluge now only sets a single proxy ... This is a stopgap measure for 1.3 code and is properly fixed for 2.0 release."
No incoming connections even after setting Port and Proxy

qBt traffic escapes allowed interface
[PROBLEM] qbt can expose DSL-IP, although VPN is used
If network interface connection drops while using proxy torrent still downloads
Both Deluge and qBitTorrent have LOTS of problems at this time. qBT's v4.1-v4.3 updates should resolve some of the very worst ones...

ANYTHING that's using libtorrent (qBT and Deluge do) likely have the same problems...this includes Halite, MooPolice, and a few others...and they haven't been updated to newer versions of libtorrent.

uTorrent/BitTorrent also can leak in-the-clear if VPN/proxy goes down:
"Using Socks5 Proxy In Utorrent, I Still Got A Copyright Notice"
"uTorrent does NOT respect your proxy restrictions when it comes to stuff like DHT and peer exchange.  This is a known issue in older versions, and I don't know if it got fixed in later versions.  I still use 2.2.1, but have have a firewall rule in place blocking traffic to/from uTorrent that aren't to PIA IPs."
"Disable features that leak identifying information will prevent BitTorrent from sharing your non-proxied IP throught handshakes with other peers, as well as through DHT.It will also prevent it from handing out your IPv6 address to IPv4 peers and vice versa."

uTorrent, VPN and Browser  "Unless opera offers a way to use external programs through their provided vpn, uTorrent CANNOT use it."

Tixati has issues as well:
VPN no protection?!
DHT Handles leak (SERIOUSLY lags a computer!)
Can't get over ~12MB/s total downstream

Transmission doesn't even support proxies (except possibly partially for non-udp trackers)
Best VPN Services for Transmission Torrent Client
transmission-daemon high memory usage. potential leak? "At init, transmission-daemon uses about 300MB, but over the course of several hours or days it can grow up to over 3.5GB."
Transmission limit to 100 Mbs ?
I tested on a 1Gb link and I can only get 40-50 Mbits/s out of it. also "I cant upload higher than 11 MB/s but I have got 200 Mbps."

Vuze can probably be configured to be secure, but it's notorious for having the most complex settings configuration. (uTorrent configuration is actually more complex in some ways, but most people don't mess with its advanced settings!)

Generic / EXTREME Speed Tests of various BitTorrent Apps
« on: November 15, 2015, 04:22:26 am »
Speed tests over loopback/ Windows
Test conditions:
-Using multiple BitTorrent clients on the same computer over loopback.
-The files being transferred are all on a ramdrive (almost 5 GB DDR3), so effectively ruling out slow drives as well.
-CPU is Intel i5 650 3.2 GHz -- dual core with hyperthreading.
-Unless stated otherwise, these speeds are all UPLOAD speeds to uTorrent v2.2.1.
-The test is a single TCP connection at a time -- 1 seed to 1 peer, which may show severe pipelining issues. Multiple seeds to multiple peers could be faster depending on program designs, but would certainly cause a much larger CPU load.
-As many settings as possible were disabled in the various BT clients -- no DHT, LPD, trackers, uTP, and even half open connections were set as low as possible since only 1 connection had to be made. Were more settings enabled, CPU loads should be higher. Peers were manually added to the torrent so even a local tracker was unnecessary.

*Tixati v2.2.5 -- 55 MB/sec peak and sustained 30 MB/sec. ( maxes out a CPU core -- 25% of CPU's max as it has 4 virtual cores)

Seems Tixati acts single-threaded and is unable to spread its CPU load between multiple cores.
When I set other very high CPU-using apps to highest priority and Tixati to lower priority, its speeds plummeted -- it even stalled out and crashed once.

*Transmission v2.84 for Windows -- 37 MB/sec often being unable to sustain an upload speed over 20 MB/sec (CPU usage: at 2-5%...)
   Tixati to Transmission is a "blazing fast" 8 MB/sec.
   Transmission to Tixati runs at 12.5 MB/sec.

*Deluge v1.3.12 -- 101 MB/sec. (CPU ~36% , ~40% in non classic/BG mode)

*uTorrent v2.2.1 -- 130 MB/sec, 100 MB/sec sustained   (CPU: 25%) -- this was uploading to qBitTorrent.

*qBitTorrent v3.3.0beta --  130 MB/sec, 120 MB/sec sustained (CPU: 33-36%)
   qBitTorrent to Transmission strangely also runs at 8 MB/sec. Transmission is at 2% CPU...qBT while uploading to Transmission is bouncing between 0-2% CPU.
   Transmission to qBitTorrent runs at 111 MB/sec.

-Both Deluge and qBitTorrent use libtorrent, so results are similar.
-uTorrent writes whole pieces in 1 go,  qBT and Deluge do not:
-Deluge 10 Gbit/sec seedbox results:
-Deluge has its own speed problems:
-multi-file torrents are slower than single file torrents of the same size:,2627.msg12725.html#msg12725

Even with the fastest possible connection and storage devices, common BitTorrent clients are likely incapable of significantly exceeding 1 gigabit/sec (~120 MB/sec) transfer speeds due to their complexity and/or lack of parallel processes. The tests were typically bottlenecked by my "slow" CPU. If I disabled hyperthreading, a BT client could use half my CPU and possibly be faster.

Windows / qBT 3.1.3 mismatching file timestamp?
« on: December 05, 2013, 10:19:01 am »
I got this error on starting up qBT v3.1.3 on Win XP Pro SP3:
05/12/2013 02:55:22 - Reason: fast resume rejected: mismatching file timestamp

I fear it's due to Windows doing daylight savings time update which mucked up the file timestamps.
This is going to be a real pain adding back a torrent that's nearly 200 GB in size.

Windows / qBT 3.0.10 Set Location... bug
« on: July 13, 2013, 12:38:00 pm »
Set Location...
...Attempts to do a COPY of the data if data is found at current location and the destination location is a different drive.

This can be very messy if the torrent is very large (like >100 GB) and the drive/s to store the torrent on are slow.
qBT appears to freeze up while it is copying the data from the old location to the new location.
If you exit qBT while this is going on, qBT gets stuck in memory.
Attempts to relaunch qBT fails, presumably until the move task is completed.

Windows / qBT 3.0.10 >500MB cache size can trigger crash + hashfails
« on: July 13, 2013, 12:36:22 pm »
When qBT 3.0.10 reaches ~530 MB ram used, I get this weird error message:
13/07/2013 04:57:34 - Reason: Torrent file () error: Not enough space
13/07/2013 04:57:34 - An I/O error occured, 'Torrent' paused.
(Note: 'Torrent' is not actually the name of the torrent in question.)

As I tried to open the Options as qBT reached the ~530 MB ram usage limit, I got this crash:

This seems to be the result of me setting qBT's write/read cache to 1000 MB size coupled with my fast upload speed of 600 KB/sec.
Neither the weird error message nor the crash occurred with the cache set to <400 MB.

The qBT 3.1.0alpha builds also exhibit this bug:,1747.msg7138.html#msg7138

Strangely, qBT 3.0.9 experiences this bug as well, but only once it exceeds ~1600 MB ram used.
This required me setting qBT 3.0.9's cache to 1800 MB.

Remote peers may receive bad pieces as a result of this bug, as this logfile from another BT client of qBT's behavior shows:

[03:46:05]  x.x.x.x:6881 Connecting: source: C
[03:46:05]  x.x.x.x:6881 [qBittorrent/ (0.0)]: Handshake completed
[03:46:21]  x.x.x.x:6881 [qBittorrent v3.0.10 (100.0)]: Disconnect: Connection closed
[03:47:00]  x.x.x.x:6881 Connecting: source: C
[03:47:00]  x.x.x.x:6881 Disconnect: Connection closed
[03:47:51]  Incoming connection from x.x.x.x:4855
[03:47:51]  x.x.x.x:4855 [qBittorrent/ (0.0)]: Handshake completed
[03:47:53]  *** PIECE 787 FAILED HASH CHECK
[03:47:53]  Banned x.x.x.x:4855: [qBittorrent v3.0.10 (100.0)]: -qB30A0-q4pb%28PwLOBIx (508 MB downloaded, 3.98 MB bad)
[03:47:53]  x.x.x.x:4855 [qBittorrent v3.0.10 (100.0)]: Disconnect: Banned
[03:48:53]  Incoming connection from x.x.x.x:4858
[03:48:53]  x.x.x.x:4858 [qBittorrent/ (0.0)]: Handshake completed
[03:49:09]  x.x.x.x:4858 [qBittorrent v3.0.10 (100.0)]: Disconnect: Connection closed
[03:49:47]  x.x.x.x:6881 Connecting: source: I
[03:49:47]  x.x.x.x:6881 [qBittorrent/ (0.0)]: Handshake completed
[03:51:08]  x.x.x.x:6881 [qBittorrent v3.0.10 (100.0)]: Disconnect: Connection closed
[03:51:55]  x.x.x.x:6881 Connecting: source: I
[03:51:56]  x.x.x.x:6881 Disconnect: Peer error: No connection could be made because the target machine actively refused it.
[03:52:22]  Incoming connection from x.x.x.x:4868
[03:52:22]  x.x.x.x:4868 [qBittorrent/ (0.0)]: Handshake completed
[03:52:23]  *** PIECE 37340 FAILED HASH CHECK
[03:52:36]  x.x.x.x:4868 [qBittorrent v3.0.10 (100.0)]: Disconnect: Connection closed
[03:53:09]  x.x.x.x:6881 Connecting: source: I
[03:53:09]  x.x.x.x:6881 [qBittorrent/ (0.0)]: Handshake completed
[03:53:26]  x.x.x.x:6881 [qBittorrent v3.0.10 (100.0)]: Disconnect: Connection closed
[03:54:08]  x.x.x.x:6881 Connecting: source: I
[03:54:08]  x.x.x.x:6881 [qBittorrent/ (0.0)]: Handshake completed
[03:54:22]  x.x.x.x:6881 [qBittorrent v3.0.10 (100.0)]: Disconnect: Peer error: An existing connection was forcibly closed by the remote host.
[03:55:28]  x.x.x.x:6881 Connecting: source: I
[03:55:29]  x.x.x.x:6881 Disconnect: Peer error: No connection could be made because the target machine actively refused it.
[03:56:33]  Incoming connection from x.x.x.x:4876
[03:56:33]  x.x.x.x:4876 [qBittorrent/ (0.0)]: Handshake completed
[03:56:52]  x.x.x.x:4876 [qBittorrent v3.0.10 (100.0)]: Disconnect: Connection closed

Pages: [1]