On Thursday, July 28, 2016 at 5:13:33 AM UTC-7, Martin Thomson wrote: > This is likely a retransmission. NSS has fairly aggressive timers for > retransmission of DTLS messages. If your ServerHello doesn't arrive > quickly, then you will see a second ClientHello after 50ms and a third > after another 100ms. As long as the handshake completes successfully, > I wouldn't worry about this. > > On Tue, Jul 26, 2016 at 11:38 PM, <[email protected]> wrote: > > Firefox 48 always sends a double DTLS hello message when acting as the > > client, where FF47 and other browsers only send one. This happens using > > our product and also in AppRTC. > > > > The first hello has seq=0, message_seq=0, > > and the second has seq=1, message_seq=0. > > > > Does anyone know why this change happened, and is it a fix, or a bug? > > > > E.g.: > > Protocol Length Info > > DTLSv1.2 211 Client Hello > > DTLSv1.2 211 Client Hello > > DTLSv1.2 129 Server Hello > > DTLSv1.2 567 Certificate > > DTLSv1.2 268 Server Key Exchange > > DTLSv1.2 67 Server Hello Done > > DTLSv1.2 129 Server Hello > > DTLSv1.2 567 Certificate > > DTLSv1.2 268 Server Key Exchange > > DTLSv1.2 67 Server Hello Done > > DTLSv1.2 208 Client Key Exchange, Change Cipher Spec, Encrypted > > Handshake Message > > DTLSv1.2 208 Client Key Exchange, Change Cipher Spec, Encrypted > > Handshake Message > > DTLSv1.2 60 Change Cipher Spec > > DTLSv1.2 103 Encrypted Handshake Message > > DTLSv1.2 60 Change Cipher Spec > > DTLSv1.2 103 Encrypted Handshake Message > > DTLSv1.2 81 Encrypted Alert > > > > > > Thanks, > > Jennifer > > _______________________________________________ > > dev-media mailing list > > [email protected] > > https://lists.mozilla.org/listinfo/dev-media
It does seem to be retransmission. The second client hello is sent 50 ms afterwards, and the first server hello comes in after that. When I ignore the second client hello and send only one server hello sequence, I still get two Client Key Exchange/change cipher/encrypted handshake messages, spaced out by 50 ms. So that is a retransmission as well. It was causing problems in our implementation when we received the second client key exchange sequence after the handshake was already completed. I fixed it by filtering out the retransmitted messages before they get interpreted by our protocol. FF47 wasn't as aggressive with the retry time, so it's possible that some other WebRTC services might see problems transitioning with FF48. _______________________________________________ dev-media mailing list [email protected] https://lists.mozilla.org/listinfo/dev-media
