This is the mail archive of the
mailing list for the Cygwin project.
RE: Problem with accept(2) on the 1003.20.0.0 release
- From: jeff_burch at agilent dot com
- To: cygwin at cygwin dot com, Tino dot Lange at isg dot de
- Date: Fri, 14 Feb 2003 10:59:02 -0800
- Subject: RE: Problem with accept(2) on the 1003.20.0.0 release
Dear Tino and the rest of the Cygwin community,
I made a post yesterday (2/13) on this problem and posted a testAccept.cpp program. By the way, my new version of cygwin and g++ agreed perfectly with Tino's response. Also, tests to use a specific "real" address in the bind( ) call didn't change the problem behavior...
As an experiment, I happened to have an old version of cygwin's install package on a server and have move the problem machine back to the distant past:
CYGWIN_NT-5.0 SSLGROUPOB 1.3.3(0.46/3/2) 2001-09-12 23:54 i686 unknown
The testAccept.exe built on this version of Cygwin works perfectly. Also, my testAccept.exe built on the lastest version of Cygwin runs perfectly on this version of Cygwin. And one more "fun fact": I tweaked the program and built it under Visual C++ and it runs perfectly.
So, on my machine the new version of Cygwin has a problem! Accept(2) will hang on the second call for the same socket. I wonder who else in the world will have similar problem. Tino reports that he doesn't have any problems on his machine...
At this point, I don't know what else to try. I'm pretty sure the problem is down in the new cygwin1.dll but I don't have the time or knowledge to go digging into that beast. Also, I'm not sure what interaction on my system is causing the problem. Clearly if Tino can run my testAccept.exe, then there has got to be something different...
Any suggestions anyone?
Communications Solutions Department
From: Tino Lange [mailto:Tino.Lange@isg.de]
Sent: Thursday, February 13, 2003 2:56 PM
Subject: Re: Problem with accept(2) on the 1003.20.0.0 release
I remeber some time ago hanging my sshd on the second connect if it was
bound to all interfaces.
Just a weird idea: Could you try to bind the server socket only to your
"real" IP and try again with telnet <ip> <port>?
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html