Dear Maintainer,

When I run arp-scan with the default parameters, I get a warning with
the text:

But if you explicitly specify the options
"--ouifile=/usr/share/arp-scan/ieee-oui.txt"
and
"--macfile=/etc/arp-scan/mac-vendor.txt"
with the required files, then the scanning goes fine.

I assume that there are wrong characters in the file paths.

When I ran arp-scan in the /tmp or /root directories, it worked without
error. When I ran arp-scan in the /home/* directories, this error
occurred.

Hi,

I tried to reproduce this issue but I was not able to do so. Could you
please provide more information on how to reproduce this issue?

In addition there is a certain disagreement between the bug title and
the warning message: The title says that the files cannot be found while
the warning indicates that the cause is a permission issue.

Best regards

Peter

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