If your sockets are all in non-blocking mode, you will
need to do a select() on the socket (for writing)
after the call to connect() to confirm that the
connection has completed.  The SSL_connect() call
should then return the need_write/need_read.  If it
doesn't, then I would try looping even if you get the
ERR_SYSCALL error, wrap the whole thing in a 2 second
alert, and do some testing to make sure that 2 seconds
is a good number as a max wait time.
  
My concern is that the underlying sockets are not
fully compliant, and so the openssl code is reporting
the best error that it can.

Tim

--- rajagopalan ramanujam <[EMAIL PROTECTED]>
wrote:
> hi tim,
> 
> I forgot to mention about the version, its
> openssl-0.9.7 and the OS is threadX running on ARM
> processor using GH compiler.
> 
> raj
> 
> --- Tim Regovich <[EMAIL PROTECTED]> wrote:
> > did youtry ERR_get_error() or perror("") to see
> what
> > they return.
> > 
> > The only guess i have is that the underlying
> socket
> > is
> > not yet connected, but i would have expectedan
> > SSL_ERROR_WANT_ACCEPT.
> > 
> > Are you using SSL_set_fd(...)?
> > 
> > Can you send me the conect section of your code? 
> I
> > will take a look at it and see what is going on.
> > 
> > also helpful would be what OS you are running on
> and
> > what version of openssl.
> > 
> > You can email me directly [EMAIL PROTECTED] and
> we
> > can take this off the discussion board.
> > 
> > Regards,
> > 
> > Tim
> > --- rajagopalan ramanujam
> <[EMAIL PROTECTED]>
> > wrote:
> > > 
> > > SSL_connect(ssl) return 0 and
> > SSL_get_error(ssl,err)
> > > is returning SSL_ERROR_SYSCALL.What i am i doing
> > > wrong?
> > > 
> > > 
> > > while(!done) {
> > >  err = SSL_connect(ssl);
> > >  if(err >0 || (SSL_get_error(ssl,err) != 
> > > SSL_ERROR_WANT_READ && SSL_get_error(ssl,err) !=
> > > SSL_ERROR_WANT_WRITE))
> > >        done = 1;
> > >   }
> > > Its taking arround 10 secs to respond to the
> > > ClientHello message from the openssl s_server
> > > running
> > > on linux.
> > > 
> > > If i introduce a delay then things work fine.
> > > 
> > > 
> > > 
> > > 
> > > --- Tim Regovich <[EMAIL PROTECTED]> wrote:
> > > > Ignore my last message, it was incomplete.
> > > > you should not need to use a bio pair.
> > > > Instead, you should be able to do something
> like
> > > so
> > > > :
> > > > 
> > > > while(!done) {
> > > >   rv = SSL_connect(my_ssl_ptr);
> > > >   if(rv >=0 || (SSL_get_error() !=
> > > > SSL_ERROR_WANT_READ
> > > >           && SSL_Get_error() !=
> SSL_WANT_WRITE)
> > > >      done = 1;
> > > > }
> > > > 
> > > > This will lock your system up for the length
> of
> > > the
> > > > transaction though, which could be
> problematic. 
> > > For
> > > > robustness you would then want to wrap this
> code
> > > in
> > > > an
> > > > alert or some other notifying mechanism to
> allow
> > > for
> > > > a
> > > > hard timeout.
> > > > 
> > > > Regards,
> > > > 
> > > > Tim
> > > > 
> > > > --- rajagopalan ramanujam
> > > <[EMAIL PROTECTED]>
> > > > wrote:
> > > > > hi tim,
> > > > > 
> > > > > Thanks for the response. The first solution
> > that
> > > > you
> > > > > proposed, is it that SSL_connect calling
> again
> > > > based
> > > > > on the return value (like
> > > > SSL_ERROR_WANT_READ.Should
> > > > > i
> > > > > use a BIO pair?
> > > > > 
> > > > > Socket layer was implemented locally and was
> > > > > Blocking
> > > > > functionality was disabled intentionaly (God
> > > knows
> > > > > why)
> > > > > 
> > > > > - raj
> > > > > 
> > > > > --- Tim Regovich <[EMAIL PROTECTED]>
> wrote:
> > > > > > There are two solutions :
> > > > > > 
> > > > > > 1) rewrite the client to use a non
> blocking
> > io
> > > > > model
> > > > > > and handle the incoming dtat
> asynchronously
> > > > > > 
> > > > > > 2) modify the client to wait at each SSL
> api
> > > > > command
> > > > > > (handshakes, reads, writes) until the
> error
> > > code
> > > > > > return is not WANT_READ or WANT_WRITE. 
> This
> > > of
> > > > > > course
> > > > > > will only work if you are doing reads of a
> > > known
> > > > > > size.
> > > > > > 
> > > > > > What embedded board are you using that
> > doesn't
> > > > > > support
> > > > > > synchronous socket I/O?
> > > > > > 
> > > > > > Regards,
> > > > > > 
> > > > > > Tim
> > > > > > 
> > > > > > 
> > > > > > --- rajagopalan ramanujam
> > > > > <[EMAIL PROTECTED]>
> > > > > > wrote:
> > > > > > > hi,
> > > > > > > 
> > > > > > > I am running client on the embedded
> board
> > > > which
> > > > > > has
> > > > > > > TCP stack with only non-blocking sockets
> > > > > > support.The
> > > > > > > problem is that when i send clientHello
> > > > message
> > > > > to
> > > > > > > the
> > > > > > > server (running linux) responds with
> > > > serverhello
> > > > > > > only
> > > > > > > after 2 Secs and since the sockets on my
> > > side
> > > > is
> > > > > > > always non-blocking when it tries to
> read
> > > > > > > (ret=ssl3_get_server_hello(s)) always
> > return
> > > > 0.
> > > > > If
> > > > > > > introduce a delay (2-3secs) i can 
> > > > successfully
> > > > > > > complete the handshake.
> > > > > > > 
> > > > > > > Is there a way out for this problem??
> > > > > > > 
> > > > > > > - raj
> > > > > > > 
> > > > > > >
> > > > >
> > >
> __________________________________________________
> > > > > > > Do you Yahoo!?
> > > > > > > Yahoo! Platinum - Watch CBS' NCAA March
> > > > Madness,
> 
=== message truncated ===

__________________________________________________
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
http://platinum.yahoo.com
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [EMAIL PROTECTED]
Automated List Manager                           [EMAIL PROTECTED]

Reply via email to