> On 20. Apr 2017, at 20:01, mahesh gs <mahesh...@gmail.com> wrote: > > Hi, > > This issue occur purely based on the time (sequence of events) at which SSL > read_state_machine enter the post processing of certificate verify which is > received from client. > > Handshake works fine if the certificate verify post processing is done before > the next message arrives at SCTP socket layer (In your case may be there is a > delay in receiving the next message at SCTP layer). Handshake works fine even > in my environment some times. Can you try the attached patch and report if it fixes the issue for you?
Best regards Michael
dtls.patch
Description: Binary data
> > > I added some debug statements, below is the debug statements. > > > Debug statements when the handshake does not work > > <image.png> > > Length of the next packet (Cipher spec change) is exactly 14 as i mentioned > in - https://github.com/openssl/openssl/issues/3251 > > Debug logs when the handshake is successful > > <image.png> > > If no message is waiting to be received at socket layer then handshake is > successful. If message is waiting to be received at socket layer then the > handshake will never be completed. > > > Thanks, > Mahesh G S > > On Thu, Apr 20, 2017 at 7:17 PM, Martin Brejcha <martin.brej...@mavenir.com> > wrote: > > > Matt Caswell wrote on 04/20/2017 03:23 PM: > > > > > > On 20/04/17 14:19, Martin Brejcha wrote: > >> > >> > >> Matt Caswell wrote on 04/20/2017 01:29 PM: > >>> > >>> > >>> On 20/04/17 12:26, mahesh gs wrote: > >>>> Hi Matt, > >>>> > >>>> Yes I raised github case for the same issue. I also tried running this > >>>> call flow with the latest SNAPSHOT code (openssl-SNAP-20170419) and > >>>> handshake is successful with the latest SNAPSHOT code which is not an > >>>> official release. > >>>> > >>>> I checked the github repo history and observer that during commits on > >>>> (11 th Jan) as a part of "Move state machine knowledge out of the record > >>>> layer". "renegotiate" bit that is set to "2" in function > >>>> "tls_post_process_client_hello" has been removed. May be that is causing > >>>> the call flow to be successful in the latest SNAPSHOT release. > >>>> > >>>> I am assuming commits that are done on 11th Jan or later are not part of > >>>> release openssl 01.01.00e > >>> > >>> Ah. No. That commit is in the dev branch only (scheduled for version > >>> 1.1.1) and won't be backported to the 1.1.0 branch. I can see why that > >>> commit might help things, but probably a different solution is more > >>> appropriate for 1.1.0. > >>> > >>> I'm looking at this issue at the moment. > >>> > >>> Matt > >>> > >> > >> hi, > >> > >> btw: I've tested similar scenario and handshake works fine. > >> test env: client and server on different VMs (rhel7.2, openssl 1.1.0e, > >> non-blocking sockets and segmented certificate) > >> So, it should work also with 1.1.0e version. > > > > Thanks. Did your handshake include client auth? I think this issue only > > arises in that case. > > > > Matt > > > > > > yes, client auth with segmented certificate has been included. > > Martin > > > > > > > > > -- > 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
-- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
