| # |
|
Tue Jun 17 22:42:33 2008 |
jreardon@cs.uwaterloo.ca - Ticket created
|
|
|
|
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
|
| # |
|
Wed Jun 18 16:17:59 2008 |
ariel@rti.com - Correspondence added
|
|
|
|
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@openssl.org
> Automated List Manager majordomo@openssl.org
>
>
--
- Ariel Salomon / Senior Software Engineer
Real-Time Innovations (RTI) / www.rti.com
408 990-7439 / ariel@rti.com
RTI - The Real-Time Middleware Experts
|
| # |
|
Wed Jun 18 16:18:00 2008 |
RT_System - Status changed from 'new' to 'open'
|
|
|
|
|
| # |
|
Wed Jun 18 23:52:40 2008 |
jreardon@cs.uwaterloo.ca - Correspondence added
|
|
|
|
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@openssl.org
>> Automated List Manager majordomo@openssl.org
>>
>>
>
>
> --
> - Ariel Salomon / Senior Software Engineer
> Real-Time Innovations (RTI) / www.rti.com
> 408 990-7439 / ariel@rti.com
>
> RTI - The Real-Time Middleware Experts
>
>
>
|
| # |
|
Thu Oct 02 05:51:18 2008 |
dwmw2@infradead.org - Correspondence added
|
|
|
|
I can reproduce this failure at will. All I need to do is set up a DTLS
connection, then somehow cause the write() call on the UDP socket to
return an error -- a firewall is an easy way of achieving that.
--
David Woodhouse Open Source Technology Centre
David.Woodhouse@intel.com Intel Corporation
|
| # |
|
Thu Oct 02 06:52:48 2008 |
dwmw2@infradead.org - Correspondence added
|
|
|
|
On Thu, 2008-10-02 at 05:47 +0100, David Woodhouse wrote:
> I can reproduce this failure at will. All I need to do is set up a DTLS
> connection, then somehow cause the write() call on the UDP socket to
> return an error -- a firewall is an easy way of achieving that.
The whole _point_ of DTLS is that it's a datagram service. That
datagrams go missing. So buffering them up when we fail to send them --
even if we _weren't_ then going to crap ourselves and abort() as a
result -- was a bad idea in the first place.
(I include DTLS1_BAD_VER here because of RT#1751)
--- openssl-0.9.8g/ssl/s3_pkt.c~ 2006-11-29 14:45:14.000000000 +0000
+++ openssl-0.9.8g/ssl/s3_pkt.c 2008-10-02 06:41:07.000000000 +0100
@@ -753,8 +753,15 @@ int ssl3_write_pending(SSL *s, int type,
s->rwstate=SSL_NOTHING;
return(s->s3->wpend_ret);
}
- else if (i <= 0)
+ else if (i <= 0) {
+ if (s->version == DTLS1_VERSION ||
+ s->version == DTLS1_BAD_VER) {
+ /* For DTLS, just drop it. That's kind of the whole
+ point in using a datagram service */
+ s->s3->wbuf.left = 0;
+ }
return(i);
+ }
s->s3->wbuf.offset+=i;
s->s3->wbuf.left-=i;
}
--
David Woodhouse Open Source Technology Centre
David.Woodhouse@intel.com Intel Corporation
|
| # |
|
Tue Oct 07 10:57:01 2008 |
openssl-dev@openssl.org - Ticket 1758: Ticket created
|
|
|
|
This simple fix to the 0.9.8 branch addresses RT #1703, where a DTLS bug
causes applications to abort. It was causing my VPN client to abort
during temporary network problems which it should have coped with and
recovered from.
When the underlying BIO_write() fails to send a datagram, we leave the
offending record queued as 'pending'. The DTLS code doesn't expect this,
and we end up hitting an OPENSSL_assert() in do_dtls1_write().
The simple fix is just _not_ to leave it queued. In DTLS, dropping
packets is perfectly acceptable -- and even preferable. If we wanted a
service with retries and guaranteed delivery, we'd be using TCP.
--- ssl/s3_pkt.c~ 2006-11-29 14:45:14.000000000 +0000
+++ ssl/s3_pkt.c 2008-10-02 06:41:07.000000000 +0100
@@ -753,8 +753,15 @@ int ssl3_write_pending(SSL *s, int type,
s->rwstate=SSL_NOTHING;
return(s->s3->wpend_ret);
}
- else if (i <= 0)
+ else if (i <= 0) {
+ if (s->version == DTLS1_VERSION ||
+ s->version == DTLS1_BAD_VER) {
+ /* For DTLS, just drop it. That's kind of the whole
+ point in using a datagram service */
+ s->s3->wbuf.left = 0;
+ }
return(i);
+ }
s->s3->wbuf.offset+=i;
s->s3->wbuf.left-=i;
}
--
dwmw2
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majordomo@openssl.org
|
| # |
|
Tue Oct 07 16:10:40 2008 |
jaenicke - Ticket 1758: Requestor dwmw2@infradead.org added
|
|
|
|
|
| # |
|
Tue Oct 07 16:10:40 2008 |
jaenicke - Ticket 1758: Requestor openssl-dev@openssl.org deleted
|
|
|
|
|
| # |
|
Tue Oct 07 16:11:01 2008 |
jaenicke - Ticket 1758: Merged into ticket #1703
|
|
|
|
|
| # |
|
Tue Oct 07 16:11:01 2008 |
jaenicke - Merged into ticket #1703
|
|
|
|
|
| # |
|
Fri Oct 10 12:39:51 2008 |
jaenicke - Taken
|
|
|
|
|
| # |
|
Fri Oct 10 12:42:51 2008 |
jaenicke - Correspondence added
|
|
|
|
I have applied the patch to 0.9.8-stable and adopted it to 0.9.9-dev. I
am not very familiar with the DTLS implementation so hopefully I did not
break it.
Best regards,
Lutz
|
| # |
|
Fri Oct 10 12:42:51 2008 |
jaenicke - Status changed from 'open' to 'resolved'
|
|
|
|
|
| # |
|
Fri Oct 10 13:02:53 2008 |
dwmw2@infradead.org - Correspondence added
|
|
|
|
On Fri, 2008-10-10 at 12:42 +0200, Lutz Jaenicke via RT wrote:
> I have applied the patch to 0.9.8-stable and adopted it to 0.9.9-dev. I
> am not very familiar with the DTLS implementation so hopefully I did not
> break it.
Thanks. Sorry to be impatient. I've got myself onto a team tasked with
implementing supporting for Linux connectivity to the company VPN, and
I'm very keep to avoid them settling on Cisco's client, which has some
fairly scary security holes as well as just integrating properly with
the desktop or being supportable, etc.
I'm trying to present the open client which I've now written as a fait
accompili -- and aside from the OpenSSL part, I'm fairly much there. We
have packages for 'openconnect' and 'NetworkManager-openconnect' on the
way through the Fedora review process and we're about to get other
people to do the same for other distributions... all we need now is to
get the distributions' OpenSSL packages updated so that DTLS works and
we're not using TCP over TCP. And understandably, distributions want to
see the patches upstream before they ship them. Especially with one with
the extra option for Cisco compatibility.
--
dwmw2
|
| # |
|
Fri Oct 10 13:02:54 2008 |
RT_System - Status changed from 'resolved' to 'open'
|
|
|
|
|
| # |
|
Mon Oct 13 09:01:58 2008 |
jaenicke - Correspondence added
|
|
|
|
> [jaenicke - Fri Oct 10 12:42:51 2008]:
>
> I have applied the patch to 0.9.8-stable and adopted it to 0.9.9-dev. I
> am not very familiar with the DTLS implementation so hopefully I did not
> break it.
Note: I have reverted the DTLS1_BAD_VER part as DTLS1_BAD_VER handling
is not
present in HEAD (0.9.9).
Best regards,
Lutz
|
| # |
|
Mon Oct 13 09:02:21 2008 |
jaenicke - Status changed from 'open' to 'resolved'
|
|
|
|
|
