On Thu, 4 Feb 2021 13:00:47 GMT, Fernando Guallini <fguall...@openjdk.org>
wrote:
> The server side is binding to the wildcard address which has been a source of
> instability in many networking tests due to javax.net.ssl.SSLException:
> Connection reset. Changing the following tests to bind to loopback address
> fixes intermittent failures:
> sun/security/ssl/SSLSocketImpl/ReverseNameLookup.java
> javax/net/ssl/TLSCommon/TLSTest.java
> sun/security/ssl/CipherSuite/SupportedGroups.java
>
>
> javax/net/ssl/SSLSession/TestEnabledProtocols.java still throws a connection
> reset occasionally because the server closes the connection before the client
> is done during handshake. That race condition cannot be completely removed in
> this test, thus is now handled and logged.
test/jdk/javax/net/ssl/SSLSession/TestEnabledProtocols.java line 29:
> 27: /*
> 28: * @test
> 29: * @bug 4416068 4478803 4479736 8241372
Here and in the other tests:
If a fix is a test bug and only contains test changes, we usually don't add the
bug id to the modified tests. Instead we add the label `noreg-self` to the JBS
issue. The bug ids in the tests files are supposed to identify *source changes*
that can be verified by running the test.
test/jdk/javax/net/ssl/SSLSession/TestEnabledProtocols.java line 145:
> 143: // The server side may have closed the socket.
> 144: System.out.println("Client SSLException:");
> 145: ssle.printStackTrace(System.out);
If security / TLS experts agree that this is OK, then it is OK for me. Not
being an expert, I'd be concerned that catching plain SSLException might be too
wide and that this might hide errors. In that case, and if the error is
intermittent, one possibility could be to respin the test in case of
SSLException (do client side and server side again) and fail if the second
attempts fails too.
test/jdk/sun/security/ssl/SSLSocketImpl/ReverseNameLookup.java line 90:
> 88: (SSLServerSocketFactory) SSLServerSocketFactory.getDefault();
> 89: InetSocketAddress socketAddress =
> 90: new InetSocketAddress(InetAddress.getLoopbackAddress(),
> serverPort);
The client is using 127.0.0.1. InetAddress.getLoopbackAddress() might return
::1 (IPv6 loopback) on certain configurations.
Two possibility:
1. run this test with -Djava.net.preferIPv4Stack to force usage of IPv4, but
trivially pass if IPv4 is not available on the machine (see IPSupport in the
test library)
2. use InetAddress.getLoopbackAddress().getHostAddress() on the client side
instead of "127.0.0.1"
If you choose 2. you may want to add an additional @run the test with
-Djava.net.preferIPv6Address to verify that it works with IPv6 - as there are
several ways to represent the IPv6 loopback as a string
-------------
PR: https://git.openjdk.java.net/jdk/pull/2405
