nmap
Use system ARP cache to help with host discovery
@dmiller-nmap and I were chatting about #92 and he suggested we might consider using a system's ARP cache to help with host discovery. This could help with devices that might ignore our probes because they already responded to another ARP request too recently (not sure how often this actually happens) or that our ARP scan might miss for other reasons. Or maybe it's over wifi or something and the system is just very briefly unavailable do to flaky network. On the other hand, could be a bit confusing that a system could show as "up" briefly due to caching even if it has been unplugged. User might even be scanning it to understand if/why it's not reachable. We might want to look into how long different systems keep ARP cache entries. We could note in the "reason" field why the host was marked up. And we could potentially have an option for avoiding this behavior. Or user could clear their ARP cache before scan if they wanted. Here's some notes from Dan:
One way would be to send the HostGroup through a function that updates the status and MAC address based on the cache before calling ultrascan. ultrascan would presumably not re-scan the ones that are already in a known state. That would probably be the easiest to implement. Another way would be to post-process it after ultrascan is done with discovery, filling in any that we missed. That would allow us to prefer the more up-to-date live result, but fall back on cache in case we missed something. The third approach would be to treat the arp cache as advisory only, and require some positive response to treat the target as up, which would probably mean a separate invocation of ultrascan discovery, probably using the default layer-3 discovery probes instead of ARP. for those "cached but not verified" targets.
