Not sure about Vista per se ... Initially I ran the test case on
windows 7 and the same failures existed
so on analysis and tracing lead me to the TwoStackPlainDatagramSocketImpl
I'm dependent on JPRT to handle the vista case ... if a Vista box exists
I can run the test explicitly on it to ensure nothing has been overlooked?
But, from my analysis the issue appeared to be the case that the
ipv6_available is
an OS level check, and this is insufficient as the individual
adapters/interfaces
may not be configured for IPv6, and so are handled as IPv4 interfaces.
regards
Mark
On 16/09/2013 12:11, Michael McMahon wrote:
On 16/09/13 11:33, Chris Hegarty wrote:
Mark,
From what I can see, I think the changes are correct.
On 16/09/2013 11:10, Michael McMahon wrote:
One comment so far. The ipv4mode parameter in
getIPv4NetworkInterface()
seems superfluous, with the call using parameter value "0"
could be just elided to using the null return value directly.
I think the param is needed to determine if the function should ever
return NULL, or force creation of the NI instance. From what I can
see, Mark's changes preserve the same behavior by using this param.
Right. I missed the return statement just before.
I was a bit confused also that the new function is in the TwoStacks...
module,
but it seems this file contains native code common to both dual
stack/two stacks
mode. We probably should move this code to a different source file some
time,
but it might be useful to put a comment in at least to say that it is
common
to both modes.
I'm not sure what what code you are referring to here, but as far as
I am aware there is no dual stack code in this file. Yes, there is
both IPv4 and IPv6, but both should be on separate sockets.
yep. Forget that as well. I thought it was being called from common
code. So, I'm missing how this
code is relevant then on Vista, which should be using the dual stack
implementation then ?
Michael
-Chris.
Michael
On 15/09/13 12:34, Mark Sheppard wrote:
Hi
please oblige and review the webrev below which addresses the issue
problem:
https://bugs.openjdk.java.net/browse/JDK-6458027
webrev:
http://cr.openjdk.java.net/~msheppar/6458027/webrev/
the core of the issue is that a windows platform may be IPv6
enabled, but
an individual adapter/interface may not be configured with for IPv6.
This causes a problem with the MulticastSocket.setNetworkInterface()
and MulticastSocket.getNetworkInterface() methods.
The solution focuses on adding and additional check on the
individual interface for IPV6 enabling.
The fallback position when an adapter is not configured for IPV6,
is to
handled it as IPV4, only.
It should be noted that setting an Interface which does not have a
valid IP address bound to it will result in a SocketException. As
such, i
the onus in on the application to supply a validly configured
NetworkInterface object to the MulticastSocket.setNetworkInterface().
With this in mind, the set of Interfaces constructed for the
associated test
is based on the interface being up, multicast, and valid IP address
configured.
regards
Mark
