Matt, thanks for the reply, very helpful so far! Answers to your questions below: You don't say what version of OpenSSL. > The support library I?m using is Licode: http://lynckia.com/licode/index.html The version of openssl I have compiled into it is 1.0.2h. > The packet trace you sent is quite confusing, as there appears to be > two separate handshakes going on at the same time that are interleaved. > Yes, apologies for that, I?ll do a better job of filtering the next time. :) Those were two separate handshakes pulled from a packet capture of a group video chat, filtered through Wireshark using the ?dtls? filter. > It seems quite clear that this is a retransmit of the earlier message > from client to server. Retransmits are a normal part of DTLS and are > there to handle packet loss. If a retransmitted packet is received by > one of the peers, and it has seen that packet before, then it is simply > ignored. Wireshark isn't ignoring it, and is reporting it as an "error" > simply because it has seen it before. > Thanks for that clarification. > Was this packet capture done on the client side or the server side or > somewhere in the middle? There appears to be some messages missing. > In particular I don?t see any CCS or Finished messages being exchanged. > Is the network this is over potentially noisy that might explain packet > loss? > >From the perspective of the DTLS handshake, my server hosting the Licode library is the client, and latest stable Chrome browser is the server, if I understand the terminology correctly. The packet capture was taken from the client (Licode) side. Would the CCS or Finished messages have gotten filtered out by the ?dtls? filter I applied to the packet capture? I do have the full trace and can re-filter to just one complete connection over a specific UDP port as you suggested, let me know if that would be helpful I see these failures only in situations where browser users with slow and/or lossy internet are joining, and usually when the group size gets to be six or more participants. The particular testing scenario that generated the packets you saw was a user with 225kbps upload, 5120kbps down, 70ms delay, 0% packet loss. I?ll grant you those network conditions aren?t the best for group video chat, but if Google Hangouts can pull it off, I?d like to as well. > On receiving that the client should respond with a retransmit of > the Certificate/ClientKeyExchange/CertificateVerify/CCS/Finished > flight of messages. But it does not appear to do so?the retransmit does > not happen until after the encrypted alert. > This sounds like it might be a bug in the Licode library, not resending the retransmit properly? > Are both ends of the communication using OpenSSL and if so what versions? > >From my research, I believe Chrome uses borringssl? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160917/a14da7e1/attachment.html>
