Re: Socket hangs on SSL_read/SSL_write
"Bill @ Rebey.com" <[EMAIL PROTECTED]> writes: > I have a pair of programs that work fine (they can communicate with one > another) in "clear" (non-SSL mode), but when I switch them to use SSL, the > SSL_write hangs, as does the SSL_read on the other end. ( "select"ing for > Read on the reader's handle doesn't even work - the "select" never trips). You say the SSL_write() hangs? This in general shouldn't happen unless you're trying to write something really enormous. However, if it is happening that would explain why select() never trips. Try running the code under the debugger. Then break it once it's hung (e.g. using Ctrl-C) and let us know what the stack trace looks like. -Ekr __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: Socket hangs on SSL_read/SSL_write
Here's the stack you asked for: NTDLL! ZwWaitForSingleObject + 11 bytes MSAFD! WSPStartup + -19775 bytes WS2_32! WSARecv + 174 bytes WSOCK32! recv + 51 bytes PENSERVER_D! BIO_new_socket + 199 bytes PENSERVER_D! BIO_read + 87 bytes PENSERVER_D! ssl23_read_bytes + 45 bytes PENSERVER_D! ssl23_get_client_hello + 72 bytes PENSERVER_D! ssl23_accept + 352 bytes PENSERVER_D! sslv23_base_method + 358 bytes PENSERVER_D! SSL_write + 94 bytes __cSocket::Send(const void *, int) line 1636 + 20 bytes It looks like the problem is simple: The SSL_write does a READ to negotiate the Handshake before it does anything else! The other end is select()ing on Read handles, and this end is reading, too, so clearly therein lies the holdup. What's up with that?? Obviously this indicates a discrepancy in how SSL sockets work and clear sockets work. How can I fix this? Can I force the handshake to take place before the first SSL_Write? Can I force SSL_Write to do a Write of some sort before it does a Read? What's the proper way to fix this? Thanks again for the help! Bill Rebey -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Eric Rescorla Sent: Wednesday, August 15, 2001 11:36 AM To: [EMAIL PROTECTED] Subject: Re: Socket hangs on SSL_read/SSL_write "Bill @ Rebey.com" <[EMAIL PROTECTED]> writes: > I have a pair of programs that work fine (they can communicate with one > another) in "clear" (non-SSL mode), but when I switch them to use SSL, the > SSL_write hangs, as does the SSL_read on the other end. ( "select"ing for > Read on the reader's handle doesn't even work - the "select" never trips). You say the SSL_write() hangs? This in general shouldn't happen unless you're trying to write something really enormous. However, if it is happening that would explain why select() never trips. Try running the code under the debugger. Then break it once it's hung (e.g. using Ctrl-C) and let us know what the stack trace looks like. -Ekr __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: Socket hangs on SSL_read/SSL_write
Eric Rescorla wrote, > The man page says: ^^^ Huh? Which platform? I'd be more impressed by POSIX chapter and verse, but even that's irrelevant because all it might or might not tell us is that many platforms aren't fully POSIX compliant. > select() examines the I/O descriptor sets whose addresses are > passed in readfds, writefds, and exceptfds to see if some of their > descriptors are ready for reading, are ready for writing, or have > an exceptional condition pending, respectively. > > "won't block on read/write" seems like a reasonable interpretation > of "ready for reading..." Maybe reasonable, but wrong. Even if POSIX mandates the behaviour you're claiming, and even if we ignored the considerations David Schwartz raised, the most we could say is that the descriptor *was* readable/writable at the point at which it was examined by select. Any actual read/write occurs later, leaving a nice big window of opportunity for races (eg. another thread might consume all available input before the selecting thread gets a shot at it). Cheers, Miles -- Miles Sabin InterX Internet Systems Architect 27 Great West Road +44 (0)20 8817 4030 Middx, TW8 9AS, UK [EMAIL PROTECTED] http://www.interx.com/ __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
