get_mac_address returns None if there are no routes on the Linux system

[vlstill]

Describe the bug
If there are no routes on the system, the getmac.get_mac_address() returns None even if there are network interfaces.

This can happen e.g. in testing environments such as virtual machines and or inside Linux network namespaces, but in general in systems not connected to larger networks.

To Reproduce

Tested on Ubuntu 20.04LTS (under root)

$ ip netns add getmac-test
$ ip netns exec getmac-test ip link set dev lo up
$ ip netns exec getmac-test python
>>> import getmac
>>> getmac.get_mac_address() is None
True
>>> exit()
$ ip netns exec getmac-test ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00

Expected behavior
A mac address is returned even without routes set.

System info
(please complete the following information):

• OS name: Ubuntu 20.04LTS
• Python version: 3.8.10

Additional context

none

[GhostofGoes]

Hey Vladimír, thanks for the bug report. Would you mind re-running the same test, with debugging output enabled?

It should be something like this (apologies if it's incorrect syntax, I'm not very familiar with the semantics of ip netns exec):

ip netns exec getmac-test python -m getmac -v -dddd

Also, try the same, with the interface specified manually. This shouldn't be necessary, but I'd like to see if it's at least able to get a MAC.

ip netns exec getmac-test python -m getmac -v -dddd -i lo

[vlstill]

Hi!

The log with debug info: getmac.log

With explicit loopback, it works:

$ ip netns exec getmac-test python -m getmac -v -dddd -i lo
DEBUG    Trying: '_read_sys_iface_file' (to_find: 'lo')
DEBUG    Result: 00:00:00:00:00:00


DEBUG    Raw MAC found: 00:00:00:00:00:00

00:00:00:00:00:00

[GhostofGoes]

Thanks for the log file. Yeah, this is definitely a bug. If no routes are found, the rational behavior would be to fallback to the first non-loopback interface, and if no interfaces are found, then fallback to the loopback interface, if it exists. The program "knows" it exists based on output of ip addr, so it should be selecting it, but isn't.

This may be addressed by the refactor, I'll add a regression test and make sure it is. In the meantime, you can try using the beta release of the refactor:

pip install --pre -U getmac

[GhostofGoes]

Alright, so turns out refactor branch had the same behavior. I partially addressed the issue in this commit: c2e54e5

Due to how getmac works internally, a proper fix will take a significant amount of work. In the interests of getting 0.9.0 released I'm deferring that work to 1.0.0.

[GhostofGoes]

0.9.0 is released that partially fixes this issue

[mark007]

Hi. Various integrations within the homeassistant GitHub project seem to be having issues in its most recent versions, where integrations that use getmac to get the Mac address, are returning None. I wonder is it related to this issue. Forcing the method seems to work as a workaround but it feels wrong to have to force the method.

home-assistant/core#87623

home-assistant/core#87146

[GhostofGoes]

@mark007 Would you mind opening a new issue to track those issues? I think I know the cause and might be able to do a quick fix.

[mark007]

No problem, created here. Thanks a lot.

#83