[openssl.org #1703] Bug report for DTLS

[David Woodhouse via RT]

For version 0.9.8h
in do_dtls1_write()

in the block:

/* first check if there is a SSL3_BUFFER still being written
  * out.  This will happen with non blocking IO */
if (s->s3->wbuf.left != 0)
{
  OPENSSL_assert(0); /* XDTLS:  want to see if we ever get
here */
  return(ssl3_write_pending(s,type,buf,len));
}


To answer the comment's question: "Yes, we do get there."

Regards,
Joel Reardon

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev@...
Automated List Manager                           majordomo@...

[David Woodhouse via RT]

If I recall correctly, when I saw this problem the issue was sending
user data larger than the MTU detected during handshake negotiation.  
The DTLS code seems to have some inconsistencies related to this, as MTU
should not have an effect on user data -- the protocol only provides
fragmentation of handshakes.

  - Ariel

Joel Reardon via RT wrote:

> For version 0.9.8h
> in do_dtls1_write()
>
> in the block:
>
> /* first check if there is a SSL3_BUFFER still being written
>   * out.  This will happen with non blocking IO */
> if (s->s3->wbuf.left != 0)
> {
>         OPENSSL_assert(0); /* XDTLS:  want to see if we ever get
> here */
>         return(ssl3_write_pending(s,type,buf,len));
> }
>
>
> To answer the comment's question: "Yes, we do get there."
>
> Regards,
> Joel Reardon
>
> ______________________________________________________________________
> OpenSSL Project                                 http://www.openssl.org
> Development Mailing List                       openssl-dev@...
> Automated List Manager                           majordomo@...
>
>  

--
 - Ariel Salomon / Senior Software Engineer
Real-Time Innovations (RTI) / www.rti.com
408 990-7439 / ariel@...

RTI - The Real-Time Middleware Experts



______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev@...
Automated List Manager                           majordomo@...

[Ariel Salomon]

If I recall correctly, when I saw this problem the issue was sending
user data larger than the MTU detected during handshake negotiation.  
The DTLS code seems to have some inconsistencies related to this, as MTU
should not have an effect on user data -- the protocol only provides
fragmentation of handshakes.

  - Ariel

Joel Reardon via RT wrote:

> For version 0.9.8h
> in do_dtls1_write()
>
> in the block:
>
> /* first check if there is a SSL3_BUFFER still being written
>   * out.  This will happen with non blocking IO */
> if (s->s3->wbuf.left != 0)
> {
>         OPENSSL_assert(0); /* XDTLS:  want to see if we ever get
> here */
>         return(ssl3_write_pending(s,type,buf,len));
> }
>
>
> To answer the comment's question: "Yes, we do get there."
>
> Regards,
> Joel Reardon
>
> ______________________________________________________________________
> OpenSSL Project                                 http://www.openssl.org
> Development Mailing List                       openssl-dev@...
> Automated List Manager                           majordomo@...
>
>  

--
 - Ariel Salomon / Senior Software Engineer
Real-Time Innovations (RTI) / www.rti.com
408 990-7439 / ariel@...

RTI - The Real-Time Middleware Experts


______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev@...
Automated List Manager                           majordomo@...

[David Woodhouse via RT]

Thanks,

I have MTU discover on, and am testing the peers using a single computers
loopback. I'll try setting the MTU using a ctrl() and do some
investigations to see if thats the problem. Anyhow, the existance
of code following an assert(0) and the
comment suggesting that the authors added it during testing to see if the
clause is reached suggests that either its unfinished, at least
likely untested, or the assertion is unnessary (or, at least minimally,
the code that follows it is unnessarily); I thought I'd bring that up.
I'm having other bugs/troubles with DTLS as I'm using it for an amibition
project. In the coming weeks I'll either present cogent bug
reports/examples programs, or fix it myself depending on how long this
Thesis takes to write and submit the patch.

Joel

On Wed, 18 Jun 2008, Ariel Salomon via RT wrote:

>
> If I recall correctly, when I saw this problem the issue was sending
> user data larger than the MTU detected during handshake negotiation.
> The DTLS code seems to have some inconsistencies related to this, as MTU
> should not have an effect on user data -- the protocol only provides
> fragmentation of handshakes.
>
>  - Ariel
>
> Joel Reardon via RT wrote:
>> For version 0.9.8h
>> in do_dtls1_write()
>>
>> in the block:
>>
>> /* first check if there is a SSL3_BUFFER still being written
>>   * out.  This will happen with non blocking IO */
>> if (s->s3->wbuf.left != 0)
>> {
>>         OPENSSL_assert(0); /* XDTLS:  want to see if we ever get
>> here */
>>         return(ssl3_write_pending(s,type,buf,len));
>> }
>>
>>
>> To answer the comment's question: "Yes, we do get there."
>>
>> Regards,
>> Joel Reardon
>>
>> ______________________________________________________________________
>> OpenSSL Project                                 http://www.openssl.org
>> Development Mailing List                       openssl-dev@...
>> Automated List Manager                           majordomo@...
>>
>>
>
>
> --
> - Ariel Salomon / Senior Software Engineer
> Real-Time Innovations (RTI) / www.rti.com
> 408 990-7439 / ariel@...
>
> RTI - The Real-Time Middleware Experts
>
>
>

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev@...
Automated List Manager                           majordomo@...