Request for Review 6887364 [SetOutgoingIf]

[Christopher Hegarty -Sun Microsystems Ireland]

Alan Bateman wrote:
> Christopher Hegarty -Sun Microsystems Ireland wrote:
>> Hi Pavel, Michael,
>>
>> 6887364: SetOutgoingIf.java fails if run on multihomed machine without 
>> PIv6 on all interfaces [more details below]
>>
>> Webrev:
>>   http://cr.openjdk.java.net/~chegar/6887364/webrev/
>>
>> I just realized why this test was failing on one of our lab machines. 
>> The reason is that the test tries to join both IPv4 and IPv6 multicast 
>> groups on network interfaces that are not loopback, are Up, and 
>> support multicast. On our machine we have one interface that has only 
>> an IPv4 address assigned to it, while another has both IPv4 and Ipv6 
>> addresses.
>>
>> I've changed the test to only try joining the appropriate multicast 
>> group if the network interface supports that IP protocol.
>>
>> Also, I noticed that the IPv4 mapped IPv6 address the test runs with 
>> actually gets converted to a regular Inet4Address because the 
>> InetAddress factory method is smarter than us! It never creates 
>> Inet6Address instances that are IPv4 mapped IPv6 addresses, it just 
>> creates Inet4Address. So (controversially) I manufactured an 
>> Inet6Address multicast instance manually. It seems to work fine.
>>
>> --------------
>> Details of failure and machine configuration:
>> Fails with:
>>   Exception in thread "main" java.net.SocketException: No such device 
>> or address
>>     at java.net.PlainDatagramSocketImpl.join(Native Method)
>>     at 
>> java.net.AbstractPlainDatagramSocketImpl.joinGroup(AbstractPlainDatagramSocketImpl.java:184) 
>>
>>     at java.net.MulticastSocket.joinGroup(MulticastSocket.java:382)
>>     at SetOutgoingIf.main(SetOutgoingIf.java:116)
>>
>> Machine configuration [IP address information removed for security 
>> reasons]:
>>   :> ifconfig -a
>> lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 
>> 8232 index 1
>>     inet 127.0.0.1 netmask ff000000
>> bge0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
>>     inet XXX.XXX.XXX.160 netmask ffffff00 broadcast XXX.XXX.XXX.255
>> bge3: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 5
>>     inet XXX.XXX.YYY.160 netmask ffffff00 broadcast XXX.XXX.YYY.255
>> bge0: flags=2000841<UP,RUNNING,MULTICAST,IPv6> mtu 1500 index 2
>>     inet6 fe80::214:4fff:fe7a:b734/10
>> lo0: flags=2002000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv6,VIRTUAL> mtu 
>> 8252 index 1
>>     inet6 ::1/128
>> ---------------
>>
>> -Chris.
> I don't know if you have a reviewer for this one yet. I went through the 
> changes to the test and the overall approach seems reasonable. The one 
> thing that doesn't seem right is attempting to do IPv4 multicasting when 
> an interface is only plumbed with IPv6 (I'm talking about the case where 
> it adds an IPv4-mapped address to the list of groups). I don't think the 
> RFC dealing with migration to IPv6 covers that scenario and I'm pretty 
> sure that many kernels don't support it either. I would suggest dropping 
> that code so that you simple test IPv4 multicast on interfaces that have 
> IPv4 address, and test IPv6 multicasting on interfaces that have IPv6 
> addresses.

I was coming around to this conclusion also. I'll just drop the IPv4 
mapped IPv6 address and update the webrev.

Thanks for the review.

-Chris.



> 
> -Alan.
>