[Bug 26031] New:=?UTF-8?Q?=20=C2=B5Torrent=20?=(uTorrent) fails listening to a port after a number of persistent connections are opened against it

http://bugs.winehq.org/show_bug.cgi?id=26031

Summary: µTorrent (uTorrent) fails listening to a port after a
                    number of persistent connections are opened against it
           Product: Wine
           Version: 1.3.13
          Platform: All
               URL: http://www.utorrent.com/
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: wineserver
        AssignedTo: [e-mail]
        ReportedBy: [e-mail]

Steps to reproduce:

1) Run µTorrent
2) Incoming connections icon should turn green (port listen: OK), netstat -ln
confirms that
3) Start downloading any torrent
4) Incoming connections icon will turn red (Listen error: you should change the
listen port)

observe these errors logged in uTorrent Logger Tab:

[2011-02-09 02:28:50]     ***   Starting Diagnostic thread   ***
[2011-02-09 02:28:50]  IPv6 is installed
[2011-02-09 02:31:46]  TCP port bind failed 0.0.0.0:9001: (10048) Error 10048
[2011-02-09 02:32:12]  TCP port bind failed 0.0.0.0:9001: (10048) Error 10048

at this point neither Wine, nor µTorrent will be listening to the designated
port:

# netstat -ln -eep | grep 8008
udp        0      0 0.0.0.0:8008                0.0.0.0:*                      
        500        117033     10470/uTorrent.exe

so while uTorrent is listening to the incoming UDP connections, TCP traffic is
unmanaged causing the errors in the µTorrent's Logger Tab.

The strangest thing is that no other application will be able to use this port
(8008):

# nc -vl 8008
nc: Address already in use

However if I order nc to bind to the loopback interface specifically, it will
run:

# nc -vl localhost 8008
[running]

It's worth noting that when wine/uTorrent "listen" abilities break, there are
already some established connections to my_external_IP_address:8008 (right now
I see three such ESTABLISHED connections).

So, probably there's some sort of bug in wine server - it shouldn't stop
listening to a port when persistent connections are made to it - but I'm
totally uncertain about it because I have no idea how wine server (should)
handles TCP traffic.

I can help solving this bug by attaching any required debug information if it's
necessary.

[Bug 26031]=?UTF-8?Q?=20=C2=B5Torrent=20?=(uTorrent) fails listening to a port after a number of persistent connections are opened against it

http://bugs.winehq.org/show_bug.cgi?id=26031

Juan Lang  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|wineserver                  |-unknown

--- Comment #1 from Juan Lang  2011-02-08 16:10:11 CST ---
Please don't guess the component.  wineserver doesn't do much with sockets,
actually.

[Bug 26031]=?UTF-8?Q?=20=C2=B5Torrent=20?=(uTorrent) fails listening to a port after a number of persistent connections are opened against it

http://bugs.winehq.org/show_bug.cgi?id=26031

--- Comment #2 from Artem S. Tashkinov  2011-02-08 16:15:54 CST ---
(In reply to comment #1)
> Please don't guess the component.  wineserver doesn't do much with sockets,
> actually.

Most manuals mention wineserver specifically when dealing with Wine network
hacks (assigning `setcap cap_net_raw=eip` capabilities) - so I thought it's the
first candidate for this bug/problem.

[Bug 26031]=?UTF-8?Q?=20=C2=B5Torrent=20?=(uTorrent) fails listening to a port after a number of persistent connections are opened against it

http://bugs.winehq.org/show_bug.cgi?id=26031

Austin English  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |download

[Bug 26031]=?UTF-8?Q?=20=C2=B5Torrent=20?=(uTorrent) fails listening to a port after a number of persistent connections are opened against it

http://bugs.winehq.org/show_bug.cgi?id=26031

--- Comment #3 from Artem S. Tashkinov  2011-02-08 16:22:16 CST ---
It seems like bug 18714 loosely talks about the same issue (but since I've
described the problem much better, I believe the old bug should be made
duplicate of the newer one).

[Bug 26031]=?UTF-8?Q?=20=C2=B5Torrent=20?=(uTorrent) fails listening to a port after a number of persistent connections are opened against it

http://bugs.winehq.org/show_bug.cgi?id=26031

--- Comment #4 from Artem S. Tashkinov  2011-02-08 16:24:45 CST ---
I'm sorry for flooding but my first message in this bug report should read:

[2011-02-09 02:31:46]  TCP port bind failed 0.0.0.0:8008: (10048) Error 10048
[2011-02-09 02:32:12]  TCP port bind failed 0.0.0.0:8008: (10048) Error 10048

[Bug 26031]=?UTF-8?Q?=20=C2=B5Torrent=20?=(uTorrent) fails listening to a port after a number of persistent connections are opened against it

http://bugs.winehq.org/show_bug.cgi?id=26031

Artem S. Tashkinov  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
             Blocks|                            |18714

[Bug 26031]=?UTF-8?Q?=20=C2=B5Torrent=20?=(uTorrent) fails listening to a port after a number of persistent connections are opened against it

http://bugs.winehq.org/show_bug.cgi?id=26031

Dan Kegel  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

--- Comment #5 from Dan Kegel  2011-02-08 21:39:12 CST ---
Does raising ulimit per
http://wiki.winehq.org/FAQ#head-80aeef30021fc0bae9ba2254f9ce6e249577ea93 help?

[Bug 26031]=?UTF-8?Q?=20=C2=B5Torrent=20?=(uTorrent) fails listening to a port after a number of persistent connections are opened against it

http://bugs.winehq.org/show_bug.cgi?id=26031

Dmitry Timoshkov  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
           Platform|All                         |Other

[Bug 26031]=?UTF-8?Q?=20=C2=B5Torrent=20?=(uTorrent) fails listening to a port after a number of persistent connections are opened against it

http://bugs.winehq.org/show_bug.cgi?id=26031

--- Comment #6 from Artem S. Tashkinov  2011-02-09 04:02:03 CST ---
(In reply to comment #5)
> Does raising ulimit per
> http://wiki.winehq.org/FAQ#head-80aeef30021fc0bae9ba2254f9ce6e249577ea93 help?

That didn't help it at all.

$ ulimit -H -n
8192

[Bug 26031]=?UTF-8?Q?=20=C2=B5Torrent=202?=.2.0 fails listening to a port after a number of persistent connections are opened against it

http://bugs.winehq.org/show_bug.cgi?id=26031

Artem S. Tashkinov  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P2                          |P4
            Summary|µTorrent (uTorrent) fails   |µTorrent 2.2.0 fails
                   |listening to a port after a |listening to a port after a
                   |number of persistent        |number of persistent
                   |connections are opened      |connections are opened
                   |against it                  |against it
           Severity|normal                      |minor

--- Comment #7 from Artem S. Tashkinov  2011-04-30 05:23:31 CDT ---
µTorrent 2.2.1 is not affected, so I'm lowering this bug importance.

[Bug 26031]=?UTF-8?Q?=20=C2=B5Torrent=202?=.2.0 fails listening to a port after a number of persistent connections are opened against it

http://bugs.winehq.org/show_bug.cgi?id=26031

--- Comment #8 from Artem S. Tashkinov  2011-09-04 12:07:36 CDT ---
(In reply to comment #7)
> µTorrent 2.2.1 is not affected, so I'm lowering this bug importance.

it _is_ affected, it just takes some time before the bug manifests itself.

[Bug 26031]=?UTF-8?Q?=20=C2=B5Torrent=202?=.2.0 fails listening to a port after a number of persistent connections are opened against it

http://bugs.winehq.org/show_bug.cgi?id=26031

Bruno Jesus  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

--- Comment #9 from Bruno Jesus  2011-10-02 10:57:36 CDT ---
I have been running utorrent 2.2.1 for over 3 months (non-stop) and have never
seen this error. My connection icon is green and the log shows nothing related
to listen errors.

I'm restarting utorrent now in latest wine git to try reproducing this error.
Artem, please, retest in latest wine version too.

If you disable the uTP feature does it happens faster?

[Bug 26031]=?UTF-8?Q?=20=C2=B5Torrent=202?=.2.0 fails listening to a port after a number of persistent connections are opened against it

http://bugs.winehq.org/show_bug.cgi?id=26031

--- Comment #10 from Artem S. Tashkinov  2011-10-03 05:58:45 CDT ---
(In reply to comment #9)

You can reproduce this bug in an instant - try changing download speed limit
while downloading/seeding any torrent - the issue will surface immediately.

And yes, I can reproduce this bug using the latest Wine snapshot.

[Bug 26031]=?UTF-8?Q?=20=C2=B5Torrent=202?=.2.0 fails listening to a port after a number of persistent connections are opened against it

http://bugs.winehq.org/show_bug.cgi?id=26031

Bruno Jesus  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1

--- Comment #11 from Bruno Jesus  2011-10-09 13:39:37 CDT ---
After retesting I can confirm this bug exists, although it's quite hard for me
to reproduce. I'm still looking for a reliable way to reproduce. Wine version
1.3.29.

[Bug 26031]=?UTF-8?Q?=20=C2=B5Torrent=20loses=20the=20ability=20of=20listening=20to=20incoming=20connections?=

http://bugs.winehq.org/show_bug.cgi?id=26031

Artem S. Tashkinov  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|µTorrent 2.2.0 fails        |µTorrent loses the ability
                   |listening to a port after a |of listening to incoming
                   |number of persistent        |connections
                   |connections are opened      |
                   |against it                  |

[Bug 26031]=?UTF-8?Q?=20=C2=B5Torrent=20loses=20the=20ability=20of=20listening=20to=20incoming=20connections?=

http://bugs.winehq.org/show_bug.cgi?id=26031

--- Comment #12 from Artem S. Tashkinov  2011-10-09 16:04:17 CDT ---
(In reply to comment #11)
> After retesting I can confirm this bug exists, although it's quite hard for me
> to reproduce. I'm still looking for a reliable way to reproduce. Wine version
> 1.3.29.

It seems like during its operation µTorrent (sometimes has to) reinitializes
the listening port and since at this time some connections can already be
opened against the same port, the Linux kernel refuses the application to
bind()/listen() to this port.

You can easily see it's the case, since `netstat -ln` won't show any
applications listening to the port.

So, this seems like a problem with the Linux TCP sockets design because under
Windows no such problem exists.

You can easily reproduce this problem in Linux using a native application this
way:

1) Start listening to a port
2) Open a connection against this port from the other side
3) Kill -9 this application, so that you have at least one connection opened
4) Try to run this application again - it won't run as the Linux kernel won't
let it bind()/listen() due to stale open connections

[Bug 26031]=?UTF-8?Q?=20=C2=B5Torrent=20loses=20the=20ability=20of=20listening=20to=20incoming=20connections?=

http://bugs.winehq.org/show_bug.cgi?id=26031

--- Comment #13 from Bruno Jesus  2011-10-09 21:13:11 CDT ---
If you kill the application the tcp status will change to time wait preventing
new binds to that port until the timer ends. You can use the SO_REUSEADDR to
prevent that. It happens in windows too.

I'm still wondering why it needs to reopen the listening door. I'm capturing
+winsock logs to see that.

[Bug 26031]=?UTF-8?Q?=20=C2=B5Torrent=20loses=20the=20ability=20of=20listening=20to=20incoming=20connections?=

http://bugs.winehq.org/show_bug.cgi?id=26031

--- Comment #14 from Bruno Jesus  2011-10-25 19:00:13 CDT ---
After more research I think there is nothing wrong in wine. I found a reliable
way to reproduce the bug too: open utorrent and after it start listening you
run wineserver -k.

This will leave the port in a unknown state (possibly TIME_WAIT) and the
GNU/Linux default timeout for this is 60 seconds. If you reopen utorrent or any
other program that tries to bind the same port the OS will refuse saying the
address is already in use. If you wait 60 seconds and retry the bind and listen
will work.

uTorrent should retry listening from time to time because this may happen in
windows too. You can also set the "Randomize port on each start" to get around
this. If utorrent used SO_REUSE_ADDR this should have not happened too.

Last thoughts: IMO this is an OS TCP implementation bug that cannot be fixed in
wine.

Any thoughts, Artem?

[Bug 26031]=?UTF-8?Q?=20=C2=B5Torrent=20loses=20the=20ability=20of=20listening=20to=20incoming=20connections?=

http://bugs.winehq.org/show_bug.cgi?id=26031

--- Comment #15 from Artem S. Tashkinov  2011-10-26 01:44:26 CDT ---
I'm not a TCP/IP or OS expert so I believe the best avenue for this bug
resolution is to notify uTorrent developers about it in hopes that they will
fix it.

[Bug 26031]=?UTF-8?Q?=20=C2=B5Torrent=20loses=20the=20ability=20of=20listening=20to=20incoming=20connections?=

http://bugs.winehq.org/show_bug.cgi?id=26031

Jerome Leclanche  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

--- Comment #16 from Jerome Leclanche  2011-10-28 18:02:01 CDT ---
(In reply to comment #14)
Does that mean this bug is invalid?

[Bug 26031]=?UTF-8?Q?=20=C2=B5Torrent=20loses=20the=20ability=20of=20listening=20to=20incoming=20connections?=

http://bugs.winehq.org/show_bug.cgi?id=26031

--- Comment #17 from Dan Kegel  2011-10-28 18:14:47 CDT ---
The original problem doesn't sound like something that happens
in windows, so probably not invalid?

[Bug 26031]=?UTF-8?Q?=20=C2=B5Torrent=20loses=20the=20ability=20of=20listening=20to=20incoming=20connections?=

http://bugs.winehq.org/show_bug.cgi?id=26031

--- Comment #18 from Juan Lang  2011-10-28 20:34:44 CDT ---
In this case it appears to be a difference in kernel implementation of sockets,
which we tend to treat as invalid, as it'd have to be fixed upstream (and won't
be, realistically.)

[Bug 26031]=?UTF-8?Q?=20=C2=B5Torrent=20loses=20the=20ability=20of=20listening=20to=20incoming=20connections?=

http://bugs.winehq.org/show_bug.cgi?id=26031

--- Comment #19 from Artem S. Tashkinov  2011-10-29 01:49:57 CDT ---
(In reply to comment #18)
> In this case it appears to be a difference in kernel implementation of sockets,
> which we tend to treat as invalid, as it'd have to be fixed upstream (and won't
> be, realistically.)

Wine should mimic Windows sockets behaviour, shouldn't it? So if sockets work
differently between the Unix/Posix world and the Windows world Wine should
strive to provide maximum Windows compatibility.

Besides, as far as I can understand adding SO_REUSEADDR to socket() invocation
just cannot hurt, so if it helps to solve this issue, I think it would be best
to change the default Wine behaviour in regard to listening sockets.

[Bug 26031]=?UTF-8?Q?=20=C2=B5Torrent=20loses=20the=20ability=20of=20listening=20to=20incoming=20connections?=

http://bugs.winehq.org/show_bug.cgi?id=26031

--- Comment #20 from Bruno Jesus  2011-11-02 09:51:56 CDT ---
Enabling SO_REUSEADDR by default may break other applications. I'm still
working on this. The problem is in how kernel handles killed apps with opened
socket handles. I'm trying to determine if the listen error in errno can be
used to trigger a special handling.

[Bug 26031]=?UTF-8?Q?=20=C2=B5Torrent=20loses=20the=20ability=20of=20listening=20to=20incoming=20connections?=

http://bugs.winehq.org/show_bug.cgi?id=26031

--- Comment #21 from Bruno Jesus  2011-11-10 21:35:54 CST ---
Created attachment 37438
  --> http://bugs.winehq.org/attachment.cgi?id=37438
Try to use SO_REUSEADDR by default

Well, after reading a lot of internet pages and trying several different
attempts I think it's possible to say that it's a kernel bug or a
characteristic of the kernel tcp implementation.

The attached patch forces SO_REUSEADDR in before every bind in an attempt to
fix the problem but it only works if the program exits cleanly (so the kernel
sets the socket to TIME_WAIT), if you do "wineserver -k" the socket will remain
opened in an unknow broken state and no applications will be able to use it
(wine or native linux apps).

Output of strace:
getsockopt(24, SOL_SOCKET, SO_REUSEADDR, [0], [4]) = 0
setsockopt(24, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
bind(24, {sa_family=AF_INET, sin_port=htons(43012), sin_addr=inet_addr("0.     
0.0.0")}, 16) = -1 EADDRINUSE (Address already in use)

It's possible to see that I'm checking if SO_REUSEADDR is enabled and then
enable it. But the bind fails anyway.

I still think this is a WONTFIX and kernel related. I'm using 2.6.32-5-amd64,
maybe newer kernels behave in a different way. If you have a newer kernel can
you test the patch?

Useful links:
http://itamarst.org/writings/win32sockets.html
http://www.ibm.com/developerworks/library/l-sockpit/
http://hea-www.harvard.edu/~fine/Tech/addrinuse.html

[Bug 26031]=?UTF-8?Q?=20=C2=B5Torrent=20loses=20the=20ability=20of=20listening=20to=20incoming=20connections?=

http://bugs.winehq.org/show_bug.cgi?id=26031

--- Comment #22 from Bruno Jesus  2011-11-13 20:40:42 CST ---
I'm trying to compile and test wine in freebsd and osx, if they don't have this
problem I will be sure this is a linux bug.

[Bug 26031]=?UTF-8?Q?=20=C2=B5Torrent=20loses=20the=20ability=20of=20listening=20to=20incoming=20connections?=

http://bugs.winehq.org/show_bug.cgi?id=26031

--- Comment #23 from Artem S. Tashkinov  2011-12-31 10:27:49 CST ---
(In reply to comment #22)
> I'm trying to compile and test wine in freebsd and osx, if they don't have this
> problem I will be sure this is a linux bug.

Unfortunately your patch didn't help:

[2011-12-31 16:26:25]  TCP port bind failed 0.0.0.0:10000: (10048) Error 10048

I'm running Linux kernel 3.2-rc7

[Bug 26031]=?UTF-8?Q?=20=C2=B5Torrent=20loses=20the=20ability=20of=20listening=20to=20incoming=20connections?=

http://bugs.winehq.org/show_bug.cgi?id=26031

--- Comment #24 from Bruno Jesus  2012-01-01 14:04:18 CST ---
I'm still testing in other systems and mostly convinced it's a kernel bug.

[Bug 26031]=?UTF-8?Q?=20=C2=B5Torrent=20loses=20the=20ability=20of=20listening=20to=20incoming=20connections?=

http://bugs.winehq.org/show_bug.cgi?id=26031

--- Comment #25 from Bruno Jesus  2012-01-25 20:09:23 CST ---
The last approach I've been trying is to close all open socket handles during
wineserver -k. So no applications would hold the port.

[Bug 26031]=?UTF-8?Q?=20=C2=B5Torrent=20loses=20the=20ability=20of=20listening=20to=20incoming=20connections?=

http://bugs.winehq.org/show_bug.cgi?id=26031

--- Comment #26 from Bruno Jesus  2012-07-24 19:43:59 CDT ---
I finally ended my research about this bug. IMO it's really upstream, it's a
linux kernel implementation characteristic. It does not happen in OSX nor in
PC-BSD. When the application dies the kernel hold the port and does not allows
anyone to reuse it. It can be tested not only with wine but with linux
applications like socat.

[Bug 26031]=?UTF-8?Q?=20=C2=B5Torrent=20loses=20the=20ability=20of=20listening=20to=20incoming=20connections?=

http://bugs.winehq.org/show_bug.cgi?id=26031

Artem S. Tashkinov  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://bugzilla.kernel.org
                   |                            |/show_bug.cgi?id=45571

[Bug 26031]=?UTF-8?Q?=20=C2=B5Torrent=20loses=20the=20ability=20of=20listening=20to=20incoming=20connections?=

http://bugs.winehq.org/show_bug.cgi?id=26031

--- Comment #27 from Dan Kegel  2012-08-04 10:13:41 CDT ---
Bruno, can you write a small Linux C program that automatically
reproduces the problem?

[Bug 26031]=?UTF-8?Q?=20=C2=B5Torrent=20loses=20the=20ability=20of=20listening=20to=20incoming=20connections?=

http://bugs.winehq.org/show_bug.cgi?id=26031

--- Comment #28 from Bruno Jesus  2012-08-04 17:46:35 CDT ---
(In reply to comment #27)
> Bruno, can you write a small Linux C program that automatically
> reproduces the problem?

The easiest way to reproduce is using utorrent.

wine utorrent_2.2.1.exe & sleep 6; pkill -9 utorrent; wine utorrent_2.2.1.exe

See the failed to bind error in utorrent log.

[Bug 26031]=?UTF-8?Q?=20=C2=B5Torrent=20loses=20the=20ability=20of=20listening=20to=20incoming=20connections?=

http://bugs.winehq.org/show_bug.cgi?id=26031

--- Comment #29 from Artem S. Tashkinov  2012-08-08 04:15:02 CDT ---
Alan Cox thinks otherwise:

Comment #1 From Alan 2012-08-08 09:07:57 (-) [reply]
> I don't think this is a bug - the re-use rules for an existing connection mean
> you can't re-use the same connection addressing for a time period.
>
> Should be discussed on [e-mail] if you think otherwise

All I can say is "WTF. Seriously?"

Can someone with a better background in networking please send a message to
this mailing list? It's definitely a bug and this behavior is definitely
broken, yet one of the most prominent Linux kernel developers thinks otherwise.

[Bug 26031]=?UTF-8?Q?=20=C2=B5Torrent=20loses=20the=20ability=20of=20listening=20to=20incoming=20connections?=

http://bugs.winehq.org/show_bug.cgi?id=26031

--- Comment #30 from Dan Kegel  2012-08-08 08:29:02 CDT ---
This is why a tiny C test case is needed.  It definitely sounds like a
standard TCP/IP behavior (if you haven't read
http://www.kohala.com/start/tcpipiv1.html yet, please do, it's a pleasure!).
But since Bruno's sure it's not standard, the burden is on him to make
a tiny plain C test case that illustrates the problem.

[Bug 26031]=?UTF-8?Q?=20=C2=B5Torrent=20loses=20the=20ability=20of=20listening=20to=20incoming=20connections?=

http://bugs.winehq.org/show_bug.cgi?id=26031

--- Comment #31 from Bruno Jesus  2012-08-08 08:44:51 CDT ---
(In reply to comment #29)
> All I can say is "WTF. Seriously?"

Well, as I said before it may be a TCP implementation characteristic. You can
look for what TCP TIME_WAIT state means.
http://www.unixguide.net/network/socketfaq/2.7.shtml
http://serverfault.com/questions/329845/how-to-forcibly-close-a-socket-in-ti...

IMO uTorrent should be smarter and try to bind from time to time, maybe it does
that in newer versions.

I'll dig further in the next week. The question is why SO_REUSEADDR is failing
when it's supposed to jump the TIME_WAIT.

[Bug 26031]=?UTF-8?Q?=20=C2=B5Torrent=20loses=20the=20ability=20of=20listening=20to=20incoming=20connections?=

http://bugs.winehq.org/show_bug.cgi?id=26031

--- Comment #32 from Artem S. Tashkinov  2012-08-08 09:24:49 CDT ---
(In reply to comment #31)
> Well, as I said before it may be a TCP implementation characteristic. You can
> look for what TCP TIME_WAIT state means.
> http://www.unixguide.net/network/socketfaq/2.7.shtml
> http://serverfault.com/questions/329845/how-to-forcibly-close-a-socket-in-ti...
>
> IMO uTorrent should be smarter and try to bind from time to time, maybe it does
> that in newer versions.
>
> I'll dig further in the next week. The question is why SO_REUSEADDR is failing
> when it's supposed to jump the TIME_WAIT.

It surely works in all NT versions of Windows (win 9x uses a different TCP/IP
stack/implementation, besides I doubt uTorrent is compatible with the latter),
I see no reason why it shouldn't work in Linux.

The kernel can easily track dead previously opened connections (after all the
TCP/IP connection has all the required features for that, i.e. the unique
sequence, source address and destination address) at the same time allowing to
reuse the socket. This whole issue smells more like it's unwillingness on the
part of kernel developers than the issue which requires to rework/reimplement
something.

[Bug 26031]=?UTF-8?Q?=20=C2=B5Torrent=20loses=20the=20ability=20of=20listening=20to=20incoming=20connections?=

http://bugs.winehq.org/show_bug.cgi?id=26031

--- Comment #33 from Dan Kegel  2012-08-08 09:28:40 CDT ---
You can't accuse them of anything until you have a minimal test case.

[Bug 26031]=?UTF-8?Q?=20=C2=B5Torrent=20loses=20the=20ability=20of=20listening=20to=20incoming=20connections?=

http://bugs.winehq.org/show_bug.cgi?id=26031

--- Comment #34 from Artem S. Tashkinov  2012-08-08 09:46:08 CDT ---
Created attachment 41316
  --> http://bugs.winehq.org/attachment.cgi?id=41316
server.c

(In reply to comment #33)
> You can't accuse them of anything until you have a minimal test case.

Steps to reproduce:

1) winegcc -O2 -lwsock32 -I/opt/wine/include/wine/msvcrt -lmsvcrt server.c
2) (Text console 1) ./a.out
3) (Text console 2) telnet localhost 2007
Enter anything and press enter
4) (Text console 1) Ctrl + C
5) (Text console 2) nc -l 2007
nc: Address already in use

As simple as it is.

[Bug 26031]=?UTF-8?Q?=20=C2=B5Torrent=20loses=20the=20ability=20of=20listening=20to=20incoming=20connections?=

http://bugs.winehq.org/show_bug.cgi?id=26031

Artem S. Tashkinov  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #41316|text/x-chdr                 |text/plain
          mime type|                            |

[Bug 26031]=?UTF-8?Q?=20=C2=B5Torrent=20loses=20the=20ability=20of=20listening=20to=20incoming=20connections?=

http://bugs.winehq.org/show_bug.cgi?id=26031

--- Comment #35 from Dan Kegel  2012-08-08 10:17:25 CDT ---
That's not minimal, because it involves wine.  You have to give them a ten-line
native C program.  Otherwise it's too hard to analyse.

[Bug 26031]=?UTF-8?Q?=20=C2=B5Torrent=20loses=20the=20ability=20of=20listening=20to=20incoming=20connections?=

http://bugs.winehq.org/show_bug.cgi?id=26031

--- Comment #36 from Bruno Jesus  2012-08-08 10:29:06 CDT ---
Artem, remove the example usage, force TCP and stop parsing argv values to
reduce the program size. Switch:

#define WIN32_LEAN_AND_MEAN
#include <winsock2.h>

To

#include <sys/ioctl.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <netinet/tcp.h>
#include <arpa/inet.h>
#include <sys/time.h>
#include <fcntl.h>

Change:
closecoket

To:
close

And remove WSAStartup. Then compile in linux gcc.

[Bug 26031]=?UTF-8?Q?=20=C2=B5Torrent=20loses=20the=20ability=20of=20listening=20to=20incoming=20connections?=

http://bugs.winehq.org/show_bug.cgi?id=26031

--- Comment #37 from Bruno Jesus  2013-07-28 13:57:19 CDT ---
Artem, I'm no longer able to reproduce this in kernel 3.9. Can you try again?

[Bug 26031]=?UTF-8?Q?=20=C2=B5Torrent=20loses=20the=20ability=20of=20listening=20to=20incoming=20connections?=

http://bugs.winehq.org/show_bug.cgi?id=26031

Artem S. Tashkinov  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |UPSTREAM

--- Comment #38 from Artem S. Tashkinov  2013-07-28 14:09:43 CDT ---
(In reply to comment #37)
> Artem, I'm no longer able to reproduce this in kernel 3.9. Can you try again?

$ uname -a
Linux localhost.localdomain 3.9.11-ic #5 SMP PREEMPT Mon Jul 22 23:57:23 YEKT
2013 i686 i686 i386 GNU/Linux

Open uTorrent 2.2.1 build 25302, start downloading any torrent, the incoming
connections icon should turn green.

Go to settings change anything, hit apply.

Immediately you'll see an error message (twice):

TCP port bind failed 0.0.0.0:1234: (10048) Error 10048
TCP port bind failed 0.0.0.0:1234: (10048) Error 10048

Incoming connections to that port cannot be established any longer.

No, it's not resolved.

Actually it's a bug in the Linux kernel, so I'm marking it "RESOLVED/UPSTREAM"
because there's nothing Wine developers can do about it.

[Bug 26031]=?UTF-8?Q?=20=C2=B5Torrent=20loses=20the=20ability=20of=20listening=20to=20incoming=20connections?=

http://bugs.winehq.org/show_bug.cgi?id=26031

--- Comment #39 from Bruno Jesus  2013-07-28 14:18:55 CDT ---
You're right, I tested without any downloading/seeding torrent. The problem is
still present.

[Bug 26031]=?UTF-8?Q?=20=C2=B5Torrent=20loses=20the=20ability=20of=20listening=20to=20incoming=20connections?=

http://bugs.winehq.org/show_bug.cgi?id=26031

Jerome Leclanche  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |CLOSED

--- Comment #40 from Jerome Leclanche  2013-07-28 14:34:19 CDT ---
The upstream bug has been closed as WONTFIX. So if nothing can be done on
Wine's side, we can close here too.

[Bug 26031]=?UTF-8?Q?=20=C2=B5Torrent=20loses=20the=20ability=20of=20listening=20to=20incoming=20connections?=

http://bugs.winehq.org/show_bug.cgi?id=26031

Jerome Leclanche  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

--- Comment #41 from Jerome Leclanche  2013-07-28 14:35:58 CDT ---
*** Bug 18714 has been marked as a duplicate of this bug. ***

[Bug 26031]=?UTF-8?Q?=20=C2=B5Torrent=20loses=20the=20ability=20of=20listening=20to=20incoming=20connections?=

http://bugs.winehq.org/show_bug.cgi?id=26031

Bruno Jesus  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|CLOSED                      |RESOLVED

--- Comment #42 from Bruno Jesus  2013-07-28 14:51:21 CDT ---
Like bug 20907 I don't think we should close it yet because the other side
closed it. I'm still looking for workarounds and digging the kernel code in
search for solutions. Currently I have tested the SO_REUSEPORT option (added in
kernel 3.9) but it does not help.

[Bug 26031]=?UTF-8?Q?=20=C2=B5Torrent=20loses=20the=20ability=20of=20listening=20to=20incoming=20connections?=

http://bugs.winehq.org/show_bug.cgi?id=26031

--- Comment #43 from Jerome Leclanche  2013-07-28 14:52:24 CDT ---
(In reply to comment #42)
If it can be fixed in Wine it's worth keeping fully open then ;) But I'll leave
it like this, it's fine.

[Bug 26031]=?UTF-8?Q?=20=C2=B5Torrent=20loses=20the=20ability=20of=20listening=20to=20incoming=20connections?=

http://bugs.winehq.org/show_bug.cgi?id=26031

--- Comment #44 from Artem S. Tashkinov  2013-07-28 15:15:19 CDT ---
(In reply to comment #40)
> The upstream bug has been closed as WONTFIX. So if nothing can be done on
> Wine's side, we can close here too.

I've taken the liberty of reopening the upstream bug report.

This behavior is absolutely counter intuitive and defies common sense.

[Bug 26031]=?UTF-8?Q?=20=C2=B5Torrent=20loses=20the=20ability=20of=20listening=20to=20incoming=20connections?=

http://bugs.winehq.org/show_bug.cgi?id=26031

--- Comment #45 from Artem S. Tashkinov  2013-07-28 15:20:09 CDT ---
One last thing,

can anyone please try MacOS X and check if SOCKET reuse is allowed by the mach
kernel (using Wine/uTorrent or a little program available as an attachment to
this bug report).

If it's allowed, I'm gonna press Linux kernel developers real hard.

P.S. BTW, the upstream bug report can be duplicated against AOSP - maybe
Android developers will be more tractable and they will at least implement a
solution for this bug as a patch.

[Bug 26031]=?UTF-8?Q?=20=C2=B5Torrent=20loses=20the=20ability=20of=20listening=20to=20incoming=20connections?=

http://bugs.winehq.org/show_bug.cgi?id=26031

--- Comment #46 from Artem S. Tashkinov  2013-07-29 22:58:04 CDT ---
Created attachment 45451
  --> http://bugs.winehq.org/attachment.cgi?id=45451
strace -fF -e socket,setsockopt,bind

(In reply to comment #37)
> Artem, I'm no longer able to reproduce this in kernel 3.9. Can you try again?

Kernel developers insist SO_REUSEADDR works:

https://lkml.org/lkml/2013/7/29/530

Actually I've just strace'd wine, and it seems like SO_REUSEADDR appears very
late in the log.

[Bug 26031]=?UTF-8?Q?=20=C2=B5Torrent=20loses=20the=20ability=20of=20listening=20to=20incoming=20connections?=

http://bugs.winehq.org/show_bug.cgi?id=26031

--- Comment #47 from Bruno Jesus  2013-07-29 23:08:50 CDT ---
(In reply to comment #46)
> Kernel developers insist SO_REUSEADDR works:
>
> https://lkml.org/lkml/2013/7/29/530
>
> Actually I've just strace'd wine, and it seems like SO_REUSEADDR appears very
> late in the log.

I don't have any doubt that SO_REUSEADDR works =)
Maybe the only solution is to force SO_REUSEADDR in every socket created inside
wine. I'm working on replicating the exact steps from uTorrent to have a better
testcase.

[Bug 26031]=?UTF-8?Q?=20=C2=B5Torrent=20loses=20the=20ability=20of=20listening=20to=20incoming=20connections?=

http://bugs.winehq.org/show_bug.cgi?id=26031

--- Comment #48 from Artem S. Tashkinov  2013-07-29 23:27:22 CDT ---
(In reply to comment #47)
> (In reply to comment #46)
> > Kernel developers insist SO_REUSEADDR works:
> >
> > https://lkml.org/lkml/2013/7/29/530
> >
> > Actually I've just strace'd wine, and it seems like SO_REUSEADDR appears very
> > late in the log.
>
> I don't have any doubt that SO_REUSEADDR works =)
> Maybe the only solution is to force SO_REUSEADDR in every socket created inside
> wine. I'm working on replicating the exact steps from uTorrent to have a better
> testcase.

Gotta agree with:
> Maybe the only solution is to force SO_REUSEADDR in every socket created inside
> wine.

I see zero problems using this flag for all bind()'s - it cannot hurt.

[Bug 26031]=?UTF-8?Q?=20=C2=B5Torrent=20loses=20the=20ability=20of=20listening=20to=20incoming=20connections?=

http://bugs.winehq.org/show_bug.cgi?id=26031

--- Comment #49 from Hans Leidekker  2013-07-30 02:12:06 CDT ---
(In reply to comment #48)
...
> > Maybe the only solution is to force SO_REUSEADDR in every socket created inside
> > wine.
>
> I see zero problems using this flag for all bind()'s - it cannot hurt.

It can hurt because it changes behavior visible to applications. It's also
opening up a security hole.

[Bug 26031]=?UTF-8?Q?=20=C2=B5Torrent=20loses=20the=20ability=20of=20listening=20to=20incoming=20connections?=

http://bugs.winehq.org/show_bug.cgi?id=26031

Jerome Leclanche  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |CLOSED

--- Comment #50 from Jerome Leclanche  2013-08-24 21:14:45 CDT ---
This is confirmed as a wontfix upstream.

There is an interesting stackoverflow answer that explains some of the socket
situation:
http://stackoverflow.com/questions/14388706/socket-options-so-reuseaddr-and-...

[Bug 26031]=?UTF-8?Q?=20=C2=B5Torrent=20loses=20the=20ability=20of=20listening=20to=20incoming=20connections?=

http://bugs.winehq.org/show_bug.cgi?id=26031

--- Comment #51 from Jerome Leclanche  2013-08-24 21:16:01 CDT ---
Also, is bug 5774 the same as this one? Oddly it that one looks fixed.

[Bug 26031]=?UTF-8?Q?=20=C2=B5Torrent=20loses=20the=20ability=20of=20listening=20to=20incoming=20connections?=

http://bugs.winehq.org/show_bug.cgi?id=26031

Artem S. Tashkinov  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|CLOSED                      |REOPENED
         Resolution|UPSTREAM                    |

--- Comment #52 from Artem S. Tashkinov  2013-08-25 01:52:42 CDT ---
(In reply to comment #50)
> This is confirmed as a wontfix upstream.
>
> There is an interesting stackoverflow answer that explains some of the socket
> situation:
> http://stackoverflow.com/questions/14388706/socket-options-so-reuseaddr-and-...

UPSTREAM said we should use SO_REUSEADDR at all times and there will be no bug.

Right now SO_REUSEADDR is used only on special occasions.

Sorry, I'm reopening this bug.

[Bug 26031]=?UTF-8?Q?=20=C2=B5Torrent=20loses=20the=20ability=20of=20listening=20to=20incoming=20connections?=

http://bugs.winehq.org/show_bug.cgi?id=26031

--- Comment #53 from Dan Kegel  2013-08-25 11:45:36 CDT ---
Was this fixed on mac by
http://source.winehq.org/git/wine.git/?a=commit;h=197041f1ffe4841b0514701fd2... 
which sets SO_REUSEPORT on Mac if SO_REUSEADDR was specified?

If so, https://lwn.net/Articles/542629/ says this option is available on Linux
as of kernel 3.9, and switching the #ifdef __APPLE__
to #ifdef HAVE_SO_REUSEADDR might make sense.

[Bug 26031]=?UTF-8?Q?=20=C2=B5Torrent=20loses=20the=20ability=20of=20listening=20to=20incoming=20connections?=

http://bugs.winehq.org/show_bug.cgi?id=26031

--- Comment #54 from Dan Kegel  2013-08-25 11:48:57 CDT ---
Ahem.  I meant #ifdef HAVE_SO_REUSEPORT.

[Bug 26031]=?UTF-8?Q?=20=C2=B5Torrent=20loses=20the=20ability=20of=20listening=20to=20incoming=20connections?=

http://bugs.winehq.org/show_bug.cgi?id=26031

--- Comment #55 from Bruno Jesus  2013-08-25 18:53:04 CDT ---
(In reply to comment #53)
No, uTorrent does not set SO_REUSEADDR by default. We were speculating about
forcing that option on every socket that is created. The problem is that
windows ignores TIME_WAIT and allows any program to bind to the port, while in
linux the timings are strictly followed.

[Bug 26031]=?UTF-8?Q?=20=C2=B5Torrent=20loses=20the=20ability=20of=20listening=20to=20incoming=20connections?=

http://bugs.winehq.org/show_bug.cgi?id=26031

--- Comment #56 from Artem S. Tashkinov  2013-08-26 00:16:11 CDT ---
(In reply to comment #55)
> (In reply to comment #53)
> No, uTorrent does not set SO_REUSEADDR by default. We were speculating about
> forcing that option on every socket that is created. The problem is that
> windows ignores TIME_WAIT and allows any program to bind to the port, while in
> linux the timings are strictly followed.

I still don't see any security implications in enabling SO_REUSEADDR by
default.

Windows has always allowed that and I don't see a single security problem
arising due to this feature. What's so different about Linux? I've no idea at
all.

[Bug 26031]=?UTF-8?Q?=20=C2=B5Torrent=20loses=20the=20ability=20of=20listening=20to=20incoming=20connections?=

http://bugs.winehq.org/show_bug.cgi?id=26031

--- Comment #57 from Hans Leidekker  2013-08-27 03:02:29 CDT ---
(In reply to comment #56)
> (In reply to comment #55)
> > (In reply to comment #53)
> > No, uTorrent does not set SO_REUSEADDR by default. We were speculating about
> > forcing that option on every socket that is created. The problem is that
> > windows ignores TIME_WAIT and allows any program to bind to the port, while in
> > linux the timings are strictly followed.
>
> I still don't see any security implications in enabling SO_REUSEADDR by
> default.

Enabling SO_REUSEADDR by default means you'd allow another socket to bind even
when Windows doesn't.

[Bug 26031]=?UTF-8?Q?=20=C2=B5Torrent=20loses=20the=20ability=20of=20listening=20to=20incoming=20connections?=

http://bugs.winehq.org/show_bug.cgi?id=26031

--- Comment #58 from Artem S. Tashkinov  2013-08-27 03:33:10 CDT ---
(In reply to comment #57)
> Enabling SO_REUSEADDR by default means you'd allow another socket to bind even
> when Windows doesn't.

Can you please find a piece of documentation which proves your words? Because I
don't have this information and I believe you are not correct.

[Bug 26031]=?UTF-8?Q?=20=C2=B5Torrent=20loses=20the=20ability=20of=20listening=20to=20incoming=20connections?=

http://bugs.winehq.org/show_bug.cgi?id=26031

--- Comment #59 from Hans Leidekker  2013-08-27 03:40:54 CDT ---
(In reply to comment #58)
> (In reply to comment #57)
> > Enabling SO_REUSEADDR by default means you'd allow another socket to bind even
> > when Windows doesn't.
>
> Can you please find a piece of documentation which proves your words? Because I
> don't have this information and I believe you are not correct.

http://msdn.microsoft.com/en-us/library/windows/desktop/ms740621%28v=vs.85%2...

The second bind call is supposed to fail with an INUSE error when no options
are set on either socket.

[Bug 26031]=?UTF-8?Q?=20=C2=B5Torrent=20loses=20the=20ability=20of=20listening=20to=20incoming=20connections?=

http://bugs.winehq.org/show_bug.cgi?id=26031

--- Comment #60 from Artem S. Tashkinov  2013-08-27 03:57:47 CDT ---
(In reply to comment #59)
> (In reply to comment #58)
> > (In reply to comment #57)
> > > Enabling SO_REUSEADDR by default means you'd allow another socket to bind even
> > > when Windows doesn't.
> >
> > Can you please find a piece of documentation which proves your words? Because I
> > don't have this information and I believe you are not correct.
>
> http://msdn.microsoft.com/en-us/library/windows/desktop/ms740621%28v=vs.85%2...
>
> The second bind call is supposed to fail with an INUSE error when no options
> are set on either socket.

We can argue forever about the feasibility and validity of using SO_REUSEADDR
by default, the fact is here's a Windows application which works under Windows
and breaks under Linux.

Besides last time I checked, Wine is meant to emulate Windows behaviour as much
as possible - and since the Linux kernel allows sockets reuse, Wine must allow
it too for Windows applications.

[Bug 26031]=?UTF-8?Q?=20=C2=B5Torrent=20loses=20the=20ability=20of=20listening=20to=20incoming=20connections?=

http://bugs.winehq.org/show_bug.cgi?id=26031

--- Comment #61 from Hans Leidekker  2013-08-27 04:04:00 CDT ---
(In reply to comment #60)
> We can argue forever about the feasibility and validity of using SO_REUSEADDR
> by default, the fact is here's a Windows application which works under Windows
> and breaks under Linux.
>
> Besides last time I checked, Wine is meant to emulate Windows behaviour as much
> as possible - and since the Linux kernel allows sockets reuse, Wine must allow
> it too for Windows applications.

Sure, but we can't fix one set of applications and break another set at the
same time.

[Bug 26031]=?UTF-8?Q?=20=C2=B5Torrent=20loses=20the=20ability=20of=20listening=20to=20incoming=20connections?=

http://bugs.winehq.org/show_bug.cgi?id=26031

--- Comment #62 from Artem S. Tashkinov  2013-08-27 05:26:35 CDT ---
(In reply to comment #61)
> Sure, but we can't fix one set of applications and break another set at the
> same time.

I don't know a single application which breaks when using this flag by default,
do you?

[Bug 26031]=?UTF-8?Q?=20=C2=B5Torrent=20loses=20the=20ability=20of=20listening=20to=20incoming=20connections?=

http://bugs.winehq.org/show_bug.cgi?id=26031

--- Comment #63 from Hans Leidekker  2013-08-27 05:48:58 CDT ---
(In reply to comment #62)
> (In reply to comment #61)
> > Sure, but we can't fix one set of applications and break another set at the
> > same time.
>
> I don't know a single application which breaks when using this flag by default,
> do you?

No, but it's easy to imagine that it will break some applications. For example,
an app that wants to find an unused port may run a loop increasing the port
number and rely on getting an error from bind, so it can try the next port.

[Bug 26031]=?UTF-8?Q?=20=C2=B5Torrent=20loses=20the=20ability=20of=20listening=20to=20incoming=20connections?=

http://bugs.winehq.org/show_bug.cgi?id=26031

--- Comment #64 from Artem S. Tashkinov  2013-08-27 06:00:03 CDT ---
(In reply to comment #63)
> (In reply to comment #62)
> > (In reply to comment #61)
> > > Sure, but we can't fix one set of applications and break another set at the
> > > same time.
> >
> > I don't know a single application which breaks when using this flag by default,
> > do you?
>
> No, but it's easy to imagine that it will break some applications. For example,
> an app that wants to find an unused port may run a loop increasing the port
> number and rely on getting an error from bind, so it can try the next port.

So instead of fixing _real_ applications you're talking about some _imaginary_
applications (with some very odd behavior) which _might_ break should we make
this change?

I've always thought real applications are of utmost concern for Wine
development.

[Bug 26031]=?UTF-8?Q?=20=C2=B5Torrent=20loses=20the=20ability=20of=20listening=20to=20incoming=20connections?=

http://bugs.winehq.org/show_bug.cgi?id=26031

--- Comment #65 from Dan Kegel  2013-08-27 06:36:10 CDT ---
Now, now.

Perhaps this could be special-cased for uTorrent someday if
apphelp is implemented; see
http://www.winehq.org/pipermail/wine-devel/2013-August/100773.html

(See also http://blogs.msdn.com/b/oldnewthing/archive/2003/12/24/45779.aspx
Related terms - apphelp, application compatibility toolkit, apppatch,
appcompat.)

Heck, I wonder if Microsoft special-cases this app.

[Bug 26031]=?UTF-8?Q?=20=C2=B5Torrent=20loses=20the=20ability=20of=20listening=20to=20incoming=20connections?=

http://bugs.winehq.org/show_bug.cgi?id=26031

Bruno Jesus  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #37438|0                           |1
        is obsolete|                            |

--- Comment #66 from Bruno Jesus  ---
Created attachment 47020
  --> http://bugs.winehq.org/attachment.cgi?id=47020
Always use SO_REUSEADDR

After re-reading this bug, the kernel bug and the discussions in kernel netdev
list started by Artem I created the simple attached patch that "solves" this
issue.

SO_REUSEADDR on linux at least will not allow the same program to bind twice in
the same port.

Keeping SO_REUSEADDR after the socket is closed is the key to allow the next
process to bind to the same address.

[Bug 26031]=?UTF-8?Q?=20=C2=B5Torrent=20loses=20the=20ability=20of=20listening=20to=20incoming=20connections?=

http://bugs.winehq.org/show_bug.cgi?id=26031

--- Comment #67 from Artem S. Tashkinov  ---
(In reply to comment #66)
> Created attachment 47020 [details]
> Always use SO_REUSEADDR
>
> After re-reading this bug, the kernel bug and the discussions in kernel
> netdev list started by Artem I created the simple attached patch that
> "solves" this issue.
>
> SO_REUSEADDR on linux at least will not allow the same program to bind twice
> in the same port.
>
> Keeping SO_REUSEADDR after the socket is closed is the key to allow the next
> process to bind to the same address.

Thanks a lot!

[Bug 26031] µTorrent loses the ability of listening to incoming connections

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=26031

David Seward  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

--- Comment #68 from David Seward  ---
Running Wine 4.20 on Kernel 5.3.0-23 AND a copy of uTorrent 2.2.1, I am kind of
able to confirm this bug in the sense that I am able to change the download
settings and get the "Listen Error" text.

However, even though uTorrent complains, the torrent will still download and
the port will still be set to LISTEN. I'm not sure if that means this can be
closed, or if we want to keep it open since it's still showing the error.

[Bug 26031] µTorrent loses the ability of listening to incoming connections

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=26031

James  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
         Depends on|                            |50499