8236184: (dc) IP_MULTICAST_* and IP_TOS socket options not effective

[Alan Bateman]

On 18/12/2019 17:10, Daniel Fuchs wrote:
> Hi Alan,
>
> DatagramChannelImpl:
>
>  382             // remaining options don't need any special handling
>  383             Net.setSocketOption(fd, family, name, value);
>  384             if (needToSetIPv4Option) {
>  385                 try {
>  386                     Net.setSocketOption(fd, 
> StandardProtocolFamily.INET, name, value);
>  387                 } catch (IOException ignore) { }
>  388             }
>
> If family == StandardProtocolFamily.INET && needToSetIPv4Option
> won't that set the option twice?
>
> If this is impossible - maybe an assert could make it explicit:
>    assert family != StandardProtocolFamily.INET || !needToSetIPv4Option
Thanks, and well spotted! This scenario will arise on Windows if the 
channel's socket is IPv6 and it is bound IPv4 local address. It doesn't 
arise on other platforms. So in this Windows scenario it would indeed 
set the IPv4 socket option twice. Harmless but L384 should be:

if (family != StandardProtocolFamily.INET && needToSetIPv4Option) {


>
>
> Otherwise looks reasonable to me.
> Does the new test pass reliably on macOS? We already have some
> multicast tests in the ProblemList.txt for that platform.
The @requires limits the platforms that it runs on so macOS is skipped 
because IPv4 socket options are not effective on IPv6 sockets there. 
There are several issues open in JBS on this, the workaround is 
-Djava.net.preferIPv4Stack=true on macOS. MulticastSocket has the same 
issue of course.

-Alan