uTorrent 1.8.1 WINE unconnectable after period of time (w/ workaround)

On my computer I have seeding a couple hundred torrents after anywhere from 5 minutes to 5 hours the computer no longer becomes connectable, it seems all inbound attempts (even using "telnet localhost port") seems to time out rather than return closed and the application still seems bound to the port.

It immediately becomes connectable again after changing port then changing it back... Or restarting uT.

I found a fix is to set the half-open to ~50 or higher. It seems the 8 get used up and it no longer responds, setting it to like 4 generally makes the symptoms occur immediately.

Are you using 1.8.1 stable?

What version of WINE?

I had tested wine versions .96 through 1.15 which I have now. They all did the same thing.

Sorry no I did not see 1.8.1 stable, I have RC1 which was current as of what 2 days ago , I'll report back w/ info on the new stable.

I noticed it about 5-6 betas ago and could not pinpoint what it was.

edit:

Aye same thing in 1.8.1 stable. It works for a min or so then it just times out, it might be because I have so many torrents and a larger number is simply needed? I'm not sure and I do not have a solid background and understanding in how tcp works in that regard with half-open or if that 8 is filled it would cause problems... If you let it sit it does not seem to go away like the 8 is just causing extreme delays leading to a "timeout" situation... But opening additional half open, 50 seems to work great, seems to cure the problem.

I also notice everything else in uT slows down as well, its like no new connections can be made in or out, its really weird when it does it, Firon pm me if you want to see for yourself and experiment...

Have you tried raising the ulimit for the utorrent process? Raise it to some unreasonably high number to make sure you're not coming even close to reaching the limit (like 20000 or something). It's a long shot, but it's worth trying.

I'm having the same problem as tazeat with utorrent on Wine 1.0 / Ubuntu Server 8.04. After a while, utorrent no longer accepts incoming connections. Outgoing connections still work in my case. Changing the incoming port to another value and then back to the original value makes utorrent connectable again.

After a restart (or changing ports), the error usually occurs within a week, and occasionally within a couple of hours. I'm only running (seeding) about 10-15 torrents at a time on my DSL connection. The server has a VIA 1.2 GHz CPU.

I have seen this problem with utorrent 1.6.1 and 1.8.0 (which I'm currently using).

When the error occurs, an nmap scan reports that the incoming port is filtered instead of open. Also, the nmap port scan connection attempt does not show up in the utorrent log for incoming connections (like it does when utorrent is accepting connections). "netstat -tulpen" still reports that utorrent.exe is listening on the port. Even when the incoming port is blocked (filtered), utorrent is still responding to webUI connections (I using a different port for that).

Use 1.8.1 ... try not using an alternate listen port?

You MUST upgrade to Wine 1.1.6 or later.

I also have this problem (see my eariler post here: http://forum.utorrent.com/viewtopic.php?id=46451)

I'm going to try the latest wine release and as suggested above...

EDIT- Wine-1.1.12 - Bug still occurs

I was wondering if you are still having the same problem. I have been running utorrent 1.8.2 build 14458 through Wine 1.0.1 on Ubuntu 8.10 for about a month now with no problems. I haven't left it running for more than 12 or so hours at a time however. I was searching the forum trying to find that post about the flickering problem when I found your post. (I stopped the flickering by unticking the "Show current speed in the titlebar" option).

I am still having the problem described in original post. It seems quite easy for me to duplicate it (1-2hours).

Info:

# wine --version

wine-1.1.20

Running: µTorrent 1.8.3 beta 15358

Once the port becomes unconnectable, I cannot connect to WebUI and telnet.

Let me know if I could help debugging this issue, Its been there since version 1.6.xx

I also have the problem of the original poster, and the workaround suggested does not help at all.

wine-1.1.21, utorrent 1.8.2

I'd also not mind helping, this problem makes utorrent almost unusable as seeding becomes impossible, which means it should have high priority IMO, as there is definitely no worthy replacement for utorrent on linux.

edit: also, for me sometimes on starting utorrent, the connectability icon is red saying listening error, and utorrent has to be restarted (with a 5 minute wait in between)

I have this issue as well. I tried setting my half open to 50, then 250. It hasn't worked. Running 1.82 on wine 1.0.1. I'll try updating wine soon.

update: problem persists in wine 1.1.22 with utorrent 1.8.2.

Perhaps this is an issue with people who have large amounts of torrents loaded? I noticed the op mentioned he was seeding a couple hundred. I have 600 torrents loaded on mine. My current connection settings are 4000 global max connections, 50 max connected peers/torrent, 4 uploads per torrent, 100 max number of active torrents.

update:

As a temporary measure, I've moved my utorrent inside of a virtualbox and it works fine. There is definitely a discrepancy between the network functionality of running utorrent through virtualbox or through wine.

My only issue left is that I have my files mounted remotely and using samba instead of sshfs seems to limit me to ~6megs/sec, which may not be fast enough to read as I sometimes upload faster than this. I'll toy around later with virtualbox's shared folder feature and sshfs.

update #2:

I think I've found the source of this. A while back, I turned off net.ipv4.tcp_syncookies because it was flooding my kernel messages.

Recently, I noticed that the webui lags horribly every once in a while (over the local network). So I'm guessing that the port was being flooded pretty badly. So I've since turned net.ipv4.tcp_syncookies back on and I also set net.ipv4.tcp_max_syn_backlog to 8192. (It was set at 1024). I get my /var/log/messages flooded with "kernel: possibly SYN flooding on port xxxx. Sending cookies." once a minute but it keeps me connectible I think. Also, my webui never lags anymore.

Here's a helpful article on TCP/IP stacks: http://www.securityfocus.com/infocus/1729

"During a SYN attack the system generates a response by sending back a packet with a cookie, instead of rejecting the connection when the SYN queue is full. When a server receives a packet with the ACK flag set (the last stage of the three-way handshake process) then it verifies the cookie. When its value is correct, it creates the connection, even though there is no corresponding entry in the SYN queue. Then we know that it is a legitimate connection and that the source IP address was not spoofed. It is important to note that the SYN cookie mechanism works by not using the backlog queue at all, so we don't need to change the backlog queue size."

So, in short:

echo 1 > /proc/sys/net/ipv4/tcp_syncookies

sysctl -w net.ipv4.tcp_max_syn_backlog="8192" (You can also use a lower number, I noticed that 4096 did the trick for me)

You may want to check that neither of these commands conflict with your /etc/sysctl.conf or else they may become undone next time you reboot.

I'll post any more updates I have on this. On one of my trackers that I have 100 trackers loaded on, I'm now fully connectible all the time. Another tracker though still shows me as not connectible.