Yah we raised a SR with Oracle support regarding the problem and in the mean time fixed it on OpenJDK. Maybe you were the engineer assigned the SR or the resulting bug?
Hopefully the submission of this patch dedupes work someone would have to do to address the issue. On Fri, May 22, 2015 at 8:05 AM, Rob McKenna <rob.mcke...@oracle.com> wrote: > Hi Brian, > > By coincidence I just started looking at this today myself. > > We have an existing bug filed for this issue: > https://bugs.openjdk.java.net/browse/JDK-8080819 > > The diagnosis looks good. > > -Rob > > > On 22/05/15 07:56, Brian Toal wrote: > >> The fix for https://bugs.openjdk.java.net/browse/JDK-7180557 causes a >> regression for Mac OSX hosts connected to a VPN (or otherwise with more >> than network >> interface associated with the hostname). >> >> For example, when on Cisco VPN, the ifconfig is as follows: >> >> lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384 >> options=3<RXCSUM,TXCSUM> >> inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 >> inet 127.0.0.1 netmask 0xff000000 >> inet6 ::1 prefixlen 128 >> gif0: flags=8010<POINTOPOINT,MULTICAST> mtu 1280 >> stf0: flags=0<> mtu 1280 >> en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500 >> ether 28:cf:e9:1a:eb:6b >> inet6 fe80::2acf:e9ff:fe1a:eb6b%en0 prefixlen 64 scopeid 0x4 >> inet 192.168.0.106 netmask 0xffffff00 broadcast 192.168.0.255 >> media: autoselect >> status: active >> p2p0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 2304 >> ether 0a:cf:e9:1a:eb:6b >> media: autoselect >> status: inactive >> utun0: flags=80d1<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST> mtu 1320 >> inet 10.3.23.199 --> 10.3.23.199 netmask 0xffffc000 >> inet6 fe80::2acf:e9ff:fe1a:eb6b%utun0 prefixlen 64 scopeid 0x6 >> inet6 fe80::49cd:21e1:4c11:721d%utun0 prefixlen 128 scopeid 0x6 >> >> The hostname entry in DNS is associated with the utun0 interface, and >> 10.3.23.199 and all routes go through that interface. The 192.168.0.106 >> IP is my local wifi address, and is not used (other than to tunnel the >> VPN traffic when VPN is connected). Any connections to the 192.168 >> address, even from localhost, will fail (hang indefinitely, as all >> packets are dropped). >> >> The OS getaddrinfo calls, when passed the FQDN hostname only return the >> 10.3 address (getaddrinfo.c attached). >> >> Prior to the fix for JDK-7180557, getaddrinfo was being used and >> everything worked fine. As part of the fix, the following block was >> added for OSX only in the IPv4 path: >> >> + #ifdef MACOSX >> + /* If we're looking up the local machine, bypass DNS lookups and get >> + * address from getifaddrs. >> + */ >> + ret = lookupIfLocalhost(env, hostname, JNI_FALSE); >> + if (ret != NULL) { >> + JNU_ReleaseStringPlatformChars(env, host, hostname); >> + return ret; >> + } >> + #endif >> >> This code, which occurs before the usual path and applies only to >> localhost lookups, tries to "guess" the localaddress by interface >> enumeration. In the case of a VPN configuration, both en0 (192.168) and >> utun0 will match as they are active. So, for example, >> InetAddress.getAllByName("localhost FQDN"), will return both addresses. >> However, the getByName() call and most other code which implicitly uses >> the localhost will return only the first entry, which is the unroutable >> en0 address. >> >> The host is configured correctly and other processes all resolve the >> hostname correctly. The issue is specific to this OSX workaround. >> >> On the IPv6 path for the same fix, the lookupIfLocalhost workaround was >> only applied *if* the original lookup via the usual routines failed. The >> attached patch follows the same approach in the IPv4 path, if the >> orginal lookup fails then call lookupIfLocalhost If this was applied to >> the IPv4 path. The patch fixes the issue without regressing the hosts >> that triggered this fix. >> >> # HG changeset patch >> # User btoal >> # Date 1432276472 25200 >> # Thu May 21 23:34:32 2015 -0700 >> # Node ID 24cf7a8a8bf4f489da6b2506bcb57cb329a93593 >> # Parent 20e6cadfac43717a81d99daff5e769de695992cd >> Only call lookupIfLocalhost if getaddrinfo call errors to avoid >> resolving to a incorrect address. >> >> diff -r 20e6cadfac43 -r 24cf7a8a8bf4 >> src/solaris/native/java/net/Inet4AddressImpl.c >> --- a/src/solaris/native/java/net/Inet4AddressImpl.c Thu Feb 05 >> 13:00:26 2015 +0100 >> +++ b/src/solaris/native/java/net/Inet4AddressImpl.c Thu May 21 >> 23:34:32 2015 -0700 >> @@ -172,20 +172,19 @@ >> return NULL; >> } >> >> -#ifdef MACOSX >> - /* If we're looking up the local machine, bypass DNS lookups and get >> - * address from getifaddrs. >> - */ >> - ret = lookupIfLocalhost(env, hostname, JNI_FALSE); >> - if (ret != NULL || (*env)->ExceptionCheck(env)) { >> - JNU_ReleaseStringPlatformChars(env, host, hostname); >> - return ret; >> - } >> -#endif >> - >> error = getaddrinfo(hostname, NULL, &hints, &res); >> >> if (error) { >> +#ifdef MACOSX >> + /* If we're looking up the local machine, bypass DNS lookups >> and get >> + * address from getifaddrs. >> + */ >> + ret = lookupIfLocalhost(env, hostname, JNI_FALSE); >> + if (ret != NULL || (*env)->ExceptionCheck(env)) { >> + JNU_ReleaseStringPlatformChars(env, host, hostname); >> + return ret; >> + } >> +#endif >> /* report error */ >> ThrowUnknownHostExceptionWithGaiError(env, hostname, error); >> JNU_ReleaseStringPlatformChars(env, host, hostname); >> >
