include, misc: Add net interface API.

[apaprocki]

Building on the work done by @zenoamaro, per +1'd approach laid out in #219, this PR lands the new interface without modifying any existing code to depend on it. All platforms return -ENOTSUP initially and the test driver skips the test if -ENOTSUP is returned. Once all platforms have been implemented in subsequent PRs, the test will change to be required and the documentation note will be removed and existing code such as uv_interface_addresses can then change to rely on the new API.

CC: @bnoordhuis @saghul

[apaprocki]

@bnoordhuis Should anyone else be pulled in on this? Or is it okay to move forward with this and start opening up PRs for the individual platform support?

[zenoamaro]

I am ok with this. In retrospect, it should have been this way from the beginning 👍

[saghul]

I think I'd rather have it for v2, that is, targeted at master. If this is to replace the old API we can remove it there.

WDYT?

[bnoordhuis]

It's useful enough IMO that I'd be okay with targeting v1. I'll review the code.

[bnoordhuis]

@apaprocki @zenoamaro Are you still interested in pursuing this?

[apaprocki]

@bnoordhuis Yes, just haven't had the time to loopback (ha ha) to this.

[cwalther]

If the plan is still to eventually implement uv_interface_addresses() in terms of the new uv_network_interfaces(), then I would like to hear your opinion on nodejs/node#14977, because if it is considered worth including, the required additional fields could be added to the uv_network_interface_t struct before it is declared immutable ABI. (There is still the ABI break of adding them to uv_interface_address_t, but I would rather have one ABI break than two.)

[lundibundi]

@apaprocki what's the status of this, do you plan to continue this PR?

[pprindeville]

Don't know if this PR is still in play or not (after 18 months), but here are some suggestions...

[pprindeville]

Given that the domain of i is positive numbers, I'd make this an unsigned here and elsewhere below.

I'd do the same for count.

[apaprocki]

@pprindeville I preserved the same API semantics as the other existing platform APIs. This also allows the new functions to plug right into the existing test driver without declaring a new variable. I'm open to changing this, but not sure why this one API should differ from the others.

[ryzokuken]

Closing the PR because it seems to be stalled. Feel free to reopen if anyone wants to continue working on this.

[ryzokuken]

Oops, this is libuv, and I'm not a collaborator 😅 Weird how we take things for granted.

@cjihrig help?

[apaprocki]

@bnoordhuis I had time to revisit this and I changed a lot of it...

• Changed the struct to use a bitmask as you suggested, with macro accessors for the flags
• Support up to 16-byte physical addresses and dynamically print out whatever is reported
• Stop storing netmask values directly and instead compute the CIDR prefix and only render it to a netmask address for IPv4 addresses

A lot of this is still opinionated, so please re-review and let me know what direction it should take. I test implemented the BSD version of this on my Mac and verified it works as expected:

e.g.

#   name: lo0
#     running: 1
#     is_loopback: 1
#     is_point_to_point: 0
#     is_promiscuous: 0
#     has_broadcast: 0
#     has_multicast: 1
#     address: inet6 ::1/128
#   name: lo0
#     running: 1
#     is_loopback: 1
#     is_point_to_point: 0
#     is_promiscuous: 0
#     has_broadcast: 0
#     has_multicast: 1
#     address: inet6 fe80::1/64
#   name: en0
#     running: 1
#     is_loopback: 0
#     is_point_to_point: 0
#     is_promiscuous: 0
#     has_broadcast: 1
#     has_multicast: 1
#     address: inet6 fe80::16:900f:XXXX:XXXX/64
#     physical address: XX:XX:XX:XX:XX:XX
#   name: en0
#     running: 1
#     is_loopback: 0
#     is_point_to_point: 0
#     is_promiscuous: 0
#     has_broadcast: 1
#     has_multicast: 1
#     address: inet4 192.168.X.X
#     netmask: inet4 255.255.255.255
#     physical address: XX:XX:XX:XX:XX:XX
#   name: utun0
#     running: 1
#     is_loopback: 0
#     is_point_to_point: 1
#     is_promiscuous: 0
#     has_broadcast: 0
#     has_multicast: 1
#     address: inet6 fe80::8fcc:XXXX:XXXX:XXXX/64

[apaprocki]

@bnoordhuis I rebased this again. I think if there's actually a v2 in the works, it would be good to include the new API if this is desired.

[cwalther]

Any opinion on including the TEMPORARY flag and valid_lifetime and preferred_lifetime fields from nodejs/node#14977?
(https://gitlab.indel.ch/indel-public/network-interfaces-plus/commit/d71e37d34e8154d471737fdb69757b6ebb723e9c, https://gitlab.indel.ch/indel-public/network-interfaces-plus/commit/3aefe92b920f5853c72312d2afc09a26d5ab2198)

[pprindeville]

Is there any progress on this?

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[ShogunPanda]

Hello! In Node.js we'd like to have this in order to close nodejs/node#498.
Do you have any plan to implement this? Do you need any help?

[piranna]

How can we get this move forward? This has been blocked on Node.js since more than 5 years ago...