Wonderful! Thanks a lot for your help. It works properly on my system without the /etc/protocols workaround:
1> maps:get(0, prim_socket:p_get(protocols)).
[ip,hopopt,'HOPOPT']
And of course what we were doing it for:
2> {ok, Sock} = socket:open(inet, dgram, udp, #{port => 5557}).
{ok,{'$socket',#Ref<0.3985991783.3553755144.74821>}}
3> socket:setopt(Sock, {ip, recvtos}, true).
ok
Mystery solved!
Excellent! Thank you for reporting this bug!
I am considering changing how protocol name aliases are handled, that is, to not use them for socket options.
That would mean to only allow {ip,recvtos} as the option name for SOL_IP,IP_RECVTOS, and not {'IP',recvtos} nor the incorrect {hopopt,recvtos} and {'HOPOPT',recvtos}. That is; to not use the protocol names from getprotoent() in socket:setsockopt/3 and socket:getsockopt/2, only in socket:setopt_native/3 and socket:getopt_native/3.
Would that be an improvement?
I think it’s a good idea. Having one way to do things is preferable over two ways of doing the same thing. Removing 'IP' would achieve this. Removing the incorrect hopopt is a no-brainer if you ask me.
I’m not familiar enough to understand if there can be downsides.
The possible risk I can see is if someone has relied on socket:supports(options)'s return values {'IP',_} being valid to use for socket:setopt|getopt.