Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RTP engine sent DTLS client hello with fragmented #413

Closed
raviraja0969 opened this issue Nov 1, 2017 · 11 comments
Closed

RTP engine sent DTLS client hello with fragmented #413

raviraja0969 opened this issue Nov 1, 2017 · 11 comments

Comments

@raviraja0969
Copy link

@raviraja0969 raviraja0969 commented Nov 1, 2017

Hi Team,

Hope you are doing great.

We are getting DTLS handshake failure errors since rtpengine sends dtls client hello (fragmented). Due to this The browser (Edge : version 40) sends error " Client Hello[Reassembly error, protocol DTLS: New fragment overlaps old data (retransmission?)]"

Is there any way that Rtpengine sends only plain client hello DTLS packet.

Could you please guide us how to resolve this issue.

Thanks in advance

@rfuchs

This comment has been minimized.

Copy link
Member

@rfuchs rfuchs commented Nov 1, 2017

Can you post a pcap of this? The DTLS packets are coming straight out of OpenSSL so I'm not sure what the issue could be.

@raviraja0969

This comment has been minimized.

Copy link
Author

@raviraja0969 raviraja0969 commented Nov 1, 2017

unsuccesswithoutdtlspassive.zip
Thanks For your quick response.

We are using openssl version 1.0.2g and Ubuntu version 16.04 ..

Find the attached pcap file for your reference

@rfuchs

This comment has been minimized.

Copy link
Member

@rfuchs rfuchs commented Nov 2, 2017

I don't believe the "fragmented" aspect is a problem, since the browser does respond to the initial Client Hello. The initial Client Hello is packet 591. The browser responds with a Hello Verify Request as it should in packet 592. Rtpengine then responds to that with another Client Hello in packet 594, now with the cookie from the Verify Request included. However, this second Client Hello is then ignored by the browser. The flagged packets 864 and 1010 are actually retransmits of 594, because the browser never responded.

Since the only difference between packets 591 and 594 is the cookie from 592, I see no reason why the DTLS fragmentation should be a problem, since the browser responded to 591 just fine. Also these packets are generated by OpenSSL and not touched by rtpengine in any way. I would investigate on the browser side of things for this issue.

@raviraja0969

This comment has been minimized.

Copy link
Author

@raviraja0969 raviraja0969 commented Nov 3, 2017

Thanks for your response..

Please suggest us how to do once you are done your R&D

@rfuchs

This comment has been minimized.

Copy link
Member

@rfuchs rfuchs commented Nov 3, 2017

I can't tell you how to debug your browser. I can only suggest to try other browsers, see what happens there and compare.

@raviraja0969

This comment has been minimized.

Copy link
Author

@raviraja0969 raviraja0969 commented Nov 3, 2017

we tried other browsers like firefox, chrome, Safari but we got this error only in Microsoft Edge browser

@jamesaylett

This comment has been minimized.

Copy link

@jamesaylett jamesaylett commented Feb 22, 2018

I am able to reproduce this issue on CentOS 7.4.1708 using OpenSSL 1.0.2k-fips. It seems that OpenSSL isn't determining the OS' MTU, causing the packet fragmentation seen the the pcap trace.

I was able to 'fix' the issue by modifying dtls.c dtls_connection_init() to call:

SSL_CTX_set_options(d->ssl_ctx, SSL_OP_NO_QUERY_MTU);
SSL_set_mtu(d->ssl, 1500);

to prevent OpenSSL trying to set the MTU by itself and hard-coding the MTU. The pcap shows that the Hello packets have the IP flag Don't Fragment set, but the flag for More Fragments unset, so I assume that schannel used by Edge is unable to reassemble the packets.

I haven't investigated further but I believe the issue is with OpenSSL and I am not sure whether this issue is addressed in a later version.

@rfuchs

This comment has been minimized.

Copy link
Member

@rfuchs rfuchs commented Feb 22, 2018

AFAIU this fragmentation is the DTLS fragmentation, not IP fragmentation. @jamesaylett can you confirm that setting the MTU like this actually makes a difference? Do you have a pcap for comparison? As I already mentioned, the pcap posted by @raviraja0969 doesn't actually seem to show a problem with fragmented packets, as the packets are responded to.

@jamesaylett

This comment has been minimized.

Copy link

@jamesaylett jamesaylett commented Feb 22, 2018

See the attached pcap traces. With the above mentioned modification to rtpengine-5.5.1.1 and without. The packet fragmentation in the without case looks to be identical to @raviraja0969 issue. You are correct that in the failed case Edge does respond to the first Hello, so perhaps my assumptions about Edge not handling the fragmented packets is wrong.

Either way it does seem like the modification does fix the issue. Discussion of a similar issue in the OpenSSL github.

withmodification.zip
withoutmodification.zip

@rfuchs

This comment has been minimized.

Copy link
Member

@rfuchs rfuchs commented Feb 22, 2018

Interesting, looks like a bug in certain versions of OpenSSL. Thanks for this.

@harry1230

This comment has been minimized.

Copy link

@harry1230 harry1230 commented Dec 4, 2019

Hi Sorry for restart this thread but i have exactly the same problem. I use OpenSSL 1.0.2h and a sip stack (pjProject) and i always get the fragmentation in the handshake from the client. I tried to set the MTU but it is not working. Do you have any hint or any advise how i can test the MTU in Openssl?

` SSL_CTX_set_options(ossock->ossl_ctx , SSL_OP_NO_QUERY_MTU);

SSL_set_mtu(ossock->ossl_ssl, 1500);

DTLS_set_link_mtu(ossock->ossl_ssl, 1500);`

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.