Failure to set `IP_MULTICAST_IF` should be fatal

[mdavidsaver]

https://epics.anl.gov/core-talk/2022/msg00456.php

Mentions #93 as fixing an "escape" of 224.0.0.128 multicast traffic which should be limited to the loopback interface. A more complete fix should treat failure to set IP_MULTICAST_IF as a fatal error. Instead, currently a message is logged, and the socket is used anyway.

epicsCoreJava/pvAccessJava/src/org/epics/pvaccess/client/impl/remote/ClientContextImpl.java

Lines 461 to 473 in 3a32ca5

	try {
	InetAddress group = InetAddress.getByName("224.0.0.128");
	localBroadcastAddress = new InetSocketAddress(group, broadcastPort);
	searchTransport.join(group, localNIF);
	// NOTE: this disables usage of multicast addresses in EPICS_PVA_ADDR_LIST
	searchTransport.setMutlicastNIF(localNIF, true);
	logger.config("Local multicast enabled on " + localBroadcastAddress + ":" + broadcastPort
	+ " using " + localNIF.getDisplayName() + ".");
	} catch (Exception th) {
	logger.log(Level.CONFIG, "Failed to initialize local multicast, funcionality disabled.", th);
	}

[mdavidsaver]

I've confirmed my suspicion that the java.net.preferIPv4Stack property was involved prior to #93. (I'm assuming that the default SelectorProvider is used, and neglecting to look through the history of the openjdk source) Setting preferIPv4Stack, or if the JVM logic detects no OS support, makes e303750 a no-op.

There is a bewildering depth of indirection, which I will only summarize here:

DatagramChannelImpl is reached through the default SelectorProvider.openDatagramChannel()

https://github.com/openjdk/jdk/blob/134acab5a40b3f927ff6343aa49477a490e410b5/src/java.base/share/classes/sun/nio/ch/DatagramChannelImpl.java#L175-L178

The Net.isIPv6Available() method ultimately calls through to an OS specific C function IPv6_supported() , which is either.

https://github.com/openjdk/jdk/blob/134acab5a40b3f927ff6343aa49477a490e410b5/src/java.base/unix/native/libnet/net_util_md.c#L103-L174

or

https://github.com/openjdk/jdk/blob/134acab5a40b3f927ff6343aa49477a490e410b5/src/java.base/windows/native/libnet/net_util_md.c#L211-L220

Looking at the unix/ implementation, I notice that only OS kernel support is being tested, not userspace configuration. With PVXS I have an additional bind() to test if an IPv6 loopback interface is configured. So I think as written, this logic will incorrectly detect IPv6 support in environments like Docker containers, where the Linux kernel supports IPv6, but no interfaces have IPv6 addresses (even the loopback).

Under unix/ there is also a DONT_ENABLE_IPV6 C macro, which doesn't seem to be set anywhere at present.

@kasemir @shroffk @juanfem fyi.

[mdavidsaver]

With pvAccessCPP, exceptions thrown by setMutlicastNIF() are allowed to propagate.

https://github.com/epics-base/pvAccessCPP/blob/81d79ecc49147452d8d87ec4eceb0975830a93c7/src/remote/blockingUDPTransport.cpp#L791