[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