royhills
commented
3 years ago I think this is the code that is generating the error (it's the only code with the error message "failed to send packet"):
/*
* Send the packet.
*/
if (verbose > 1)
warn_msg("---\tSending packet #%u to host %s tmo %d", he->num_sent,
my_ntoa(he->addr), he->timeout);
if (write_pkt_to_file) {
nsent = write(write_pkt_to_file, buf, buflen);
} else if (!pkt_read_file_flag) {
for (i=0; i<retry_send; i++) {
nsent = pcap_sendpacket(pcap_handle, buf, buflen);
if (nsent >= 0) {
break;
}
if (retry_send_interval > 0) {
sleep(retry_send_interval);
}
}
}
if (nsent < 0)
err_sys("ERROR: failed to send packet");What appears to be happening is that pcap_sendpacket() is returning -1 indicating an error. The "Resource temporarily unavailable" part of the message comes from the system error specified by errno and corresponds to the error code EAGAIN which means that the operation would have blocked but nonblocking operation was requested.
The EAGAIN will be generated by the underlying system call that pcap_sendpacket() calls - probably sendto().
I've never seen this error, but I've never tried using arp-scan on a 10G link. You may be able to get more detail by using strace to see the system calls and return codes. E.g.
# strace -e socket,open,close,send,sendto ./arp-scan --localnet
You could also try running arp-scan under gdb which would allow you to examine variables etc after the error has occurred.
As I've not seen this error before and I don't have access to the hardware that appears to cause it, I'd be interested to determine the cause and hopefully a fix or workaround.
gessel
Running on a linux VM and executing
sudo /usr/sbin/arp-scan -g -r 2 -B 1M 10.0.0.0/8 192.168.0.0/16 169.254.0.0/16 172.16.0.0/12arp-scan sometimes fails withERROR: failed to send packet: Resource temporarily unavailableThis typically happens early in the scan, but not immediately, say after 5-15 hosts are enumerated, but within minutes rather than the 4-5 hours the full scan takes at-B 1M.It seems to be more reliable at lower scan rates, as one would expect from the error, but not reliably so - for example scans completed at
-B 10M(after much less time, of course).Is there some way to make the process robust against this error - there's no indication that fall back does anything and running
-vvvjust generates an unusable amount of data (plus I suspect the hobble of writing to stdio sufficiently slows the process to reduce the risk of barfing).ETH0 is a 10G optical link, so it isn't getting close to saturating the link even at 10M. Also, the system seems quite responsive even at 10M and there's no indication in top that resources are being problematically consumed even at 10M, let alone at 1M.
I tried building master rather than using the distro version - same version number (1.9) so maybe that will help, but I don't see anything referencing this error message.