Re: RFR: JDK-8257235: [PATCH] InetAddress.isReachable: Try to use an IPPROTO_ICMP socket type before attempting RAW_SOCK [v2]
> Users have been able to send ICMP packets without the need for root > privileges or the CAP_NET_RAW capability since at least kernel 3.11. > > For some time now, if the kernel parameter net.ipv4.ping_group_range included > the gid of a user sending an icmp packet with the IPPROTO_ICMP protocol, then > the packet would> > It's important to note that the both the checksum and ident field are > overwritten by the kernel when this is done. > > Newer distributions are now setting the default value of > net.ipv4.ping_group_range to be open to all possible group ids (Fedora 31 and > Ubuntu 20.04 for example) so it can b> > > Also of note is the that this is also implemented in MacOS. > > This patch proposes attempting to use IPPROTO_ICMP first, and then fall back > to attempting a raw socket and ultimately failing over to tcp echo. > This patch also alters the logic for identifying icmp reply packets, since > the kernel overwrites id ident field when using the IPPROTO_ICMP protocol. > The method is similar to that used by the ping(8) utility in the iputils > package, where we compare data in the icmp_data member of the icmp struct > to identify the packet as our response. The ping utility compares the > timeval, whereas this patch proposes to compare both the timeval and the > user's pid. Jamie Le Tual has updated the pull request incrementally with one additional commit since the last revision: Fixed formatting - Changes: - all: https://git.openjdk.java.net/jdk/pull/1502/files - new: https://git.openjdk.java.net/jdk/pull/1502/files/923e3489..1c8a555f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1502&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1502&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1502.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1502/head:pull/1502 PR: https://git.openjdk.java.net/jdk/pull/1502
Re: RFR: JDK-8257235: [PATCH] InetAddress.isReachable: Try to use an IPPROTO_ICMP socket type before attempting RAW_SOCK [v2]
On Tue, 22 Dec 2020 14:08:26 GMT, Alan Bateman wrote: > Adding support for SOCK_DGRAM/IPPROTO_ICMP(6) is good and I think is mostly > okay. The comments and the formatting is messy in several places and should > be cleaned up before the patch is sponsored. Alan, thanks for taking a look at the patch. I tried to see which comments and formatting where messy and I have to say I don't see what your are talking about; as far as I can tell the formatting in the patch doesn't diverge from the code style of the files they are in. Can you give a specific example of what you consider messy so I can know what you're talking about? - PR: https://git.openjdk.java.net/jdk/pull/1502
Re: RFR: 8255264: Support for identifying the full range of IPv4 localhost addresses on Windows
On Mon, 30 Nov 2020 18:09:57 GMT, Mat Carter wrote: > Modified Windows specific loopback macros to support full range of loopback > addresses, commit message includes unit test data as there's no gtest's for > java libraries (only hotspot compiler) > > This is an expansion on the original fix for 8250521: Configure initial RTO > to use minimal retry for loopback connections on Windows > > IPV4 loopback addresses are defined as 127.0.0.0/8 the CIDR translates to a > range of 127.0.0.0 to > 127.255.255.255 inclusive. > > The previous macro implementation only identified 127.0.0.1 and ::1 as > loopback addresses, this is corrected in this change > > Note that as IPV6 is defined as ::1/128 only ::1 is a valid loopback address Looks good. - Marked as reviewed by alanb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1523
Re: RFR: 8255264: Support for identifying the full range of IPv4 localhost addresses on Windows
On Wed, 23 Dec 2020 16:10:27 GMT, Alan Bateman wrote: >> Modified Windows specific loopback macros to support full range of loopback >> addresses, commit message includes unit test data as there's no gtest's for >> java libraries (only hotspot compiler) >> >> This is an expansion on the original fix for 8250521: Configure initial RTO >> to use minimal retry for loopback connections on Windows >> >> IPV4 loopback addresses are defined as 127.0.0.0/8 the CIDR translates to a >> range of 127.0.0.0 to >> 127.255.255.255 inclusive. >> >> The previous macro implementation only identified 127.0.0.1 and ::1 as >> loopback addresses, this is corrected in this change >> >> Note that as IPV6 is defined as ::1/128 only ::1 is a valid loopback address > > Looks good. Thanks for the review Alan - PR: https://git.openjdk.java.net/jdk/pull/1523
