Find a better method

[silverwind]

Given

  en0: [ { address: 'x.x.x.x', netmask: '255.255.255.0', family: 'IPv4', internal: false } ],
  vboxnet0: [ { address: 'y.y.y.y', netmask: '255.255.255.0', family: 'IPv4', internal: false } ]

the module will wrongly return the VM interface's address. I think we can do better, maybe by utilizing the machine's routing table to find the default gateway.

[silverwind]

This presents a idea for a new module which obtains the default gateway (en0) and related data like its address. This is something I'd have a personal use case for with node-pcap.

[silverwind]

Or maybe, it's already been done: https://github.com/mh61503891/node-default-network, not sure I like the child_process dependency thought :)

[sindresorhus]

Kinda feels like something Node.js should provide, right?

Like:

en0: [ { default: true, address: 'x.x.x.x', netmask: '255.255.255.0', family: 'IPv4', internal: false } ],

[silverwind]

Totally, in my opinion. Reading up on the topic, it seems Ben wasn't in favor in 2012 and there's node-netroute which looks to be the proper way, but it doesn't support Windows. Maybe it should be brought up again for discussion.

[sindresorhus]

Maybe it should be brought up again for discussion.

Definitely.

[timdp]

Not sure how relevant it is, but I vaguely remember writing code like this myself and having crazy issues with virtual adapters that Windows added for debugging Windows Phone. I don't use Windows for development anymore so I can't reproduce it at this point, but in general, I think Node often just isn't aware of how "internal" an interface really is.

[silverwind]

There's no concept of an "internal" network interface in any OS, but we can somewhat reliably identify such interfaces by them not being the default route target. This would of course break once you introduce VPNs that don't set a default route, but it'd say it's a rare case.

[bugdanov]

Why is it returning the last interface IP instead of the first one ? You mean for some other OS the last one is the one ?

On my machine os.networkInterfaces() returns the output below, and internal-ip returns 172.17.0.1 for ipv4 and fe80::dc93:37ff:fea5:b088 for ipv6, instead of the expected 192.168.1.200 / fe80::76d4:35ff:fe4c:273f

Causing some trouble with castnow: xat/castnow#203

{ lo: 
   [ { address: '127.0.0.1',
       netmask: '255.0.0.0',
       family: 'IPv4',
       mac: '00:00:00:00:00:00',
       internal: true },
     { address: '::1',
       netmask: 'ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff',
       family: 'IPv6',
       mac: '00:00:00:00:00:00',
       scopeid: 0,
       internal: true } ],
  eth0: 
   [ { address: '192.168.1.200',
       netmask: '255.255.255.0',
       family: 'IPv4',
       mac: '74:d4:35:4c:27:3f',
       internal: false },
     { address: 'fe80::76d4:35ff:fe4c:273f',
       netmask: 'ffff:ffff:ffff:ffff::',
       family: 'IPv6',
       mac: '74:d4:35:4c:27:3f',
       scopeid: 2,
       internal: false } ],
  'eth0:1': 
   [ { address: '10.3.0.1',
       netmask: '255.255.255.0',
       family: 'IPv4',
       mac: '70:f2:af:03:00:00',
       internal: false } ],
  docker0: 
   [ { address: '172.17.0.1',
       netmask: '255.255.0.0',
       family: 'IPv4',
       mac: '02:42:37:e8:9b:74',
       internal: false },
     { address: 'fe80::42:37ff:fee8:9b74',
       netmask: 'ffff:ffff:ffff:ffff::',
       family: 'IPv6',
       mac: '02:42:37:e8:9b:74',
       scopeid: 4,
       internal: false } ],
  veth4a10a10: 
   [ { address: 'fe80::d096:c4ff:fe03:de95',
       netmask: 'ffff:ffff:ffff:ffff::',
       family: 'IPv6',
       mac: 'd2:96:c4:03:de:95',
       scopeid: 6,
       internal: false } ],
  vethc75935d: 
   [ { address: 'fe80::dcb4:b8ff:fea6:8bd',
       netmask: 'ffff:ffff:ffff:ffff::',
       family: 'IPv6',
       mac: 'de:b4:b8:a6:08:bd',
       scopeid: 8,
       internal: false } ],
  vethb486c1e: 
   [ { address: 'fe80::d8e3:ff:fe75:c5d6',
       netmask: 'ffff:ffff:ffff:ffff::',
       family: 'IPv6',
       mac: 'da:e3:00:75:c5:d6',
       scopeid: 10,
       internal: false } ],
  veth19625c8: 
   [ { address: 'fe80::d6:dcff:fe8c:257e',
       netmask: 'ffff:ffff:ffff:ffff::',
       family: 'IPv6',
       mac: '02:d6:dc:8c:25:7e',
       scopeid: 12,
       internal: false } ],
  vethc6f5da6: 
   [ { address: 'fe80::b40b:64ff:fecf:8585',
       netmask: 'ffff:ffff:ffff:ffff::',
       family: 'IPv6',
       mac: 'b6:0b:64:cf:85:85',
       scopeid: 14,
       internal: false } ],
  vethf77529e: 
   [ { address: 'fe80::4c49:43ff:fe2a:a9b4',
       netmask: 'ffff:ffff:ffff:ffff::',
       family: 'IPv6',
       mac: '4e:49:43:2a:a9:b4',
       scopeid: 16,
       internal: false } ],
  vethb968eb2: 
   [ { address: 'fe80::dc93:37ff:fea5:b088',
       netmask: 'ffff:ffff:ffff:ffff::',
       family: 'IPv6',
       mac: 'de:93:37:a5:b0:88',
       scopeid: 24,
       internal: false } ] }
> 

[silverwind]

It's pretty much just guesswork right now. The proper fix will come once mh61503891/node-default-network#1 is merged.

[bugdanov]

Before going so far, returning the first address is not the better way ?.. for *nix it looks like it does

[sindresorhus]

Should be fixed in v2.0.0.