RFR: JDK-8257235: [PATCH] InetAddress.isReachable: Try to use an IPPROTO_ICMP socket type before attempting RAW_SOCK [v2]

[Conor Cleary]

On Wed, 23 Dec 2020 14:06:12 GMT, Jamie Le Tual <github.com+55101029+jamieletual at openjdk.org> wrote:

>> 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

src/java.base/unix/native/libnet/Inet4AddressImpl.c line 375:

> 373:         icmp->icmp_type = ICMP_ECHO;
> 374:         icmp->icmp_code = 0;
> 375:         // same result as downcasting the little-endian pid, although we are not longer

I don't think this is true. When downcasting the pid (which is at this stage in Nework/Big-Endian Order), the host order will be considered. Assuming that the downcast is to `uint16_t`, which it looks like is what icmp_id takes, the 16 least significant bits will be considered (if the host machine is little-endian of course). This is different from the 16 bit right shift. Here is some example output from a short C program I wrote (output is in hex to more easily demonstrate bitwise ops):

pid size: 4
int size: 4

getpid() testing:
pid   = be67f
htonl = 7fe60b00
cast  = b00
>> 16 = 7fe6

-------------

PR: https://git.openjdk.java.net/jdk/pull/1502