[9] RFR: 8159416: javax/net/ssl/DTLS/CipherSuite.java failed on timeout
Artem Smotrakov
artem.smotrakov at oracle.com
Thu Jul 28 23:36:11 UTC 2016
Hi Xuelei,
I updated CustomDatagramSocketImpl class to be able to drop some packets
randomly or by specified numbers.
While updating the test, I found
https://bugs.openjdk.java.net/browse/JDK-8161086 which I think is the
root cause of these intermittent failures.
I added a couple of PacketLoss* tests to reproduce and verify 8161086.
These tests drop different packets while handshaking. They use different
cipher suites and modes, so that they take a while. I didn't notice they
fail with timeout, but I suspect that may happen on slower machines.
That's why I increased timeout value for them. I added the tests to the
problem list since 8161086 is not fixed yet.
There are a couple of other updates to DTLSOverDatagram.java:
- Server tries to receive first application data when it finishes
handshaking. Server re-sends final handshaking messages if timeout
reached while waiting for application data from client.
- Updated client and server to use simple threads instead of thread
pools. This way, it's possible to specify meaningful names for threads
which makes logs more readable if "-Djavax.net.debug=ssl" specified
- Added more logging
- Made some fields final
At the moment, CustomDatagramSocketImplFactory doesn't drop packets by
default because it may cause intermittent failures of tests which are
based on DTLSOverDatagram class:
...
static class CustomDatagramSocketImplFactory
implements DatagramSocketImplFactory {
...
// if true, it's going to drop some packets
private static boolean dropPackets = false;
...
When 8161086 is fixed, it may be set to true by default. Currently the
packet loss rate is 5% which I think is much more than if we use UDP
sockets on localhost, so that we test DTLS impl in worse conditions.
Could you please take a look at updated webrev?
http://cr.openjdk.java.net/~asmotrak/8159416/webrev.02/
Artem
On 06/27/2016 06:25 PM, Xuelei Fan wrote:
> On 6/28/2016 9:12 AM, Artem Smotrakov wrote:
>> Hello,
>>
>> Please review this patch for javax/net/ssl/DTLS tests.
>>
>> A couple of DTLS tests fail intermittently on Mac with timeout or "Too
>> many handshake loops ..." error. The tests use UDP to transfer DTLS
>> records. It happens sometimes that server cannot receive UDP packets
>> with DatagramSocket.receive() method even if client tries to re-send
>> them multiple times. Please see logs in the bug.
>>
>> At the moment, it is not clear why UDP packets can't be delivered to
>> server. If someone has seen something similar before, or has some ideas
>> what might be the root cause, please let me know.
>>
> UDP is not reliable. It could happen that the packets get lost.
>
>> I think that the tests and DTLS implementation are fine here. Since the
>> tests are for DTLS, we can workaround this issue by avoiding real UDP
>> connections. To avoid changing test logic much, we can use a custom
>> DatagramSocketImpl and DatagramSocketImplFactory implementations to
>> replace system UDP implementation.
>>
>> The patch below updates the tests with the following:
>> - added custom DatagramSocketImpl and DatagramSocketImplFactory
>> implementations to avoid real UDP connections
> Tests for real connections in practice are needed. If we update this
> test this way, we need to add other tests to test real application
> usage. I don't think this is the right direction to avoid real UDP
> connections.
>
>> - added more test output, so that we can have more info it the tests
>> fail again
>>
> I agree with this point.
>
> Xuelei
>
>> I have run javax/net/ssl/DTLS/CipherSuite.java test in a loop on Mac,
>> and I didn't see it failed. I also have run javax/net/ssl/DTLS tests on
>> all supported generic platforms, and they worked fine.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8159416
>> http://cr.openjdk.java.net/~asmotrak/8159416/webrev.00/
>>
>> Artem
More information about the security-dev
mailing list