http://bugs.winehq.org/show_bug.cgi?id=21387
Summary: NetTerm locks up Product: Wine Version: unspecified Platform: x86 URL: http://www.securenetterm.com/pub/nt325405.exe OS/Version: Linux Status: UNCONFIRMED Keywords: download Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs@winehq.org ReportedBy: nerv@dawncrow.de CC: support@securenetterm.com
This is a Bug discussed in Bug 11621 but not belonging there. Summary:
As the author of NetTerm, SecureNetTerm, SNetTerm and SecureFTP, I am seeing the same problem with NetTerm that I see with Putty as it relates to the telnet connection problem.
Our SNetTerm product, as well as the Microsoft telnet.exe DOES NOT have this issue.
Is there been any additional information on this issue that would help us get this resolved? Where to look? Anytime we can test in the winsock area to help resolve the issue?
I am not sure that this is all that is going on. Our NetTerm product DOES NOT send a SIOCATMARK, yet the behavior is much like Putty's. That is, it connects to the host ok, then about 2-3 seconds after the connect, it freezes.
Note that it IS NOT a the same place everytime. That is, if I run NetTerm without a script, I cannot type fast enough to enter my userid at the Login: prompt before the application locks up. However if I use a script, it logs in and gets to the command line then locks up.
It appears that some type of timer is involved.
The really strange thing is our SNetTerm product is not affected by the bug at all. It does a telnet connect and everything works ok. The same is true for the Microsoft telnet.exe program.
The current version of NetTerm can be downloaded from:
http://www.securenetterm.com/pub/nt325405.exe
and includes a 60 day trial period. If more time is needed, or has been downloaded before and trial period has expired, contact me at support@securenetterm.com and I will send a new key.
I found the problem. It is in the telnet tcpip network code, sort of like the Putty problem. NetTerm locks up when it issues a winsock recv()call for 1 byte with MSG_PEEK in the flags field.
http://bugs.winehq.org/show_bug.cgi?id=21387
--- Comment #1 from André H. nerv@dawncrow.de 2010-01-16 05:30:52 --- @Kenneth Robinette: I tried it with wine 1.1.36 and can not confirm your problem, but if you have problems, please specify wine-version, cpu-type and if it came from winsock or ws2_32. Of course we use this Bug for further handlings of your problem and not the putty bug. Also please dont fix the Problem in your Application, but in Wine.
http://bugs.winehq.org/show_bug.cgi?id=21387
--- Comment #2 from Kenneth Robinette support@securenetterm.com 2010-01-16 07:48:10 --- (In reply to comment #1)
@Kenneth Robinette: I tried it with wine 1.1.36 and can not confirm your problem, but if you have problems, please specify wine-version, cpu-type and if it came from winsock or ws2_32. Of course we use this Bug for further handlings of your problem and not the putty bug. Also please dont fix the Problem in your Application, but in Wine.
Problem resolved, please close this report.
http://bugs.winehq.org/show_bug.cgi?id=21387
--- Comment #3 from André H. nerv@dawncrow.de 2010-01-16 07:51:13 --- one moment, resolved in your app or by a workaround?
http://bugs.winehq.org/show_bug.cgi?id=21387
André H. nerv@dawncrow.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |INVALID
--- Comment #4 from André H. nerv@dawncrow.de 2010-01-18 08:01:54 --- resolved in their app:
We were using a winsock recv() with a flag of MSG_PEEK in an attempt to detect if the host closed the connection. After doing a Google search, we discovered that this can cause problems with some of the older winsock based tcpip stacks.
http://bugs.winehq.org/show_bug.cgi?id=21387
Dmitry Timoshkov dmitry@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |UNCONFIRMED Resolution|INVALID |
--- Comment #5 from Dmitry Timoshkov dmitry@codeweavers.com 2010-01-18 11:36:29 --- Since this works under Windows this is a valid Wine bug. What Wine version was used for testing?
http://bugs.winehq.org/show_bug.cgi?id=21387
--- Comment #6 from Kenneth Robinette support@securenetterm.com 2010-01-18 11:59:55 --- (In reply to comment #5)
Since this works under Windows this is a valid Wine bug. What Wine version was used for testing?
1.0.1-1
http://bugs.winehq.org/show_bug.cgi?id=21387
Dmitry Timoshkov dmitry@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|unspecified |1.0.1
--- Comment #7 from Dmitry Timoshkov dmitry@codeweavers.com 2010-01-18 22:36:32 --- Testing with 1.0.1 is not useful. Does the bug exist in 1.1.36?
http://bugs.winehq.org/show_bug.cgi?id=21387
--- Comment #8 from Kenneth Robinette support@securenetterm.com 2010-01-19 06:07:30 --- (In reply to comment #7)
Testing with 1.0.1 is not useful. Does the bug exist in 1.1.36?
Yes.
http://bugs.winehq.org/show_bug.cgi?id=21387
--- Comment #9 from Kenneth Robinette support@securenetterm.com 2010-02-09 10:36:29 --- (In reply to comment #8)
(In reply to comment #7)
Testing with 1.0.1 is not useful. Does the bug exist in 1.1.36?
Yes.
The bug is in all versions of wine. There also appears to be a problem when doing the initial network connect. The select() function is returning a 1 to indicate a connection was established, when in fact it has not. This is simple to confirm by trying to connect to a server that is powered down.
It appears the wine network logic does not do any error checking at all!
http://bugs.winehq.org/show_bug.cgi?id=21387
Bruno Jesus 00cpxxx@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |00cpxxx@gmail.com
--- Comment #10 from Bruno Jesus 00cpxxx@gmail.com 2011-08-02 23:45:56 CDT --- Select indeed returns 1 because poll() returns 1, the main problem is that poll returned an error event for the descriptor but Wine didn't check it. As the FD is being checked for write Wine tests only for POLLOUT. This is a piece of the log generated by strace:
... poll([{fd=21, events=POLLOUT}], 1, 100) = 0 (Timeout) poll([{fd=21, events=POLLOUT}], 1, 100) = 0 (Timeout) poll([{fd=21, events=POLLOUT}], 1, 100) = 0 (Timeout) poll([{fd=21, events=POLLOUT}], 1, 100) = 1 ([{fd=21, revents=POLLOUT|POLLERR|POLLHUP}]) ...
On socket.c, on function get_poll_results the revents variable is not checked properly for read and write fds. The attached patch fix this but although it's simple it contains critical changes. Netterm is not giving false connections anymore, I also tested utorrent because it does thousands of socket operations and it still runs fine after the patch.
The make test for the sockets says there are 2 failures, both of them are success inside todo blocks, I'm not sure what that means but I guess they are not real errors.
sock.c:4979: **** TEST 4 COMPLETE **** sock.c:2314: Test succeeded inside todo block: expected 0 (timeout), got: 0 sock.c:2353: Test marked todo: select should not return any socket handles sock.c:2354: Test marked todo: FD should not be set sock.c:2355: Test succeeded inside todo block: FD should not be set
The tests create sockets and pass them to select without binding, this makes poll returns POLLHUP for every socket. But POLLHUP is also a message telling us that a socket is being disconnected (if TCP connection was previously established), so in order to fix the errors from lines 2353 and 2354 Wine would need to check if the socket was connected; and if it was treat POLLHUP as a successful reading. Read remarks from http://msdn.microsoft.com/en-us/library/ms740141%28v=vs.85%29.aspx for a much better explanation.
http://bugs.winehq.org/show_bug.cgi?id=21387
--- Comment #11 from Bruno Jesus 00cpxxx@gmail.com 2011-08-02 23:52:15 CDT --- Created an attachment (id=35792) --> (http://bugs.winehq.org/attachment.cgi?id=35792) Try to fix false-positive select() returns
http://bugs.winehq.org/show_bug.cgi?id=21387
Dan Kegel dank@kegel.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch Status|UNCONFIRMED |NEW CC| |dank@kegel.com Ever Confirmed|0 |1
--- Comment #12 from Dan Kegel dank@kegel.com 2011-08-03 12:03:33 CDT --- It sounds like we need a conformance test which does a winsock recv() for 1 byte with MSG_PEEK in the flags field. Can you add one?
(For what it's worth, here are two possibly related pages:
http://www.greenend.org.uk/rjk/2001/06/poll.html reminds us that we have to test on multiple unixes before changing code that relates to poll, as they return different results from poll under the same conditions.
http://lists.danga.com/pipermail/memcached/2003-October/000336.html suggests that the Linux kernel translates POLLERR into "both readable and writable", and POLLHUP into "readable", in its select().)
http://bugs.winehq.org/show_bug.cgi?id=21387
--- Comment #13 from André H. nerv@dawncrow.de 2011-08-03 12:29:35 CDT --- (In reply to comment #10)
The make test for the sockets says there are 2 failures, both of them are success inside todo blocks, I'm not sure what that means but I guess they are not real errors.
sock.c:4979: **** TEST 4 COMPLETE **** sock.c:2314: Test succeeded inside todo block: expected 0 (timeout), got: 0 sock.c:2353: Test marked todo: select should not return any socket handles sock.c:2354: Test marked todo: FD should not be set sock.c:2355: Test succeeded inside todo block: FD should not be set
you already did a good job and the test proves that. tests marked with todo_wine makes our test not fail when a check failed on wine, so that we happily can test it on windows without being annoyed when testing in wine. that means your patch should also remove the todo_wine flags in these two lines. further your patch should be in git format, see http://wiki.winehq.org/SubmittingPatches
i didn't looked closer, so i bet you also should follow Dan's hints.
http://bugs.winehq.org/show_bug.cgi?id=21387
--- Comment #14 from Bruno Jesus 00cpxxx@gmail.com 2011-08-03 12:38:38 CDT --- The first link conclusion is that we should check for both POLLIN and POLLHUP on reading, this my patch does =) After reading both links my conclusion is that I should remove the !POLLERR from both read/write making something like this:
for (i = k = 0; i < readfds->fd_count; i++, j++) - if (fds[j].revents) + if ((fds[j].revents&(POLLIN|POLLHUP)))
for (i = k = 0; i < writefds->fd_count; i++, j++) - if (fds[j].revents) + if ((fds[j].revents&POLLOUT) && !(fds[j].revents&POLLHUP))
It's still necessary to test !POLLHUP on write because otherwise it would return an FD in error state (false-positive connection).
I'm reading more about conformance tests but AFAIK I read something about that MSG_PEEK test already implemented (or in process of being commited) in current git.
Sorry about the patch format, I'm still starting on all this git stuff.
http://bugs.winehq.org/show_bug.cgi?id=21387
Bruno Jesus 00cpxxx@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #35792|0 |1 is obsolete| |
--- Comment #15 from Bruno Jesus 00cpxxx@gmail.com 2011-08-03 22:26:09 CDT --- Created an attachment (id=35803) --> (http://bugs.winehq.org/attachment.cgi?id=35803) New simplified patch and without todo_wines on the correctly passing tests
This patch also affects bug 9425.
I'm still playing with the MSG_PEEK test, sorry =(
http://bugs.winehq.org/show_bug.cgi?id=21387
--- Comment #16 from Bruno Jesus 00cpxxx@gmail.com 2011-08-04 22:13:49 CDT --- Created an attachment (id=35813) --> (http://bugs.winehq.org/attachment.cgi?id=35813) 2 tests for MSG_PEEK
I have added two different tests, when the socket is connected and when it's not. Doing that I found an inconsistency that I addressed using a todo_wine.
On windows XP trying a recv on a closed socket returns WSAENOTCONN, on wine it returns WSAEBADF.
http://bugs.winehq.org/show_bug.cgi?id=21387
Bruno Jesus 00cpxxx@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #35813|0 |1 is obsolete| |
--- Comment #17 from Bruno Jesus 00cpxxx@gmail.com 2011-08-04 22:29:03 CDT --- Created an attachment (id=35814) --> (http://bugs.winehq.org/attachment.cgi?id=35814) 3 MSG_PEEK tests (better version)
http://bugs.winehq.org/show_bug.cgi?id=21387
--- Comment #18 from André H. nerv@dawncrow.de 2011-08-05 12:04:57 CDT --- so you should first send your MSG_PEEK test (with todo_wine where needed without your fix) and the WSAENOTCONN test in a seperate patch to wine-patches@winehq.org
then you can send your fix with removing the todo_wines
http://bugs.winehq.org/show_bug.cgi?id=21387
--- Comment #19 from Bruno Jesus 00cpxxx@gmail.com 2011-08-25 21:25:13 CDT --- Should be fixed by bebc425bb52fde72611a767c732b0214074b3f17.
There were two problems here, first is that MSG_PEEK was deadlocking the application, tests prove this is not happening anymore.
Second there was a false-positive fd being set on write making the program think the connection was established, this is fixed too.
http://bugs.winehq.org/show_bug.cgi?id=21387
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED
--- Comment #20 from Austin English austinenglish@gmail.com 2011-08-26 13:16:58 CDT --- (In reply to comment #19)
Should be fixed by bebc425bb52fde72611a767c732b0214074b3f17.
There were two problems here, first is that MSG_PEEK was deadlocking the application, tests prove this is not happening anymore.
Second there was a false-positive fd being set on write making the program think the connection was established, this is fixed too.
Fixed.
http://bugs.winehq.org/show_bug.cgi?id=21387
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #21 from Alexandre Julliard julliard@winehq.org 2011-09-09 12:55:25 CDT --- Closing bugs fixed in 1.3.28.
http://bugs.winehq.org/show_bug.cgi?id=21387
Bruno Jesus 00cpxxx@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |bebc425bb52fde72611a767c732 | |b0214074b3f17
https://bugs.winehq.org/show_bug.cgi?id=21387
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |focht@gmx.net Component|-unknown |winsock
-
wine-bugs＠winehq.org