`os.networkInterfaces` does not list all interfaces.

[zenoamaro]

Adoption of joyent/node#9029.

os.networkInterfaces() does not list all interfaces, but only those that have addresses, excluding for example an unplugged eth0, which can be surprising.

This happens because os.networkInterfaces is actually implemented in terms of GetInterfaceAddresses which calls into uv_interface_addresses (which among other things filters out everything except AF_INET*) making networkInterfaces a bit of a misnomer for what is basically networkInterfaceAddresses.

Though os is at stability 4 already, this behavior can be a bit unexpected. Perhaps we could correct it somewhat without breaking the API, or at least document it. I can think of a few ways to work this out:

• Leave the method as it is, but document the exceptional behavior in the docs, and leave it to a community module to solve this correctly; or
• Alias it to os.networkInterfaceAddresses, thus reflecting GetInterfaceAddresses and uv_interface_addresses; or
• Implement uv_interfaces and rebase os.networkInterfaces() on that and uv_interface_addresses, preserving the current behavior, but listing all interfaces when given a flag.
  1. yes
  2. os
  3. v0.10, v0.12, v1.0.0

[rvagg]

os.networkInterfaces({ all: true }) wouldn't be a breaking change, I'm +1 for that; not having the ability to list all interfaces is a bit of a handicap for the platform

[bnoordhuis]

It would require a (tedious) update to libuv, however. Tedious because it needs to be applied to all platforms and because it's an API change. Whoever wants to pursue that, please file a libuv issue first so we can hash out the details.

[zenoamaro]

+1 for { all: true } and similar approaches. It's unlikely for networkInterfaces to receive an object with this shape by accident. Conversely, trying to invoke the new behavior on node.js will still return a valid list of interfaces (with down interfaces missing as usual).

I believe libuv would only need a single addition (uv_interfaces and possibly uv_free_interfaces) without changes in existing code. The remaining job of meshing uv_interfaces and uv_interface_addresses together would be entirely done on the io.js bindings. I'll open an issue there and try a POC.

[piranna]

+1 for { all: true }. Until that, what workarounds could be used?

[brendanashworth]

@piranna I don't believe there is a core workaround right now, unless there is an npm module somewhere.

[piranna]

I don't know of any npm module about this... :-(

[Trott]

This issue appears to be dormant and doesn't seem likely to get any traction any time soon because it depends on a significant feature appearing in libuv first. Would it be wrong-headed to close this and open something in nodejs/NG instead?

[Fishrock123]

@Trott Nah, this is still valid IMO. It's the kind of thing that we would add.

[Trott]

Adding blocked label because this can't happen until libuv gets the required feature...

[OndroNR]

As workaround, I used undocumented function findalldevs() in pcap npm package (uses binary libpcap library, which must be present on system). I am using live packet capture from pcap module anyway. As time of writing, npm version did not compile on my system, but git master did.

In this example, at least interface en4 is unplugged.

> const pcap = require('pcap');
undefined
> pcap.findalldevs()
[ { name: 'en0', addresses: [ <1 empty item>, [Object] ] },
  { name: 'awdl0', addresses: [ <1 empty item>, [Object] ] },
  { name: 'bridge0', addresses: [] },
  { name: 'en1', addresses: [] },
  { name: 'en2', addresses: [] },
  { name: 'p2p0', addresses: [] },
  { name: 'en4', addresses: [] },
  { name: 'lo0',
    addresses: [ <1 empty item>, [Object], [Object], [Object], [Object] ],
    flags: 'PCAP_IF_LOOPBACK' } ]

Also Cap looks usable. it still needs libpcap installed, but should work on Windows as well. Edit: just converted my code to Cap as I need Windows support :)

[brtthomp]

Are there any open tickets within libuv currently to keep track of? It would be nice to know if anyone is currently working on this problem.

[cjihrig]

There is https://github.com/libuv/libuv/issues/158. I don't think anyone is actively working on it though.

[ryzokuken]

What's the current status on this? Is anyone working on this/it's libuv counterpart?

/cc @nodejs/libuv @cjihrig

[lundibundi]

@ryzokuken So there is this https://github.com/libuv/libuv/pull/219 old PR which has been superseded by this https://github.com/libuv/libuv/pull/1371 but unfortunately there has been no activity for almost a year now. It seems the implementation pretty much stalled. Edit: ping'ed the author in the PR, let's see, maybe there is a chance.

[ryzokuken]

The upstream PR seems to be stalled, and I attempted to close it. Is this still an issue? We could reformat it so that someone else picks it up.

[antillgrp]

As workaround, I used undocumented function findalldevs() in pcap npm package (uses binary libpcap library, which must be present on system). I am using live packet capture from pcap module anyway. As time of writing, npm version did not compile on my system, but git master did.

In this example, at least interface en4 is unplugged.

> const pcap = require('pcap');
undefined
> pcap.findalldevs()
[ { name: 'en0', addresses: [ <1 empty item>, [Object] ] },
  { name: 'awdl0', addresses: [ <1 empty item>, [Object] ] },
  { name: 'bridge0', addresses: [] },
  { name: 'en1', addresses: [] },
  { name: 'en2', addresses: [] },
  { name: 'p2p0', addresses: [] },
  { name: 'en4', addresses: [] },
  { name: 'lo0',
    addresses: [ <1 empty item>, [Object], [Object], [Object], [Object] ],
    flags: 'PCAP_IF_LOOPBACK' } ]

Also Cap looks usable. it still needs libpcap installed, but should work on Windows as well. Edit: just converted my code to Cap as I need Windows support :)

Any other workaround besides pcap?, I tried npm network which uses wmic but opens a console to run the wmic command.

Why is so hard to have something like this, for node:

https://docs.microsoft.com/en-us/dotnet/api/system.net.networkinformation.networkinterface.getallnetworkinterfaces?view=netframework-4.7.2

[ghost]

5 years and it's still an issue. Workaround is to rely on another npm package or parse ipconfig / ifconfig (or any other network cmd) yourself. Any better ideas?

[Fishrock123]

It seems that no one's gone through the effort to properly land this in libuv?

[jasnell]

Given the lack of engagement on this at the libuv level, and given that the implementation is going to be different per platform, we need to decide if we're ever going to do anything with this request. At this point, deferring to a userland native addon would likely be the better option for the ecosystem as it's not evident that libuv will ever get to it (sadly).

[roychowdhuryrohit-dev]

As workaround, I used undocumented function findalldevs() in pcap npm package (uses binary libpcap library, which must be present on system). I am using live packet capture from pcap module anyway. As time of writing, npm version did not compile on my system, but git master did.

In this example, at least interface en4 is unplugged.

> const pcap = require('pcap');
undefined
> pcap.findalldevs()
[ { name: 'en0', addresses: [ <1 empty item>, [Object] ] },
  { name: 'awdl0', addresses: [ <1 empty item>, [Object] ] },
  { name: 'bridge0', addresses: [] },
  { name: 'en1', addresses: [] },
  { name: 'en2', addresses: [] },
  { name: 'p2p0', addresses: [] },
  { name: 'en4', addresses: [] },
  { name: 'lo0',
    addresses: [ <1 empty item>, [Object], [Object], [Object], [Object] ],
    flags: 'PCAP_IF_LOOPBACK' } ]

Also Cap looks usable. it still needs libpcap installed, but should work on Windows as well. Edit: just converted my code to Cap as I need Windows support :)

None of these solutions could provide me the MAC addresses of each interfaces.

UPDATE: Using node library 'systeminformation' this is possible.

[pprindeville]

None of these solutions could provide me the MAC addresses of each interfaces.

Anything that builds against glibc will have getifaddrs() which gets you everything you need.

https://www.freebsd.org/cgi/man.cgi?getifaddrs

That just leaves Windows needed an odd-man-out (as usual) solution. It's homologue is:

https://docs.microsoft.com/en-us/windows/win32/api/iphlpapi/nf-iphlpapi-getadaptersaddresses

[ShogunPanda]

Since libuv is not working on this and the documentation now clearly states:

Returns an object containing network interfaces that have been assigned a network address.

Shall we just close this?

[pprindeville]

Shall we just close this?

I don't see the point. What if you want to use NodeJS to manage interfaces, including the assignment of addresses, either statically or through DHCP? You'd need to see unprovisioned interfaced so that they might be provisioned.

[ShogunPanda]

I totally agree with you. This is a feature that should exist.

But as there's no support in libuv and neither in glibc (and would love to be wrong, honestly) this cannot be implemented in Node.js core.

Therefore I'm suggesting to close this as a signal for future viewers to look for external solutions (like the one mentioned earlier in this issue) rather than waiting for this to be solved.

WDYT?

[manolopm]

@ShogunPanda, imho, I think you're wrong about glibc.

@pprindeville talked about getifaddrs() and I think it's the way. I take a look to the man page and there is an example that find all interfaces, the interfaces which have an address (family AF_INET or AF_INET6) and the ones without address yet or other low leves interfaces (family AF_PACKET).

I take a look into libuv code and I think there is an explicit filter to the interfaces that aren't in IF_RUNNING state.

If I take the code of the function and put a printf before the if I could see all my network interfaces (such virtualbox, flanel , veth, and so on) that I can't see in node using os.networkInterfaces

This is just my 5 cents, what do you think?

[github-actions[bot]]

There has been no activity on this feature request for 5 months and it is unlikely to be implemented. It will be closed 6 months after the last non-automated comment.

For more information on how the project manages feature requests, please consult the feature request management document.

[piranna]

This feature is still missing, how can we move it forward?

[ShogunPanda]

The problem is to understand if libuv and/or glibly support it. If they don't, there is nothing we can do about it.

[piranna]

Maybe we can implement the missing functionality there...

[github-actions[bot]]

There has been no activity on this feature request for 5 months and it is unlikely to be implemented. It will be closed 6 months after the last non-automated comment.

For more information on how the project manages feature requests, please consult the feature request management document.

[piranna]

This PR has been open for 8 years, and ask for a basic functionality. How can we help to move it forward? There's no npm modules that I know that implement it as an alternative, at least in a sane way...

[bnoordhuis]

The libuv PR (or PRs - I think there were multiple) stalled, repeatedly. Someone would need to revive it but, honestly, I already spent enough time reviewing it. I don't cherish the thought of spending even more of my free time on it.

[ShogunPanda]

@bnoordhuis I agree.

Note for people reading this issue: Unless libuv lands the needed PR we cannot implement this, sorry. :(

[github-actions[bot]]

There has been no activity on this feature request for 5 months and it is unlikely to be implemented. It will be closed 6 months after the last non-automated comment.

For more information on how the project manages feature requests, please consult the feature request management document.

[piranna]

no-stale

[github-actions[bot]]

There has been no activity on this feature request for 5 months and it is unlikely to be implemented. It will be closed 6 months after the last non-automated comment.

For more information on how the project manages feature requests, please consult the feature request management document.

[piranna]

No stale.

[piranna]

This is just my 5 cents, what do you think?

@manolopm I think that since you've find the place it needs to fixed, just try to move in on libuv side, to see if we have more luck there.

[github-actions[bot]]

There has been no activity on this feature request for 5 months. To help maintain relevant open issues, please add the https://github.com/nodejs/node/labels/never-stale label or close this issue if it should be closed. If not, the issue will be automatically closed 6 months after the last non-automated comment. For more information on how the project manages feature requests, please consult the feature request management document.