Error with examples "unexpected message" in Accept

sdamm / asio_dtls

A DTLS implementation using the ASIO library

51 stars 11 forks source link

Error with examples "unexpected message" in Accept #14

Open nato4r opened 4 years ago

nato4r commented 4 years ago

Hello I'm using asio example without changing anything and get this.

Error in Accept: unexpected message

Here is a screenshot.

error

sdamm commented 4 years ago

Could you please add the following information:

Did you use the ASIO or the Boost::ASIO example?
Which ASIO/Boost::ASIO version?
Which OS are you using?

I couldn't reproduce your Problem with Boost(1.72.0) and ASIO(1.16.1).

nato4r commented 4 years ago

This is non-boost version of ASIO 1.16.1 and I am using Windows 10 1909.

sdamm commented 4 years ago

I reproduced the Problem with windows 10, openssl 1.1.1g asio-1.16.1 but haven't found the cause yet.

I don't know how to solve it yet, but the Problem seems to be the following:

listensocket receives the client hello (expected)
listensocket responds with the hello verify
listensocket receives client hello (with cookie) At this point the client cookie is verified and we are allowed to allocate state
dtls socket is bound to local and remote address
dtls socket sends server Hello
listen socket receives Handshake message from client (this should be received by the dtls socket not by the listen socket; the listen socket can't interpret this message and the dtls socket will wait for it without success)

At least that's what how I currently understand it.

sdamm commented 4 years ago

The examples on the windows_workarounds branch should work on Windows. The usability is not great, so I willl propably change the acceptor before merging into master.

asantoni commented 9 months ago

This bug is still reproducible with Boost 1.82.0 and Windows 11. I think @sdamm's understanding is mostly correct and matches my observations as well.

One issue with the workaround is that the acceptor breaks after that. It is able to accept one DTLS connection, but then it never seems to accept any others even though async_accept has been called.

I've also found that the workaround sometimes doesn't work, but it does seem to work reliably for me when run under a debugger, so that suggests there might be a race condition here too (where the wrong socket receives a datagram). This could be part of the problem.