I have tested my library on macOS and Linux and both works. If you look into inet_icmp.erl then you will see that there is special case for handling macOS return value.
Yes, it is. Not all OSes even allow such socket. That is why my library provides a way to use either datagram or raw sockets (datagram sockets are default).
Yes. I was just mentioning the different behaviors without referring explicitly to your code which I read btw, even if I overlooked decode(<<4:4, IHL:4, Rest/binary>>) because I was mostly interested in gen_icmp_server.erl and its nice use of handle_continue.
Hi, could I persuade you to explain the code a little more here please?
I see the line referenced
decode(<<4:4, IHL:4, Rest/binary>>)
But I’m really not clear why that can’t match an unfortunate (or carefully constructed) ping response
Phrasing the question another way, is there a tight binary match for an IPv4 header that couldn’t match the ICMP body response (on Linux)?
I wonder why you don’t check the OS during init and then match on that? (Stash it in the state perhaps?)
Agreed that the continue handling is very neat!