Apologies for delayed response. There was some bureaucracy to go through
to make sure I had management approval for releasing the code which
explains my interest in the subject.
That's done now; we have a full open source client for the VPN in
question, and OpenSSL client support for BAD_DTLS_VER
Note: I have reverted the DTLS1_BAD_VER part as DTLS1_BAD_VER handling
is not present in HEAD (0.9.9).
That makes sense.
I assume that DTLS1_BAD_VER handling wasn't added to HEAD because the
pre-RFC version of DTLS was considered to be an OpenSSL-specific thing
that would quickly die out
David Woodhouse wrote:
On Mon, 2008-10-13 at 09:01 +0200, Lutz Jaenicke via RT wrote:
Note: I have reverted the DTLS1_BAD_VER part as DTLS1_BAD_VER handling
is not present in HEAD (0.9.9).
That makes sense.
I assume that DTLS1_BAD_VER handling wasn't added to HEAD because the
[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
On Mon, 2008-10-13 at 09:01 +0200, Lutz Jaenicke via RT wrote:
Note: I have reverted the DTLS1_BAD_VER part as DTLS1_BAD_VER handling
is not present in HEAD (0.9.9).
That makes sense.
I assume that DTLS1_BAD_VER handling wasn't added to HEAD because the
pre-RFC version of DTLS was considered
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
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
__
OpenSSL Project
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 WoodhouseOpen Source Technology Centre
[EMAIL
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
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
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
11 matches
Mail list logo
