Matt,
If you have any way to enable some kind of logging it will be useful to find what is the issue.
Why do we get error 2 for ssl_accept. We have seen this for connect but not sure why we get it for accept.
Thanks,
Grace
On 31-Oct-2017 6:56 PM, "Grace Priscilla Jero" <grace.priscilla@xxxxxxxxx> wrote:
Matt,Here is more info on the process backtrace where it is stuck.cat /proc/15602/stack[<ffffffff812ab64d>] inet_csk_accept+0xc1/0x1f0[<ffffffff812cc3b5>] inet_accept+0x28/0xf5[<ffffffff81267362>] sys_accept4+0x11b/0x1b8[<ffffffff8126740a>] sys_accept+0xb/0xd[<ffffffff81312152>] system_call_fastpath+0x16/0x1b[<ffffffffffffffff>] 0xffffffffffffffffThanks,GraceOn Tue, Oct 31, 2017 at 4:22 PM, Grace Priscilla Jero <grace.priscilla@xxxxxxxxx> wrote:Please find attached the pcap. It only has Client Hello.While debugging SSL_accept, I see it stuck in s->method->ssl_read_bytesThanks,GraceOn Tue, Oct 31, 2017 at 4:16 PM, Matt Caswell <matt@xxxxxxxxxxx> wrote:
On 31/10/17 10:40, Grace Priscilla Jero wrote:
> Hi Matt,
> yes, we have found that later and have add the call backs. But we never
> get the Client Hello with cookie. The Hello verify request is sent from
> the server.
>
> Thanks for pointing out that listen was for cookies. Now without that
> providing the SSL_accept, it hangs. We are unable to figure out why it
> hangs. Only client hello is sent. Is there any way to spot what is going
> wrong.
I suggest you use Wireshark to take a look what is happening on the wire.
Matt
>
> Thanks,
> Grace
>
> On Tue, Oct 31, 2017 at 3:50 PM, Matt Caswell <matt@xxxxxxxxxxx
> <mailto:matt@xxxxxxxxxxx>> wrote:
>
>
>
> On 31/10/17 06:06, Grace Priscilla Jero wrote:
> > Thankyou for the suggestions. After correcting few options the
> > "ClientHello" goes successfully but we have failure in "DTLSv1_listen".
> > There are'nt any cookies in the Client Hello request.
> > But DTLSv1_listen return error and the failure in see is in
> > "SSLerr(SSL_F_DTLSV1_LISTEN, SSL_R_COOKIE_GEN_CALLBACK_FAILURE);" > <mailto:grace.priscilla@gmail
>
> This is most likely because you haven't called
> SSL_CTX_set_cookie_generate_cb() first.
>
> > We are using 1.1.0f version. Is there a way we can disable cookies?
>
> Well the whole *point* of calling DTLSv1_listen() is to generate those
> cookies. If you don't want cookies, don't call it.
>
> Matt
>
> >
> > Thanks,
> > Grace
> >
> > On Fri, Oct 27, 2017 at 12:39 PM, Grace Priscilla Jero
> > <grace.priscilla@xxxxxxxxx <mailto:grace.priscilla@gmail.com >
.com
> <mailto:grace.priscilla@gmail.com >>> wrote:
> >
> > Hi Matt,
> >
> > SSL_get_error() returns 5.
> > It is the same socket using which the UDP connection is established.
> > Could you suggest some logging that can be done for OPENSSL.
> >
> > Thanks,
> > Grace
> >
> >
> > On Thu, Oct 26, 2017 at 9:23 PM, Matt Caswell <matt@xxxxxxxxxxx <mailto:matt@xxxxxxxxxxx>
> > <mailto:matt@xxxxxxxxxxx <mailto:matt@xxxxxxxxxxx>>> wrote:
> >
> >
> >
> > On 26/10/17 16:43, Grace Priscilla Jero wrote:
> > > Thankyou for the responses.
> > > We figured the issue. But now we are getting error -5
> from "SSL_connect"
> > > and the errno is set to 22 which means invalid argument.
> > > Is there a easy way to debug or get logs for SSL_connect.
> > >
> > > Below is the sequence for the dtls udp connect that we
> are trying.
> > > ssl = SSL_new(ctx)
> > > bio = BIO_new_dgram(sock_id,BIO_NOCLOSE)
> > > SSL_set_bio(ssl, bio, bio);
> > > VI_res = SSL_connect(ssl)
> >
> > Do you really mean SSL_connect() returns -5? Or do you
> mean that
> > after a
> > negative return value from SSL_connect() you call
> > SSL_get_error() and
> > that return 5 (SSL_ERROR_SYSCALL)?
> >
> > If you really mean SSL_connect() returns -5 then you need
> to call
> > SSL_get_error() as a next step.
> >
> > If you are getting SSL_ERROR_SYSCALL then my guess is that
> there
> > is a
> > problem with sock_id. How do create it?
> >
> > Matt
> >
> >
> > >
> > >
> > >
> > > Thanks,
> > > Grace
> > >
> > > On Tue, Oct 24, 2017 at 4:07 PM, Matt Caswell
> <matt@xxxxxxxxxxx <mailto:matt@xxxxxxxxxxx> <mailto:matt@xxxxxxxxxxx
> <mailto:matt@xxxxxxxxxxx>>
> > > <mailto:matt@xxxxxxxxxxx <mailto:matt@xxxxxxxxxxx>
> <mailto:matt@xxxxxxxxxxx <mailto:matt@xxxxxxxxxxx>>>> wrote:
> > >
> > >
> > >
> > > On 24/10/17 11:25, Grace Priscilla Jero wrote:
> > > > We are using SSL_accept to accept the connection
> for which we see the
> > > > failure. Please let know if you have any thoughts.
> > >
> > > Have you set the wbio correctly? Does SSL_get_wbio()
> return your wbio
> > > object if you call it immediately before
> SSL_do_handshake()?
> > >
> > > Matt
> > >
> > > --
> > > openssl-users mailing list
> > > To unsubscribe:
> > >
> https://mta.openssl.org/mailman/listinfo/openssl-users
> <https://mta.openssl.org/mailman/listinfo/openssl-users >
> > <https://mta.openssl.org/mailman/listinfo/openssl-users
> <https://mta.openssl.org/mailman/listinfo/openssl-users >>
> > >
> <https://mta.openssl.org/mailman/listinfo/openssl-users
> <https://mta.openssl.org/mailman/listinfo/openssl-users >
> > <https://mta.openssl.org/mailman/listinfo/openssl-users
> <https://mta.openssl.org/mailman/listinfo/openssl-users >>>
> > >
> > >
> > >
> > >
> > --
> > openssl-users mailing list
> > To unsubscribe:
> > https://mta.openssl.org/mailman/listinfo/openssl-users
> <https://mta.openssl.org/mailman/listinfo/openssl-users >
> > <https://mta.openssl.org/mailman/listinfo/openssl-users
> <https://mta.openssl.org/mailman/listinfo/openssl-users >>
> >
> >
> >
> >
> >
> --
> openssl-users mailing list
> To unsubscribe:
> https://mta.openssl.org/mailman/listinfo/openssl-users
> <https://mta.openssl.org/mailman/listinfo/openssl-users >
>
>
>
>
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
-- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
