getting different/wrong MAC address now and then

[jonwaland]

(as you know) I'm using ARPSCAN as part of NetAlertX, and I have now had two occurrences of a partial MAC duplicate.

device mac address is 9c:5a:81:ba:6a:46. But ARPSCAN has also reported it as 9c:5a:91:ba:6a:46 which isn't rec recognized as a valid MAC vendor id

correct:

incorrect:

Unfortunately I wasn't quick enough to see if there was any logging provided. Is this something known about?

[royhills]

The latest IEEE Mac/vendor mapping file from GitHub shows that the vendor name lookup gives the same results. So we can eliminate out of date mapping files and the hash table lookup process.

localhost:~/arp-scan# ls -l ieee-oui.txt 
-rw-r--r--    1 root     root       1649021 Feb 23 10:59 ieee-oui.txt
localhost:~/arp-scan# grep -i 9c5a81 ieee-oui.txt 
9C5A81  Xiaomi Communications Co Ltd
localhost:~/arp-scan# grep -i 9c5a91 ieee-oui.txt 
localhost:~/arp-scan# 

[royhills]

This is an unusual finding that I’ve not observed before, and there has not been any issues logged for it. So thank you for reporting it.

What’s really strange is that it’s the OUI that’s changing, which no network stack should do.

There are two bits that differ between 81 and 91, so it’s not a single bit change:

91 dec = 01011011 binary
81 dec = 01010001 binary 

I’ll give this some thought and will comment later.

[royhills]

You could try running arp-scan directly against the IP of the device in question. Arp-scan allows you to specify the same address multiple times (although this usage is uncommon), for example to run against 10.128.0.1 ten times with 5000ms between requests you could do this (using bash shell):

$ arp-scan $(eval echo {1..10} | sed "s/[[:digit:]]*/10.128.0.1/g") -i 5000
Interface: ens4, type: EN10MB, MAC: 42:01:0a:80:00:04, IPv4: 10.128.0.4
Starting arp-scan 1.10.1-git with 10 hosts (https://github.com/royhills/arp-scan)
10.128.0.1      42:01:0a:80:00:01       (Unknown: locally administered)
10.128.0.1      42:01:0a:80:00:01       (Unknown: locally administered)
10.128.0.1      42:01:0a:80:00:01       (Unknown: locally administered)
10.128.0.1      42:01:0a:80:00:01       (Unknown: locally administered)
10.128.0.1      42:01:0a:80:00:01       (Unknown: locally administered)
10.128.0.1      42:01:0a:80:00:01       (Unknown: locally administered)
10.128.0.1      42:01:0a:80:00:01       (Unknown: locally administered)
10.128.0.1      42:01:0a:80:00:01       (Unknown: locally administered)

9 packets received by filter, 0 packets dropped by kernel
Ending arp-scan 1.10.1-git: 10 hosts scanned in 45.337 seconds (0.22 hosts/sec). 8 responded

Note that only 8 out of the 10 requests results in a response. I’m not sure why this is but I don’t think it affects the result.

This would remove netalertx from the equation and also provide more flexibility for debugging.

[jonwaland]

hmm..

sudo arp-scan $(eval echo {1..100} | sed "s/[[:digit:]]*/192.168.1.177/g") -i 5000
Interface: eno1, type: EN10MB, MAC: 54:b2:03:19:8e:a5, IPv4: 192.168.1.128
Starting arp-scan 1.10.1-git with 100 hosts (https://github.com/royhills/arp-scan)
192.168.1.177   9c:5a:81:ba:6a:46       Xiaomi Communications Co Ltd
[snip]
192.168.1.177   9c:5a:81:ba:6a:46       Xiaomi Communications Co Ltd

473 packets received by filter, 0 packets dropped by kernel
Ending arp-scan 1.10.1-git: 100 hosts scanned in 480.285 seconds (0.21 hosts/sec). 64 responded

I've enabled email notifications on new devices in NetAlertX, so I'll wait and see if I can get an other occurrence.