Hi,
Same problem here.
I think the problem happens when you are running (as root) from a
directory which root does not have the rights to read if your ignore
root's capabilities.
$ ls -ld .
drwx------ 6 foo foo 4096 2 juin 14:35 .
$ sudo strace arp-scan --localnet
[…]
newfstatat(AT_FDCWD, "ieee-oui.txt", 0x7fff8b25d6f0, 0) = -1 EACCES
(Permission non accordée)
openat(AT_FDCWD, "ieee-oui.txt", O_RDONLY) = -1 EACCES (Permission non
accordée)
write(1, "Interface: enp3s0, type: EN10MB,"..., 74Interface: enp3s0,
type: EN10MB, MAC: 94:c6:91:16:00:8d, IPv4: 10.0.0.245
) = 74
write(2, "WARNING: Cannot open MAC/Vendor "..., 69WARNING: Cannot open
MAC/Vendor file ieee-oui.txt: Permission denied
) = 69
newfstatat(AT_FDCWD, "mac-vendor.txt", 0x7fff8b25d6f0, 0) = -1 EACCES
(Permission non accordée)
openat(AT_FDCWD, "mac-vendor.txt", O_RDONLY) = -1 EACCES (Permission non
accordée)
write(2, "WARNING: Cannot open MAC/Vendor "..., 71WARNING: Cannot open
MAC/Vendor file mac-vendor.txt: Permission denied
) = 71
AFAIU, this is because this version of arp-scan explicitly drops root's
capabilities:
$ sudo strace arp-scan --localnet
[…]
capset({version=_LINUX_CAPABILITY_VERSION_3, pid=0}, {effective=0,
permitted=1<<CAP_NET_RAW, inheritable=0}) = 0
prctl(PR_SET_KEEPCAPS, 1) = 0
getuid() = 0
setuid(0) = 0
prctl(PR_SET_KEEPCAPS, 0) = 0
getuid() = 0
capget({version=_LINUX_CAPABILITY_VERSION_3, pid=0}, NULL) = 0
capget({version=_LINUX_CAPABILITY_VERSION_3, pid=0}, {effective=0,
permitted=1<<CAP_NET_RAW, inheritable=0}) = 0
capset({version=_LINUX_CAPABILITY_VERSION_3, pid=0},
{effective=1<<CAP_NET_RAW, permitted=1<<CAP_NET_RAW, inheritable=0}) = 0
[…]
capset({version=_LINUX_CAPABILITY_VERSION_3, pid=0}, {effective=0,
permitted=1<<CAP_NET_RAW, inheritable=0}) = 0
capget({version=_LINUX_CAPABILITY_VERSION_3, pid=0}, NULL) = 0
capset({version=_LINUX_CAPABILITY_VERSION_3, pid=0}, {effective=0,
permitted=0, inheritable=0}) = 0
Changing directory to a directory where access is allowed to
read/execute fixes the issue. Interestingly, arp-scan actually uses the
txt files in /usr as documented but first attempts to read when from the
current directory. When reading from the current directory fails, it
appears it does not event attempts to read them from /usr. In other
words, even if the program does not actually uses any files in the
current working directories, not being able to stat files in the current
orking directotries make this fail.
Regards,
Gabriel
