Arp-scan Frequently Asked Questions
Why does arp-scan need to run as root?
arp-scan needs to access the network at the link layer (Layer 2). To do this, it uses packet socket, BPF or DLPI to send the packets, and libpcap to receive them. Only root can send and receive link layer packets. If you run arp-scan as a normal user, you will receive an error similar to this:
$ arp-scan You need to be root, or arp-scan must be SUID root, to open a link-layer socket. link_open: Operation not permitted
You can either run arp-scan as root, or install it SUID root. Installing arp-scan SUID root may introduce a security risk if it contains exploitable bugs. I am not aware of any such bugs, and I have taken care to avoid them, but there are no guarantees.
It may be possible to use capabilities instead of full root privileges on systems that support them.
Why doesn't arp-scan use libnet to send the packets?
I decided to write my own link-layer send functions rather than use libnet to minimise the number of dependencies. Libnet is not common enough to assume that it will be present on most systems, and I don't want to force the user to install extra software in order to use arp-scan.
By contrast, I have used libpcap for the packet receive functions because it is quite common now and I believe that most potential arp-scan users will already have it installed.
Why doesn't arp-scan use libpcap's pcap_inject() or pcap_sendpacket() to send the packets?
Indeed it could, although libpcap didn't have these functions when I first wrote arp-scan.
But in addition to sending raw packets, my link-layer send functions need to obtain the interface interface MAC address. There does not appear to be a way to do this from libpcap, so there wouldn't be any gain from using the pcap packet send functions if I still need to use my own API specific routines to obtain the MAC address.
I get ERROR: failed to send packet: No buffer space available
This means arp-scan could not send a packet because the output queue for the network interface was full.
This can be caused by trying to use an interface that is down or setting the outgoing bandwidth too high.
Some network card/driver combinations are able to sustain a higher output rate than others, so you may find that one interface may report this error, while running arp-scan with the same parameters on a different interface may not.