-
Notifications
You must be signed in to change notification settings - Fork 156
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
many hosts respond to single arp packet #176
Comments
Version 1.9.7 is very old now and you should upgrade to the latest version. I'm guessing you're running an old debian stable or ubuntu LTS? The latest Debian/Ubuntu LTS versions should have packages for version 1.10.0. I think the problem you are seeing is the same as in this issue: #67, which was fixed in version 1.9.8.
arp-scan defaults to 2 milliseconds between outgoing ARP requests giving a rate of 500 packets per second and a bandwidth of 256Kbit/sec (the ARP request packets are 64 bytes long). You can control the outgoing ARP request packet rate with the arp-scan's default of 256Kb/s is only 0.0256% of a gigabit Ethernet or 0.256% of 100Mbit which I wouldn't expect to cause an issue, but if it's reproducible then it is worth investigating. Some initial thoughts:
|
I did not realize how aged that version is - it keeps surprising me, how poorly some distros maintain their packages... my host is running
as it's being installed for use with pi.alert and pi-hole.
Yes, I saw your extensive explanation on the readme (excellent documentation, by the way!) and tried to adjust some intervals or bandwidth settings, while that did not make any difference going to negligible values though. It appears as though some "mirror" effects kick in and multiply the few packets send out by non-addressed hosts. I would call it an avalanche that can be initiated with just a few arp packets.
Yes, Zyxel hardware managed through Nebula. There are some limited points of information, a blunt message hinting on a detected broadcast storm at the switch. The AP merely become non-responsive at some point.
I did not have storm control enabled on the access port which connects to the RPi, then I turned that on and set it to a level of 100 pckts. Will turn it off again. The AP do not show any option for storm control. Next, I will try to get my hands on latest version arp-scan, which will probably take ages to compile on the rpi. |
I think the issue is that the version of raspbian is based on debian 11 "Bullseye". Debian 12 "bookworm" includes arp-scan version 1.10.0. The latest version of rasperry pi os is based on Debian bookworm so should have arp-scan version 1.10.0.
Capturing packets with e.g.
Only the ARP requests that are sent by arp-scan should be broadcast packets. ARP responses should be unicast directed back to the requesting address, and arp-scan should not be sending ARP requests more frequently than specified with
It shouldn't take very long - it's just a small C program. |
Issue #178 is another duplicate ARP response issue. This may be a seperate issue, but I am mentioning it in case there is a connection. |
As described in the wiki on duplicate arp replies, I have observed many repeated replies on my network due to ARP scans. This is not limited to running the scan from a specific host, I have seen the exact same happening when using the Fing app on my phone, arp-scan on a RPi, and on any other linux client accordingly.
Here are some examples of scans with very limited number of hosts to scan for, but the time it takes is ridiculously high.
Scan of 3 hosts with interval of 20ms, which should only take 1,16s consumes more than a minute.
Returning to defaults still consumes approx 6s
Furthermore, if the complete
localnet
is to be scanned, a broadcast storm will be detected causing shutdown of network traffic to the host running arp-scan, while also leaving critical network components non-responsive, e.g., access points.What could be the cause of this? We can try and investigate on my network maybe a bit more, this is 100% reproducible.
The text was updated successfully, but these errors were encountered: