DHT nodes shrink to 0 / zero after µTorrent 2.0.4

[bumpycars]

One of the reasons I cannot switch the local server to µTorrent versions past 2.0.4 is after loading the new build, the number of DHT nodes shrink to 0.

Starting at ~ 160 nodes gathered from 2.0.4, on the new build, over the next five minutes, the number decreases to 0. Without DHT nodes, DHT does not work -> no transfers. The local client doesn't use any trackers.

No other problems. The server is behind a router, a very capable Fritzbox 7570. Ports are forwarded, other µTorrent clients work fine. µTorrent is run with the /RECOVER switch, as there is more than one copy running on the same window session in the same account.

Please let me know what other information you would like about the configuration:

Windows XP SP3 w latest fixes (problem has been ongoing for four months, ever since trying newer builds past 2.0.4, then being forced to go back to 2.0.4 for the DHT problem)

EvilLord TCPIP.SYS patched to about 150 connections. Server has many other apps w/network connections, and at most, a few times a day the Eventlog has a 4226.

Terminal services unblocked. Ain't goina let some cruddy marketing department get me down.

[DreadWingKnight]

http://torrenthelp.depthstrike.com/2007/11/utorrent-dht-troubleshooting.html

[bumpycars]

i wrote a reply - forgot to 'post'

dreadwing - the issue, if it was corrupt DAT files, when upgrading, then downgrading, the DAT files would still be corrupt, yeah? It's only when going past 2.0.4 i.e. 2.2.x, the problem occurs. Downgrading, the issue goes away.

ready.

[bumpycars]

Upgraded to the release version of 2.2.

DHT gradually crept down while no torrents were using DHT anymore.

Quit, deleted DHT.* files and started again 2.2.

(0) Login, then '0 nodes'.

After 2.0.4 DHT is firewalled somehow within utorrent.

I run utorrent.exe with the /RECOVER switch as I have another copy running with /RECOVER in another folder. Did something change with the /RECOVER function?

[bumpycars]

Same thing with the latest build of 2.2.1x as of this post.

Login, then 0 nodes.

Going back to 2.0.4 it works perfectly.

Restarted with 2.0.4 and it's logging into DHT right away. The first update says '16' nodes and rapidly increases.

[Firon]

Why are you using /recover? Are you using the same port on both of them?

What is your firewall?

[whatvvv]

I have the exact same issue like bumpycars, DHT stopped working on newer versions after 2.0.4, so I'm stuck with using the outdated version because of it.

I deleted the .dht.dat and dht.dat.old files, didn't help.

Port used is the same in 2.0.4 and in newer version, (32459), and I don't use any software firewall, I use the inbuilt one from my Huawei HG520c modem.

If you need anything else about my setup, please ask, off the top of my head I don't think there's anything that would cause a conflict with utorrent.

I will also test all v2.2 builds and post in what specific build the problem started happening.

[bumpycars]

whatev: thanks

firon:

That's a good question, firon.

First see http://forum.utorrent.com/viewtopic.php?pid=544544#p544544

Using the hypothethized example:

(low-scheduling priority) utorrent1.exe /RECOVER is running on port 55000, and the net.outgoing_port is 55002 and the net.outgoing_max_port is 55499.

(lowest-scheduling priority) utorrent2.exe /RECOVER is running on port 55001, and the net.outgoing_port is 55500 and the net.outgoing_max_port is 55999.

Both utorrents have separate folders, e.g. D:\utorrent1 and D:\utorrent2. There are two separate shortcuts on the desktop, one points to "D:\utorrent1\utorrent1.exe /RECOVER" and the second points to "D:\utorrent2\utorrent2.exe /RECOVER".

These two copies run side-by-side perfectly, until around 2.x, when the other issue (see link) crept up during updates alone. After 2.0.4, DHT dies, so no matter what the update thus far, utorrentx.exe must be down-graded to 2.0.4.

Thanks for your great gift!

[whatvvv]

I have tested all 2.2 builds, installing one on top of another, (first the earliest version), and testing each and every for DHT not working.

To my surprise, DHT worked on each and every one of the builds I tested, including the latest, final 2.2 version.

I don't know if I missed a version or two earlier when upgrading and that's why my problem happened, but it's fixed now and DHT is working great.

[bumpycars]

whatvvv based on your reply i unhopefully tried it again:

shrank from 157 nodes to 3 nodes in 15 minutes.

So it still doesn't work / there is a bug.

here are the preferences in the advanced section:

bt.connect_speed 30 (tcpip.sys has been patched)

bt.enable_tracker true

bt.ratelimit_tcp_only true

bt.tcp_rate_control false

bt.transp_disposition 26 (tried 255 no difference)

bt.use_rangeblock false

gui.report_problems false

net.calc_overhead true

net.max_halfopen 15

net.outgoing_max_port 61999

net.outgoing_port 61600

rss.update_interval 360

Build uTorrent 23703

[Firon]

Leave the settings alone. Close µTorrent then delete your settings.dat and settings.dat.old.

[bumpycars]

reset all the settings except for net.outgoing_port and net.outgoing_max_port (as I have other services using other ports) and it continues to sit there doing nothing 'Waiting to log in.'

Going back to 2.0.4 until the bug is fixed.

[DreadWingKnight]

You didn't follow the directions given.

[Firon]

I didn't tell you to reset the settings. I told you to delete your settings and leave them all alone.

[bumpycars]

some of the settings I need, like outgoing port and max outgoing port.

I'll delete the files the next time.

I know you are barking up the file corruption tree, and unless you think it's own code that's done it, the server has a 3ware 9500B-8 hardware RAID 1, and hasn't had a single file-corruption problem in 3.5 years since installing the card. The drives are a second set, Samsung 1TB 5-year warranty raid drives; been running fine for almost 2 years.

The power lines are all buried and maintained properly; there are brownouts or power interruptions at most about once every 6 months. Whereas generally on north america and many other places, likely where you're at, brownouts are several times daily. Very common to have file corruption problems under those circumstances. And the server has a BackUPS-Pro on it for kicks.

[bumpycars]

Okay.

I made a folder separate, for the utorrent 2.2.1x build (latest as of today).

I ran it with /RECOVER, and it insisted on the wizard.

So I directed it to install in the same special folder as I had originally downloaded 2.2.1 *.upx.exe to.

There were not utorrent.exe's created, or any files.

The DAT files were placed in Application Data\utorrent, NOT the special folder set-up.

This is a problem.

Yes, the DHT nodes build, however /RECOVER is broke.

[Firon]

Making a separate folder is not enough. You need to put a blank settings.dat in the same directory as the exe.

[bumpycars]

If the proxy is set to TOR and the Socks type remains at 5, this causes the DHT to not work in versions past 2.0.4.

I changed the proxy setting to Socks4 and DHT logs in again/ works with versions > 2.0.4.

So I don't know if there is some different handling? of the proxy requests?

Or a bug?

[DreadWingKnight]

Tor doesn't support UDP traffic.

Additionally, neither us, nor the Tor development team supports nor endorses the use of torrent clients over Tor.

[bumpycars]

uTorrent 2.0.4 works over the Socks4 setting as well as Socks5.

Maybe better with Socks4.

uTorrent > 2.0.4 works only with the Socks4 setting.

(TOR)

Additionally, it is not sending the bulk of data over TOR, only some of the overhead.

What that has to do with UDP traffic, I don't know?

uTorrent is using UDP via the newer protocols between clients for data transfer? fine.

The proxy is not being used for the main data transfer.

[Firon]

DHT is UDP-based. Some SOCKS5 proxies do not provide UDP support, so your UDP traffic will stop working.