[Bug 21387] New: NetTerm locks up
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(a)winehq.org ReportedBy: nerv(a)dawncrow.de CC: support(a)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(a)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.
-- 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=21387 --- Comment #1 from André H. <nerv(a)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. -- 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=21387 --- Comment #2 from Kenneth Robinette <support(a)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. -- 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=21387 --- Comment #3 from André H. <nerv(a)dawncrow.de> 2010-01-16 07:51:13 --- one moment, resolved in your app or by a workaround? -- 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=21387 André H. <nerv(a)dawncrow.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |INVALID --- Comment #4 from André H. <nerv(a)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.
-- 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=21387 Dmitry Timoshkov <dmitry(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |UNCONFIRMED Resolution|INVALID | --- Comment #5 from Dmitry Timoshkov <dmitry(a)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? -- 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=21387 --- Comment #6 from Kenneth Robinette <support(a)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 -- 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=21387 Dmitry Timoshkov <dmitry(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Version|unspecified |1.0.1 --- Comment #7 from Dmitry Timoshkov <dmitry(a)codeweavers.com> 2010-01-18 22:36:32 --- Testing with 1.0.1 is not useful. Does the bug exist in 1.1.36? -- 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=21387 --- Comment #8 from Kenneth Robinette <support(a)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. -- 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=21387 --- Comment #9 from Kenneth Robinette <support(a)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! -- 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=21387 Bruno Jesus <00cpxxx(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |00cpxxx(a)gmail.com --- Comment #10 from Bruno Jesus <00cpxxx(a)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. -- 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=21387 --- Comment #11 from Bruno Jesus <00cpxxx(a)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 -- 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=21387 Dan Kegel <dank(a)kegel.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch Status|UNCONFIRMED |NEW CC| |dank(a)kegel.com Ever Confirmed|0 |1 --- Comment #12 from Dan Kegel <dank(a)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().) -- 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=21387 --- Comment #13 from André H. <nerv(a)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. -- 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=21387 --- Comment #14 from Bruno Jesus <00cpxxx(a)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. -- 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=21387 Bruno Jesus <00cpxxx(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #35792|0 |1 is obsolete| | --- Comment #15 from Bruno Jesus <00cpxxx(a)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 =( -- 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=21387 --- Comment #16 from Bruno Jesus <00cpxxx(a)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. -- 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=21387 Bruno Jesus <00cpxxx(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #35813|0 |1 is obsolete| | --- Comment #17 from Bruno Jesus <00cpxxx(a)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) -- 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=21387 --- Comment #18 from André H. <nerv(a)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(a)winehq.org then you can send your fix with removing the todo_wines -- 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=21387 --- Comment #19 from Bruno Jesus <00cpxxx(a)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. -- 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=21387 Austin English <austinenglish(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #20 from Austin English <austinenglish(a)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. -- 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=21387 Alexandre Julliard <julliard(a)winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #21 from Alexandre Julliard <julliard(a)winehq.org> 2011-09-09 12:55:25 CDT --- Closing bugs fixed in 1.3.28. -- 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=21387 Bruno Jesus <00cpxxx(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |bebc425bb52fde72611a767c732 | |b0214074b3f17 -- 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.
https://bugs.winehq.org/show_bug.cgi?id=21387 Anastasius Focht <focht(a)gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |focht(a)gmx.net Component|-unknown |winsock -- 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 (1)
-
wine-bugs＠winehq.org