Yesterday, when I needed the tool for catching the unknown MAC addresses, the choice have fallen to arpalert. It provides hooks in the form of external executables for getting the job done on many event types, which I used for reporting new MAC addresses:

newmac.sh

#!/bin/bash -e
 
source /etc/environment
 
# Excerpt from arpalert.conf:
# script launched on each detection
# parameters are:
#  - "mac adress of requestor"
#  - "ip of requestor"
#  - "supp. parm."
#  - "ethernet device listening on"
#  - "type of alert"
#  - optional : "ethernet vendor"
# type of alert:
# 0: ip change
# 1: mac address only detected but not in white list
# 2: mac address in black list
# 3: new mac address
# 4: unauthorized arp request
# 5: abusive number of arp request detected 
# 6: ethernet mac address different from arp mac address
# 7: global flood detection
# 8: new mac address without ip
# 9: mac change
 
mac=${1:-}
ip=${2:-}
supp_parm=${3:-}
eth_dev=${4:-}
alert_type=${5:-}
eth_vendor=${6:-}
 
logger "arpalert event: ${mac} ${ip} ${supp_parm} ${eth_dev} ${alert_type} ${eth_vendor}"

You may need some additional processing if you need more than numeric alert type codes. You can even process arpalert's log (or syslog) with excellent nxlog log processing daemon, which is a different story.

After short configuration edit, the tool was started in daemon mode. What surprised me was that after detecting new MAC, the tool segfaulted:

==> /var/log/syslog <==
Jul  2 20:09:49 dhcp kernel: [ 8212.536872] arpalert[4587]: segfault at 126 ip 00007f7490db3cc0 sp 00007ffe132ba770 error 4 in libc-2.23.so[7f7490d65000+1c0000]

What puzzled me even more that Google had 3 hits, of which zero applied to the issue.

After some consideration and event correlation, it struck me:

chmod +x /etc/arpalert/newmac.sh