RFR: JDK-6458027 - Disabling IPv6 on a specific network interface causes problems

[Mark Sheppard]

Hi Michael,
    thanks for the response.

the getIPv4NetworkInterface is called in two places within the
getMulticastInterface function. It's a refactoring of what would have been
duplicate code. This lead to the "boolean" ipv4Mode.

line 2039

     if (isIPV4) {
         jobject netObject = NULL; // return is either an addr or a netif
         netObject = getIPv4NetworkInterface(env, this, fd, opt, 1);
         return netObject;
     }

and
line 2134
             return addr;
         } else if (index == 0) {
             jobject netObject = NULL;
             netObject = getIPv4NetworkInterface(env, this, fd, opt, 0);
             if (netObject != NULL) {
                 return netObject;
             }
         }

in the former the return will either be a always be an object, which
may have a null NetworkInterface object

in the latter it maybe null value in which case this branch of the code fabricates
a null NetworkInterface object. The calling sequence here is for IPv6 and
is slightly different than that for IPv4.

hence the use of ipv4Mode indicator in getIPv4NetworkInterface function.

I'll add some comments as suggested


regards
Mark


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 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.
>
> 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
>