[PATCH] fix Inet4AddressImpl.lookupAllHostAddr returning unroutable addresses
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=8049UP,LOOPBACK,RUNNING,MULTICAST mtu 16384
options=3RXCSUM,TXCSUM
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1
inet 127.0.0.1 netmask 0xff00
inet6 ::1 prefixlen 128
gif0: flags=8010POINTOPOINT,MULTICAST mtu 1280
stf0: flags=0 mtu 1280
en0: flags=8863UP,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 0xff00 broadcast 192.168.0.255
media: autoselect
status: active
p2p0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 2304
ether 0a:cf:e9:1a:eb:6b
media: autoselect
status: inactive
utun0: flags=80d1UP,POINTOPOINT,RUNNING,NOARP,MULTICAST mtu 1320
inet 10.3.23.199 -- 10.3.23.199 netmask 0xc000
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.cThu Feb 05 13:00:26
2015 +0100
+++ b/src/solaris/native/java/net/Inet4AddressImpl.cThu 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);
Re: 8080819: [PATCH] fix Inet4AddressImpl.lookupAllHostAddr returning unroutable addresses
Adding bug id to subject for reference.
-Rob
On 22/05/15 16:05, Rob McKenna 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=8049UP,LOOPBACK,RUNNING,MULTICAST mtu 16384
options=3RXCSUM,TXCSUM
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1
inet 127.0.0.1 netmask 0xff00
inet6 ::1 prefixlen 128
gif0: flags=8010POINTOPOINT,MULTICAST mtu 1280
stf0: flags=0 mtu 1280
en0: flags=8863UP,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 0xff00 broadcast 192.168.0.255
media: autoselect
status: active
p2p0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 2304
ether 0a:cf:e9:1a:eb:6b
media: autoselect
status: inactive
utun0: flags=80d1UP,POINTOPOINT,RUNNING,NOARP,MULTICAST mtu 1320
inet 10.3.23.199 -- 10.3.23.199 netmask 0xc000
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.cThu Feb 05
13:00:26 2015 +0100
+++ b/src/solaris/native/java/net/Inet4AddressImpl.cThu 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,
Re: [PATCH] fix Inet4AddressImpl.lookupAllHostAddr returning unroutable addresses
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=8049UP,LOOPBACK,RUNNING,MULTICAST mtu 16384
options=3RXCSUM,TXCSUM
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1
inet 127.0.0.1 netmask 0xff00
inet6 ::1 prefixlen 128
gif0: flags=8010POINTOPOINT,MULTICAST mtu 1280
stf0: flags=0 mtu 1280
en0: flags=8863UP,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 0xff00 broadcast 192.168.0.255
media: autoselect
status: active
p2p0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 2304
ether 0a:cf:e9:1a:eb:6b
media: autoselect
status: inactive
utun0: flags=80d1UP,POINTOPOINT,RUNNING,NOARP,MULTICAST mtu 1320
inet 10.3.23.199 -- 10.3.23.199 netmask 0xc000
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.cThu Feb 05
13:00:26 2015 +0100
+++ b/src/solaris/native/java/net/Inet4AddressImpl.cThu 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);
Re: [PATCH] fix Inet4AddressImpl.lookupAllHostAddr returning unroutable addresses
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=8049UP,LOOPBACK,RUNNING,MULTICAST mtu 16384
options=3RXCSUM,TXCSUM
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1
inet 127.0.0.1 netmask 0xff00
inet6 ::1 prefixlen 128
gif0: flags=8010POINTOPOINT,MULTICAST mtu 1280
stf0: flags=0 mtu 1280
en0: flags=8863UP,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 0xff00 broadcast 192.168.0.255
media: autoselect
status: active
p2p0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 2304
ether 0a:cf:e9:1a:eb:6b
media: autoselect
status: inactive
utun0: flags=80d1UP,POINTOPOINT,RUNNING,NOARP,MULTICAST mtu 1320
inet 10.3.23.199 -- 10.3.23.199 netmask 0xc000
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.cThu Feb 05
13:00:26 2015 +0100
+++ b/src/solaris/native/java/net/Inet4AddressImpl.cThu 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
+
