GhostofGoes
Raspberry pi, calling get_mac_address("localhost") or with your local hosts ip doesn't return correct value
On a Raspberry Pi, I'm looping around my subnet and when it gets to its own ip address, it doesn't return anything. You get 'none'.
using get_mac_address with either 'ip="your ip address"' or 'hostname="localhost"' doesn't return expected mac address. You get 'none' or '00:00:00:00:00:00'. Working fine for other ip addresses on the network.
pi@pi4-4:/home/linux $ ifconfig eth0
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.1.209 netmask 255.255.255.0 broadcast 192.168.1.255
inet6 fe80::6718:7e65:ae4f:c8a5 prefixlen 64 scopeid 0x20
inet6 2a00:23c5:af97:1f01:2f15:c490:9da1:ddbd prefixlen 64 scopeid 0x0
pi@pi4-4:/home/linux $ python Python 2.7.16 (default, Apr 6 2019, 01:42:57) [GCC 8.2.0] on linux2 Type "help", "copyright", "credits" or "license" for more information.
from getmac import get_mac_address print get_mac_address(ip="192.168.1.209") None print get_mac_address(hostname="localhost") 00:00:00:00:00:00 print get_mac_address(hostname="pi4-4") None print get_mac_address() dc:a6:32:09:bf:45 print get_mac_address(ip="192.168.1.131") b8:27:eb:05:eb:64
I'd expect it to return the same thing as calling get_mac_address().
Raspberry Pi 4B, running Duster.
I also tried it on python3, but it just doesn't seem to work for me at all :-
pi@pi4-4:/home/linux $ python3 Python 3.7.3 (default, Apr 3 2019, 05:39:12) [GCC 8.2.0] on linux Type "help", "copyright", "credits" or "license" for more information.
from getmac import get_mac_address print get_mac_address(ip="192.168.1.209") File "
", line 1 print get_mac_address(ip="192.168.1.209") ^ SyntaxError: invalid syntax print get_mac_address() File " ", line 1 print get_mac_address() ^ SyntaxError: invalid syntax
and just importing the whole module :-
pi@pi4-4:/home/linux $ python3 Python 3.7.3 (default, Apr 3 2019, 05:39:12) [GCC 8.2.0] on linux Type "help", "copyright", "credits" or "license" for more information.
from getmac import getmac print get_mac_address(ip="192.168.1.209") File "
", line 1 print get_mac_address(ip="192.168.1.209") ^ SyntaxError: invalid syntax
What version of getmac are you using? If you're not using the latest (0.8.1), try that. Upgrade using: python -m pip install -U getmac
Otherwise, can you run the following commands and post the output of each:
python -m getmac -v -dddd --ip 192.168.1.209
python -m getmac -v -dddd --hostname localhost
By the way, you have to use print(stuff) instead of print stuff in Python 3, that's why it's not working in 3 ;)
Hi,
I'm using 0.8.1 :-
pi@pi4-4:/home/linux/software $ getmac --version getmac 0.8.1
and the output from the 2 debug commands :-
`pi@pi4-4:/home/linux/software $ python -m getmac -v -dddd --ip 192.168.1.209 DEBUG Trying: '_read_arp_file' (to_find: '192.168.1.209') DEBUG Result: None
DEBUG Trying: '
DEBUG Trying: 'arp 192.168.1.209' DEBUG Running: '/usr/sbin/arp 192.168.1.209' DEBUG Output from '/usr/sbin/arp' command: 192.168.1.209 (192.168.1.209) -- no entry
DEBUG Result: None
DEBUG Trying: 'arp -an' DEBUG Running: '/usr/sbin/arp -an' DEBUG Output from '/usr/sbin/arp' command: ? (192.168.1.85) at 24:5e:be:23:7e:c9 [ether] on eth0 ? (192.168.1.86) at 7a:1f:29:e4:ac:5a [ether] on eth0 ? (192.168.1.254) at 4c:1b:86:b4:ef:ae [ether] on eth0 ? (192.168.1.81) at 0e:fc:e0:14:e2:f2 [ether] on eth0
DEBUG Result: None
DEBUG Trying: 'arp -an 192.168.1.209' DEBUG Running: '/usr/sbin/arp -an 192.168.1.209' DEBUG Output from '/usr/sbin/arp' command: arp: in 4 entries no match found.
DEBUG Result: None
DEBUG Trying: 'arp 192.168.1.209' DEBUG Running: '/usr/sbin/arp 192.168.1.209' DEBUG Output from '/usr/sbin/arp' command: 192.168.1.209 (192.168.1.209) -- no entry
DEBUG Result: None
DEBUG Trying: 'arp -a' DEBUG Running: '/usr/sbin/arp -a' DEBUG Output from '/usr/sbin/arp' command: ? (192.168.1.85) at 24:5e:be:23:7e:c9 [ether] on eth0 ? (192.168.1.86) at 7a:1f:29:e4:ac:5a [ether] on eth0 ? (192.168.1.254) at 4c:1b:86:b4:ef:ae [ether] on eth0 ? (192.168.1.81) at 0e:fc:e0:14:e2:f2 [ether] on eth0
DEBUG Result: None
DEBUG Trying: 'arp -a 192.168.1.209' DEBUG Running: '/usr/sbin/arp -a 192.168.1.209' DEBUG Output from '/usr/sbin/arp' command: arp: in 4 entries no match found.
DEBUG Result: None
DEBUG Trying: '_uuid_ip' (to_find: '192.168.1.209') DEBUG Result: None
DEBUG Raw MAC found: None ` and
pi@pi4-4:/home/linux/software $ python -m getmac -v -dddd --hostname localhost 00:00:00:00:00:00
It looks to me, that because /sbin/ip doesn't find it, things don't work and it doesn't know that it is looking for itself. My suggested fix. Just document that this is what it does when looking at your own ip address.
and the debug for getmac with no options :-
`pi@pi4-4:/home/linux/software $ python -m getmac -v -dddd DEBUG Trying: '_get_default_iface_linux' (to_find: 'None') DEBUG Result: eth0
DEBUG Trying: '_read_sys_iface_file' (to_find: 'eth0') DEBUG Result: dc:a6:32:09:bf:45
DEBUG Raw MAC found: dc:a6:32:09:bf:45
dc:a6:32:09:bf:45 `
Huh, yeah, it's not working under Linux, just Windows. It's something that I thought was working and definitely should work, but isn't. Unfortunately, at first glance I don't see an quick way to fix this on Linux, so it may be a while.
Will document it as a known issue for now, and keep this issue open to track it.
Thank you for the (very helpful) report, and sorry it isn't working.
That's fine for me. Just took me a little while to figure out what it was doing.
Potential workaround for now may be to use netifaces to enumerate the IPs of the locally connected interfaces, then call get_mac_address with the name of the interface that has the IP.
I was running into this exact issue, but I can't afford the netifaces dependency. I've come up with a python solution that's been working for me:
import subprocess
from getmac import get_mac_address
def get_interface_from_local_ip(ip_address:str) -> str:
interfaces = subprocess.run(['ip', '-br', 'address'], stdout=subprocess.PIPE)
interfaces = interfaces.stdout.decode('utf-8').split('\n')
for interface in interfaces:
if ip_address in interface:
return interface.split(' ')[0]
def get_linux_mac_from_local_ip(ip_address: str) -> str:
interface = get_interface_from_local_ip(ip_address)
if interface:
return get_mac_address(interface)
I was running into this exact issue, but I can't afford the
netifacesdependency. I've come up with a python solution that's been working for me:import subprocess from getmac import get_mac_address def get_interface_from_local_ip(ip_address:str) -> str: interfaces = subprocess.run(['ip', '-br', 'address'], stdout=subprocess.PIPE) interfaces = interfaces.stdout.decode('utf-8').split('\n') for interface in interfaces: if ip_address in interface: return interface.split(' ')[0] def get_linux_mac_from_local_ip(ip_address: str) -> str: interface = get_interface_from_local_ip(ip_address) if interface: return get_mac_address(interface)
What distros does this run on? Would love to integrate it if you can provide a sample for the tests.
I'm working with Ubuntu 20.04 at the moment, but the iproute2 utility this is based around dates back to Linux 2.2. I'm happy to test back to the Linux distros and versions you list in the readme when I get some time this week.
Also happy to provide a sample for testing. Can you point me to an example of a sample? I'm not exactly sure what you are asking for.
I'm working with Ubuntu 20.04 at the moment, but the
iproute2utility this is based around dates back to Linux 2.2. I'm happy to test back to the Linux distros and versions you list in the readme when I get some time this week.Also happy to provide a sample for testing. Can you point me to an example of a sample? I'm not exactly sure what you are asking for.
Great, whatever you can contribute would be fantastic. I've been meaning to put more time to this project, just have had a lot going on lately.
A sample is just a dump of the command output on a system that we can use to test against. Here's an example of a sample: https://github.com/GhostofGoes/getmac/blob/master/tests/samples/ubuntu_18.04/ip_link.out
This issue was likely resolved as part of the rewrite for 0.9.0 or will be resolved with 1.0.0. If you're still having this issue with 0.9.4, please feel free to re-open the issue and include debugging output from the new version.