This is the mail archive of the mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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: 

uname -a
CYGWIN_NT-5.0 SSLGROUPOB 1.3.3(0.46/3/2) 2001-09-12 23:54 i686 unknown

g++ --version

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?

- J
Jeff Burch
Communications Solutions Department
Agilent Laboratories
Phone: 650-485-6364
Fax:     650-485-8092

 -----Original Message-----
From: 	Tino Lange [] 
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:
Bug reporting:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]