Closed mniestroj closed 1 month ago
We think we have the same problem as this. In our case the server is pion/dtls and the client is an embedded device communicating over cellular (e.g. NB-IoT). The client occasionally seems to miss the server's Hello Verify Request message and retransmits its Client Hello (with sequence number 0). The server ignores this as duplicate packet (see logs below) and doesn't send a new Hello Verify Request. Attached the Wireshark captures. (In this case I'm not sure whether the replay should stop this packet or whether the handshake should continue with a new server Hello Verify Request after the client hello on no. 12.) Hope this helps analysing this issue.
My problem may also be related to this issue.
According to RFC6347 section 4.2.8,
In cases where a server believes it has an existing association on a given host/port quartet and it receives an epoch=0 ClientHello, it SHOULD proceed with a new handshake but MUST NOT destroy the existing association until the client has demonstrated reachability either by completing a cookie exchange or by completing a complete handshake including delivering a verifiable Finished message.
However, it appears that the server does not respond to ClientHello with existing parameters.
These are log screenshots on the client. The server is built with PionDTLS, the client is not. (client=10.254.0.162, server=100.66.1.41)
This was fixed by ec76652f161d0116e85db57af95768639688accb and d013d0c2f9a366c6fa24bc3f4ba848e2f6a1219b
We also have a test for this in TestPionE2ELossy now. We disable RTX on one side, and it is entirely driven by the client
If anyone is still seeing issues please drop a message and would love to help
Your environment.
What did you do?
Run example PSK listener from https://github.com/mniestroj/pion-dtls/tree/handshake-not-finishing, which contains some adjustments for mbedTLS client that I use. Also the retransmit timer was extended from 1s to 30s to help reproduce the issue.
Communication was done on tun/tap interface, because it actually happens between virtual machine (QEMU) and host. In order to simulate packet loss, following command was executed on host:
which basically makes 75% of the packets to be dropped, which is great way to test handshake retransmission mechanisms (and reproduce this bug).
What did you expect?
Server should follow DTLS spec, which says: "the node that transmits the last flight MUST respond to a retransmit of the peer's last flight with a retransmit of the last flight". This means that server should respond to client retransmissions, as the handshake was not complete from the client point of view (due to packet loss).
Server thinks that handshake has completed. This is not true, because mbedTLS client did not receive the last message from server, so it keeps retransmitting previous message.
According to https://datatracker.ietf.org/doc/html/rfc6347#section-4.2.4:
What happened?
Server ignores client retransmissions. This can be seen on wireshark logs (screen) above.