Error in Call Home with no ethernet

[macmpi]

Hi,

Noticed the following in journalctl when using volumio on Wifi exclusively (piZero with no ethernet adapter)

volumio[767]: info: Loading plugin "system"...
Jan 13 07:04:52 volumio[767]: { Error: ENOENT: no such file or directory, open '/sys/class/net/eth0/address'
Jan 13 07:04:52 volumio[767]: at Error (native)
Jan 13 07:04:52 volumio[767]: at Object.fs.openSync (fs.js:640:18)
Jan 13 07:04:52 volumio[767]: at Object.fs.readFileSync (fs.js:508:33)
Jan 13 07:04:53 volumio[767]: at ControllerSystem.callHome (/volumio/app/plugins/system_controller/system/index.js:458:20)
Jan 13 07:04:53 volumio[767]: at ControllerSystem.onVolumioStart (/volumio/app/plugins/system_controller/system/index.js:46:7)
Jan 13 07:04:53 volumio[767]: at PluginManager.loadPlugin (/volumio/app/pluginmanager.js:122:19)
Jan 13 07:04:53 volumio[767]: at PluginManager.loadPlugins (/volumio/app/pluginmanager.js:192:10)
Jan 13 07:04:53 volumio[767]: at new CoreCommandRouter (/volumio/app/index.js:45:24)
Jan 13 07:04:53 volumio[767]: at Object.<anonymous> (/volumio/index.js:34:21)
Jan 13 07:04:53 volumio[767]: at Module._compile (module.js:570:32)
Jan 13 07:04:53 volumio[767]: errno: -2,
Jan 13 07:04:53 volumio[767]: code: 'ENOENT',
Jan 13 07:04:53 volumio[767]: syscall: 'open',
Jan 13 07:04:53 volumio[767]: path: '/sys/class/net/eth0/address' }
Jan 13 07:04:53 volumio[767]: info: Loading plugin "appearance"...

Something may need to be adapted around here to get MAC address from primary interface, which may not be ethernet, as piZero may not have one.

Hopefully there are no other assumption of ethernet interface existence in the code.

[xipmix]

There are several places where there are assumptions about interfaces, I have not looked in detail if they are ust reasonable defaults that are later tweaked at runtime.

app/platformSpecific.js
app/plugins/system_controller/network/index.js
app/plugins/system_controller/network/lib/ifconfig.js
app/plugins/system_controller/system/index.js
http/restapi.js

[chsims1]

I think that this is not necessarily related to Volumio. Yesterday I connected a new second RPi0 to my home wifi, and was surprised to see that my router reported it as the original RPi0. So both devices are apparently detected with the same MAC address. I haven't tried connecting both yet, to see what happens :)

[macmpi]

What do you mean by "my router reported it as the original RPi0" : is that the device name? If both have Volumio on it with unchanged name: they just use same name, and router reports it.
Did you incidently used the same wifi dongle? Router could have associated name with wifi dongle MAC too. Or it may depend on DHCP lease.
Anyway I don't think it is related to the original issue.

[chsims1]

I had assigned a name and IP address to a Volumio RPi0 presumably with a particular MAC address. Those properties were assigned to a new RPi0 (without Volumio). It is possible that I used the same wifi adapter, which of course would explain it. I will check later.

Edit: yep, apologies for my mistake. Dongle MAC address.

[macmpi]

@xipmix
Thanks for the quick scan.
I looked at files on live device and they are not tweaked.
ifconfig.js reference to eth0 is inside comments, so no worries on that one.
Others do have more influence.

Ideally Volumio network manager would enumerate available hw ports, and call them based on existence rather than with most assumed names.
This would also allow to setup & configure other type of wired networking ports for instance (usb0 in gadget mode, firewire, etc...).
(hack-ish way in the meantime would be to rename them as per this)

I don't underestimate the work required to enhance in such a way Volumio Network Manager (which may be profound and impact Network Preference UI), and unfortunately, I think I do have the skills to make such changes on my own...

At least with that know limitations, I'd like to make sure eventual errors do not cause instabilities when no eth0 is present.

[xipmix]

It's probably simplest to test for the existence of /sys/class/net/eth0 before probing for the address etc...

Nonetheless I agree with your points above - the assumption that eth0 is always around is one that is not valid and some work to accommodate that needs to be done. Further, if later versions of systemd come along that do away with the 'ethX' naming scheme, then a bit more abstraction is going to be required. To get that right, some kind of written spec for the behaviour is likely to be needed and (heavens!) some test cases for the new code..