[Bug 26031] New: µTorrent (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: wine-bugs(a)winehq.org ReportedBy: t.artem(a)mailcity.com 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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=26031 Juan Lang <juan_lang(a)yahoo.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Component|wineserver |-unknown --- Comment #1 from Juan Lang <juan_lang(a)yahoo.com> 2011-02-08 16:10:11 CST --- Please don't guess the component. wineserver doesn't do much with sockets, actually. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=26031 --- Comment #2 from Artem S. Tashkinov <t.artem(a)mailcity.com> 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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=26031 Austin English <austinenglish(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=26031 --- Comment #3 from Artem S. Tashkinov <t.artem(a)mailcity.com> 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). -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=26031 --- Comment #4 from Artem S. Tashkinov <t.artem(a)mailcity.com> 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 -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=26031 Artem S. Tashkinov <t.artem(a)mailcity.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |18714 -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=26031 Dan Kegel <dank(a)kegel.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dank(a)kegel.com --- Comment #5 from Dan Kegel <dank(a)kegel.com> 2011-02-08 21:39:12 CST --- Does raising ulimit per http://wiki.winehq.org/FAQ#head-80aeef30021fc0bae9ba2254f9ce6e249577ea93 help? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=26031 Dmitry Timoshkov <dmitry(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Platform|All |Other -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=26031 --- Comment #6 from Artem S. Tashkinov <t.artem(a)mailcity.com> 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 -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=26031 Artem S. Tashkinov <t.artem(a)mailcity.com> 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 <t.artem(a)mailcity.com> 2011-04-30 05:23:31 CDT --- µTorrent 2.2.1 is not affected, so I'm lowering this bug importance. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=26031 --- Comment #8 from Artem S. Tashkinov <t.artem(a)mailcity.com> 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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=26031 Bruno Jesus <00cpxxx(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |00cpxxx(a)gmail.com --- Comment #9 from Bruno Jesus <00cpxxx(a)gmail.com> 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? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=26031 --- Comment #10 from Artem S. Tashkinov <t.artem(a)mailcity.com> 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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=26031 Bruno Jesus <00cpxxx(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 --- Comment #11 from Bruno Jesus <00cpxxx(a)gmail.com> 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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=26031 Artem S. Tashkinov <t.artem(a)mailcity.com> 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 | -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=26031 --- Comment #12 from Artem S. Tashkinov <t.artem(a)mailcity.com> 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 -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=26031 --- Comment #13 from Bruno Jesus <00cpxxx(a)gmail.com> 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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=26031 --- Comment #14 from Bruno Jesus <00cpxxx(a)gmail.com> 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? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=26031 --- Comment #15 from Artem S. Tashkinov <t.artem(a)mailcity.com> 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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=26031 Jerome Leclanche <adys.wh(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |adys.wh(a)gmail.com --- Comment #16 from Jerome Leclanche <adys.wh(a)gmail.com> 2011-10-28 18:02:01 CDT --- (In reply to comment #14) Does that mean this bug is invalid? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=26031 --- Comment #17 from Dan Kegel <dank(a)kegel.com> 2011-10-28 18:14:47 CDT --- The original problem doesn't sound like something that happens in windows, so probably not invalid? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=26031 --- Comment #18 from Juan Lang <juan.lang(a)gmail.com> 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.) -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=26031 --- Comment #19 from Artem S. Tashkinov <t.artem(a)mailcity.com> 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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=26031 --- Comment #20 from Bruno Jesus <00cpxxx(a)gmail.com> 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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=26031 --- Comment #21 from Bruno Jesus <00cpxxx(a)gmail.com> 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 -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=26031 --- Comment #22 from Bruno Jesus <00cpxxx(a)gmail.com> 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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=26031 --- Comment #23 from Artem S. Tashkinov <t.artem(a)mailcity.com> 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 -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=26031 --- Comment #24 from Bruno Jesus <00cpxxx(a)gmail.com> 2012-01-01 14:04:18 CST --- I'm still testing in other systems and mostly convinced it's a kernel bug. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=26031 --- Comment #25 from Bruno Jesus <00cpxxx(a)gmail.com> 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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=26031 --- Comment #26 from Bruno Jesus <00cpxxx(a)gmail.com> 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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=26031 Artem S. Tashkinov <t.artem(a)mailcity.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugzilla.kernel.org | |/show_bug.cgi?id=45571 -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=26031 --- Comment #27 from Dan Kegel <dank(a)kegel.com> 2012-08-04 10:13:41 CDT --- Bruno, can you write a small Linux C program that automatically reproduces the problem? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=26031 --- Comment #28 from Bruno Jesus <00cpxxx(a)gmail.com> 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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=26031 --- Comment #29 from Artem S. Tashkinov <t.artem(a)mailcity.com> 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 netdev(a)vger.kernel.org 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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=26031 --- Comment #30 from Dan Kegel <dank(a)kegel.com> 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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=26031 --- Comment #31 from Bruno Jesus <00cpxxx(a)gmail.com> 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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=26031 --- Comment #32 from Artem S. Tashkinov <t.artem(a)mailcity.com> 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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=26031 --- Comment #33 from Dan Kegel <dank(a)kegel.com> 2012-08-08 09:28:40 CDT --- You can't accuse them of anything until you have a minimal test case. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=26031 --- Comment #34 from Artem S. Tashkinov <t.artem(a)mailcity.com> 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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=26031 Artem S. Tashkinov <t.artem(a)mailcity.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #41316|text/x-chdr |text/plain mime type| | -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=26031 --- Comment #35 from Dan Kegel <dank(a)kegel.com> 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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=26031 --- Comment #36 from Bruno Jesus <00cpxxx(a)gmail.com> 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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=26031 --- Comment #37 from Bruno Jesus <00cpxxx(a)gmail.com> 2013-07-28 13:57:19 CDT --- Artem, I'm no longer able to reproduce this in kernel 3.9. Can you try again? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=26031 Artem S. Tashkinov <t.artem(a)mailcity.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |UPSTREAM --- Comment #38 from Artem S. Tashkinov <t.artem(a)mailcity.com> 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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=26031 --- Comment #39 from Bruno Jesus <00cpxxx(a)gmail.com> 2013-07-28 14:18:55 CDT --- You're right, I tested without any downloading/seeding torrent. The problem is still present. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=26031 Jerome Leclanche <adys.wh(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #40 from Jerome Leclanche <adys.wh(a)gmail.com> 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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=26031 Jerome Leclanche <adys.wh(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |gmdime(a)gmail.com --- Comment #41 from Jerome Leclanche <adys.wh(a)gmail.com> 2013-07-28 14:35:58 CDT --- *** Bug 18714 has been marked as a duplicate of this bug. *** -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=26031 Bruno Jesus <00cpxxx(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|CLOSED |RESOLVED --- Comment #42 from Bruno Jesus <00cpxxx(a)gmail.com> 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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=26031 --- Comment #43 from Jerome Leclanche <adys.wh(a)gmail.com> 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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=26031 --- Comment #44 from Artem S. Tashkinov <t.artem(a)mailcity.com> 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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=26031 --- Comment #45 from Artem S. Tashkinov <t.artem(a)mailcity.com> 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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=26031 --- Comment #46 from Artem S. Tashkinov <t.artem(a)mailcity.com> 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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=26031 --- Comment #47 from Bruno Jesus <00cpxxx(a)gmail.com> 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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=26031 --- Comment #48 from Artem S. Tashkinov <t.artem(a)mailcity.com> 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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=26031 --- Comment #49 from Hans Leidekker <hans(a)meelstraat.net> 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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=26031 Jerome Leclanche <adys.wh(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #50 from Jerome Leclanche <adys.wh(a)gmail.com> 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-... -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=26031 --- Comment #51 from Jerome Leclanche <adys.wh(a)gmail.com> 2013-08-24 21:16:01 CDT --- Also, is bug 5774 the same as this one? Oddly it that one looks fixed. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=26031 Artem S. Tashkinov <t.artem(a)mailcity.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|CLOSED |REOPENED Resolution|UPSTREAM | --- Comment #52 from Artem S. Tashkinov <t.artem(a)mailcity.com> 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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=26031 --- Comment #53 from Dan Kegel <dank(a)kegel.com> 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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=26031 --- Comment #54 from Dan Kegel <dank(a)kegel.com> 2013-08-25 11:48:57 CDT --- Ahem. I meant #ifdef HAVE_SO_REUSEPORT. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=26031 --- Comment #55 from Bruno Jesus <00cpxxx(a)gmail.com> 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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=26031 --- Comment #56 from Artem S. Tashkinov <t.artem(a)mailcity.com> 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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=26031 --- Comment #57 from Hans Leidekker <hans(a)meelstraat.net> 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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=26031 --- Comment #58 from Artem S. Tashkinov <t.artem(a)mailcity.com> 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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=26031 --- Comment #59 from Hans Leidekker <hans(a)meelstraat.net> 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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=26031 --- Comment #60 from Artem S. Tashkinov <t.artem(a)mailcity.com> 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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=26031 --- Comment #61 from Hans Leidekker <hans(a)meelstraat.net> 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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=26031 --- Comment #62 from Artem S. Tashkinov <t.artem(a)mailcity.com> 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? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=26031 --- Comment #63 from Hans Leidekker <hans(a)meelstraat.net> 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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=26031 --- Comment #64 from Artem S. Tashkinov <t.artem(a)mailcity.com> 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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=26031 --- Comment #65 from Dan Kegel <dank(a)kegel.com> 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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=26031 Bruno Jesus <00cpxxx(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #37438|0 |1 is obsolete| | --- Comment #66 from Bruno Jesus <00cpxxx(a)gmail.com> --- 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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=26031 --- Comment #67 from Artem S. Tashkinov <t.artem(a)mailcity.com> --- (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! -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=26031 David Seward <bignintyfan(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bignintyfan(a)gmail.com --- Comment #68 from David Seward <bignintyfan(a)gmail.com> --- 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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=26031 James <James(a)superbug.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Depends on| |50499 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (2)
-
wine-bugs＠winehq.org -
WineHQ Bugzilla