Repository navigation
os.networkInterfaces() returns wrong MAC addresses #13581
Copy link
Copy link
Closed
Labels
libuvIssues and PRs related to the libuv dependency or the uv binding.Issues and PRs related to the libuv dependency or the uv binding.osIssues and PRs related to the os subsystem.Issues and PRs related to the os subsystem.
Description
- Version: 8.1.0
- Platform: linux
- Subsystem: os
os.networkInterfaces() returns wrong MAC addresses.
Running the following code
console.log('interfaces ####################\n',
require('os').networkInterfaces())
console.log('ip a ####################\n',
require('child_process').execSync('ip a').toString().trim())I get the following output
interfaces ####################
{ 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 } ],
enp3s0f1:
[ { address: '192.168.1.116',
netmask: '255.255.255.0',
family: 'IPv4',
mac: '00:00:00:00:41:00',
internal: false },
{ address: 'fe80::4100:1991:751a:d1aa',
netmask: 'ffff:ffff:ffff:ffff::',
family: 'IPv6',
mac: '00:00:00:00:41:00',
scopeid: 2,
internal: false } ] }
ip a ####################
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: enp3s0f1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 70:4d:7b:3c:16:b0 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.116/24 brd 192.168.1.255 scope global dynamic enp3s0f1
valid_lft 1076sec preferred_lft 1076sec
inet6 fe80::4100:1991:751a:d1aa/64 scope link
valid_lft forever preferred_lft forever
165: wlp2s0mon: <BROADCAST,ALLMULTI,PROMISC,NOTRAILERS,UP,LOWER_UP> mtu 1500 qdisc mq state UNKNOWN group default qlen 1000
link/ieee802.11/radiotap d0:57:7b:0e:93:31 brd ff:ff:ff:ff:ff:ff
This a small tabble with some experiments I did playing with node versions and platforms
| Version | OS | Platform | Output |
|---|---|---|---|
| 8.1.0 | linux | PC | wrong |
| 7.10.0 | linux | RaspberryPi 3 | wrong |
| 4.8.3 | linux | PC | correct |
| 4.4.3 | linux | RaspberryPi 3 | correct |
I'm no expert of nodejs core, but my feeleing is that maybe libuv returns a wrong MAC address... Is it maybe related to libuv/libuv#829 ?
Thanks for your help, and all the hard work you're doing!
Kind regards,
M.
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
libuvIssues and PRs related to the libuv dependency or the uv binding.Issues and PRs related to the libuv dependency or the uv binding.osIssues and PRs related to the os subsystem.Issues and PRs related to the os subsystem.
Activity
unix: fix wrong MAC of uv_interface_address
XadillaX commentedon Jun 10, 2017
I've created a PR for this bug in libuv. After that PR done, we can upgrade libuv in Node.js.
mattbrun commentedon Jun 12, 2017
Thanks a lot!
oxygen commentedon Jun 20, 2017
On CentOS 7.2, node 8.0.0 and every 7.x version I have tried works fine.
However, when switching to node 8.1.0 the MAC addresses are wrong and always begin with 00:00:00:00:xx:xx.
I have reproduced this with two fresh installs in VMware on two different hosts.
Is there any other way I can help with this?
XadillaX commentedon Jun 20, 2017
@oxygen Yes, This bug appears on the newer version of libuv. Node.js 8.x failed because of the updating of libuv. And I've already create a PR to fix this issue on libuv (libuv/libuv#1375). After that PR done, we can upgrade libuv in Node.js.
Maybe you can give some suggest to that PR.
unix: fix wrong MAC of uv_interface_address
targos commentedon Jul 17, 2017
Reopening because the fix only landed in libuv.
XadillaX commentedon Jul 18, 2017
@bnoordhuis Shall I wait for new version of libuv releases, or just patch the bugfix code into Node.js master?
bnoordhuis commentedon Jul 18, 2017
Just wait for the upgrade, we never float libuv patches.
XadillaX commentedon Aug 21, 2017
#14866 will fix this issue. (via libuv/libuv@f1e0fc4)
deps: upgrade libuv to 1.14.1
deps: upgrade libuv to 1.14.1
deps: upgrade libuv to 1.14.1
deps: upgrade libuv to 1.14.1
deps: upgrade libuv to 1.14.1
deps: upgrade libuv to 1.14.1
deps: upgrade libuv to 1.14.1