settings bug

Discuss suggestions and ideas for the forums, site, software.
Post Reply
Posts: 9
Joined: Wed Apr 29, 2015 5:39 am

settings bug

Post by spiroth10 » Wed Apr 29, 2015 6:33 am

I posted this in the windows forum, after inadvertantly stumbling upon it, not sure if its windows specific or what...

I discovered that certain settings refused to change, or changed themselves, in accordance with other settings. sometimes, a disabled option would remain enabled despite clicking 'apply', until another seemingly unrelated option was chosen that forced it off.

first I noticed the port changed after switching off my proxy to run some tests... I couldnt change it back until I switched the network adapter qbittorrent was bound to in advanced, then switched it back to the same network adapter again (Tunnel->any->back to VPN tunnel)... I figured... no biggie, its fixed!

then I realized that a fingerprint was still being put out there by the client to peers - it wasnt anything too dangerous, just a Local network IP, the kind that tells you which number connection you are (like, or 10.xx.x.x) -- it was given out alongside the proxy IP (or VPN IP, if proxy fails). Not a major thing, but still somewhat of a fingerprint -- it COULD have been worse had I had an IP leak or something...

this should NOT have happened, because my settings were spot on, and bittorrent/utorrent has no such problem! so I figured I'd experiment with DHT, shut it off, restarted -- still had the issue. so I figured... F*** it, and since all the other options were already ticked off anyway, I enabled privacy mode -- at this point, it disappeared!

so, im not done yet, I asked 'why is it that this happened? all the privacy mode settings were already off!" and then I realized, there were two settings it didnt change on setup, even though I ticked them off, and that was Upnp and NatPmp! I quickly re enabled DHT, peer exchange et all (except upnp/natpmp) and it STILL wasnt broadcasting the local IP!

the interesting thing was, I already had those unticked! they are the only possible settings that could leak any info out through the VPN and proxy like that! theres a *chance* someone in a swarm noticed, since I HAD used the client, but I dont think its a major issue -- could be a thousand local ips with that address!

but its still a major problem -- the settings manager should be applying the settings in real time as they are ticked off and applied, not after some other, seemingly arbitrary setting is changed! I shouldnt have to switch the network interface, then switch it back to change the Port Forwarding settings, and I shouldnt HAVE to enable and disable privacy mode in order for the client to realize I'd told it NOT to use Upnp/NatPmp...

I'm not sure if its just the windows version or what... Im not a good enough coder to look into it myself. but somone should definitely take a quick look at whats causing this in the code and patch it up. with my knowledge of C++, which isnt much, I'd say its not something that would jump out at you -- it may be as simple as two settings being related to each other, and a variable or class object fails to change until something else more important in terms of hierarchy tries to change that entry --

obviously privacy mode is ABOVE the other settings, because it disregards them and renders them null, so its possible in this release that the code renders changes to the other page null so long as privacy mode isnt turned on, and when it forces them off, it doesnt re enable natpmp/unpn until I check the boxes and apply it again.

although thats just a guess as I havent looked into the code, and know I'd only break the thing if I tried fixing it myself. I know a little of theh basics, but lack the knowledge and talent to make such a complex app myself.

sorry for the essay, I just thought being descriptive would help isolate the problem -- I do believe its a possible security threat, as some of the settings may possibly lead to IP leaks for users who work very hard to prevent that!

Posts: 62
Joined: Mon Oct 15, 2012 12:38 pm

Re: settings bug

Post by Seedthis » Wed Apr 29, 2015 10:40 am

Hi spiroth10,

Can't really tell if there is a bug or not as i'm not a dev and i also never used any VPN/proxy with qBT so i've never made any tests. I use qBt since something like 3 years though and my experience with the settings is that they apply right away.

Anyway, my network tech rusty skills tell me that i doubt peers can see your local IP as when you connect on the Web, an external IP is used. Routers don't let private IP pass. Those specific IP ranges you mentionned are forbidden on the Web.

For reference, bug tickets can be created on qbittorrent GitHub page, here :

User avatar
Forum addict
Forum addict
Posts: 2771
Joined: Sat May 18, 2013 4:08 pm

Re: settings bug

Post by ciaobaby » Wed Apr 29, 2015 12:12 pm

just a Local network IP, the kind that tells you which number connection you are (like, or 10.xx.x.x)
Of ABSOLUTELY no importance. As Seedthis says "Private" IP ranges are non-routable and therefore CANNOT be used to isolate or connect to, a machine from outside the local area network or subnet. (CIDR ranges, and )

IPs that your client displays in the execution logs are most definitely NOT what appears at trackers or remote clients and 'listeners'.
Smarter than the av-er-age bear, Boo Boo.,3084.0.html

Posts: 2413
Joined: Sun Jan 23, 2011 1:17 pm

Re: settings bug

Post by sledgehammer_999 » Sat May 02, 2015 11:00 pm


Summarize your wall of text if you want my opinion on your problems. (Your wall of text is good for documenation if there is actually a bug)

Post Reply