If incoming data packets are received out of order, they seem to get
dropped by my test case using blocking I/O.
Worse, my real application using non-blocking I/O seems to just receive
garbage when the out-of-order packet arrives.
Even the blocking behaviour seems inappropriate for DTLS. Reordering
within reason should be fine -- it's a datagram service, after all.
It seems to occur because dtls1_record_replay_check() is rejecting the
packets. This, in turn, is because s->d1->next_bitmap.length is never
being set. This patch to dtls1_new() seems to fix it:
--- ssl/d1_lib.c~ 2008-10-02 06:43:47.000000000 +0100
+++ ssl/d1_lib.c 2008-10-05 21:31:38.000000000 +0100
@@ -106,6 +106,7 @@ int dtls1_new(SSL *s)
pq_64bit_init(&(d1->bitmap.map));
pq_64bit_init(&(d1->bitmap.max_seq_num));
+ d1->next_bitmap.length = d1->bitmap.length;
pq_64bit_init(&(d1->next_bitmap.map));
pq_64bit_init(&(d1->next_bitmap.max_seq_num));
That doesn't solve the question of why non-blocking I/O was returning
crap for the offending out-of-order packets, instead of just returning
an error with SSL_ERROR_WANT_READ as might be expected. But at least
it'll make that bug offend me less.
--
David Woodhouse Open Source Technology Centre
[EMAIL PROTECTED] Intel Corporation
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
