libc: Import OpenBSD's inet_net_{ntop,pton}

[ivy]

Summary

Our versions of these functions (originally taken from BIND) simply
don't work correctly for AF_INET6. These were removed from BIND itself
quite a while ago, but OpenBSD has made quite a few fixes in the mean
time, so import their code.

Add tests for both functions.

MFC after: 1 week
Obtained from: OpenBSD (lib/libc/net)
Reported by: Nico Sonack <[e-mail]>
PR: 289198

[ivy]

inet_net_test: add a test for an overlong prefix

the comment says we want to test this, and we do, so actually test it.

[ivy]

add tests for invalid input

[glebius]

Oh, that's a lot to review :) Thanks a lot for creating the tests. Quick question: do the tests pass on the previous implementation?

[ivy]

In D52629#1202550, @glebius wrote:

do the tests pass on the previous implementation?

no. as the reporter mentioned in the PR, our current implementation is completely broken -- it almost never produces valid output. i'm not sure how no one noticed that, but i assume these functions just aren't very widely used (i'd never even heard of them until i looked at the PR).

[ivy]

fix a few nits in inet_net_test, and while here, add the full license text to the header (for legal reasons, my new preference for files i create)

[zlei]

This change touches inet_net_ntop_ipv4(). I think this deserves careful review.

[des]

Nothing uses these functions, they are non-standard and never worked properly. Even BIND (which is where we got them) didn't use them.

[des]

lib/libc/inet/inet_net_ntop.c

73

This is wrong.

[emaste]

lib/libc/inet/inet_net_pton.c

177

If these are currently broken and do not work we should just not support net classes.

[ivy]

lib/libc/inet/inet_net_pton.c

177

this change is not related to network classes, which don't exist in IPv6 at all. as far as i'm aware our current implementation supports classes okay.

[ivy]

i've written a standalone test case for IPv4: https://people.freebsd.org/~ivy/tmp/inet.tar.Z

usage:

% make
% ./test

this runs both the FreeBSD and OpenBSD versions of inet_net_{pton,ntop} on every possible IP address and netmask combination and checks for any differences in return value. due to the number of addresses involved, it's quite slow, but i'm currently running it on universe16b and it's processes enough addresses that i'm reasonably confident the output is already the same.

this doesn't cover the IPv6 case, but since our IPv6 implementation is completely broken anyway, it can't really get worse.

[ivy]

fix a comment

[emaste]

lib/libc/inet/inet_net_pton.c

177

Oh, currently completely broken for IPv6 only. OK.

[glebius]

Your run on entire IPv4 space suggested an extra test, that would be really nice:

• generate a salt with arc4random and print it.
• using the seed and nrand48() generate a set of IP addresses, maybe 1000
• run inet_ntop() and then inet_pton() and make sure that they translate forth and back to original

Please don't consider this idea as a blocking requirement to commit. You may add it later or you may ignore this idea.

[ivy]

In D52629#1214691, @glebius wrote:

Your run on entire IPv4 space suggested an extra test, that would be really nice:

• generate a salt with arc4random and print it.
• using the seed and nrand48() generate a set of IP addresses, maybe 1000
• run inet_ntop() and then inet_pton() and make sure that they translate forth and back to original

i'm not sure we want non-deterministic test cases; aside from anything, this would probably confuse Jenkins when it's trying to bisect a failure. (not that it's much good at that anyway, but we may as well not make it worse...)

some test frameworks, like Catch2, allow you to use a specific random seed to make test failures reproducible, but i don't know if this have this in Kyua at all, or if any of our CI runners support it.

[ivy]

if no one has an objection, i plan to land this in the next day or two so we can get some testing (to the extent that anything even uses these functions) and hopefully sneak it into 15.0-BETA3