-
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
Information about own MAC #40
Comments
Thanks for suggesting this. It makes sense, and is easy to do. Commit 9d62503 includes the interface MAC address in the interface summary output. Does this do what you're looking for? |
Thanks a lot for the quick response! |
Yes, adding the interface IP address would be a good idea. I'll see if there's an easy way to do this on the same "Interface:" line, as I want to avoid adding additional output lines to avoid problems for people who have scripts that parse the output. |
Honestly, I don't see the reason why the scan of a given IP range should exclude yourself if you're in that range. But for compatibility, I'd suggest an additional option (like |
The reason that a scan doesn't include your own IP is a feature / limitation of the ARP protocol, not arp-scan. arp-scan will include all IPs in the range including your own if applicable. But no operating systems I'm aware of will respond to an ARP request where the source and destination and both a local interface. For script processing, the --plain option will disable the header and footer leaving just the scan result lines. I hope that anyone parsing output with a script would use this option, but you never know. |
I wasn't aware of the --plain option, it seems to be relatively new (or rather the version in Debian 9 is too old) and is exactly what I had in mind. Thanks! |
Debian only builds from the last official release, not from the latest git version. I should probably plan for a new release at some point, as there have been many changes since the debian version. I've added the IP address in the latest commit: b6d684f I've also changed the output slightly to ensure it fits on one line. I probably won't include the host's own IP in the output though, as that would go against the spirit of the tool. |
It's a tricky thing with distro package maintainers. Debian 10, which was released two months ago already has 1.9.5. Debian 9, released in 2017, still has version 1.9 (4 years old at the time of release). For CentOS 7 there is an EPEL package of 1.9.2. Don't know about CentOS 8 yet. One last attempt at persuading you: I think I understand the argument about 'the spirit of the tool': you can't actually arp-scan the local machine, so any info about it would be kind of 'fake'. On the other hand, I believe the tool is most often used to show the active devices in the local network, and the local machine is part of this network and is active. For this use case I think it should be acceptable to have an extra switch to include the local info in the output (also with --plain). Anyway, thanks a lot for your time and effort! Wish you all the best! P.S. One more thing I noticed: the documentation link http://www.nta-monitor.com/wiki/ doesn't work any more. It takes you to https://nta.intertek.com/. |
Thanks for your comments. Regarding displaying local machine IP/MAC, arp-scan has this information now (as displayed on the Interface: line). It wouldn't be a problem to add a new switch to display it, so I'll consider this. Regarding the wiki, the comapny NTA Monitor Ltd which used to host the wiki was acquired by Intertek plc in 2018, and the web site got moved. I think I have a backup of the old site, so I just need to look at an appropriate site to host the wiki and update the documentation accordingly. I'm leaving this ticket open for now so I remember these issues when I next visit the arp-scan code. |
Hi Roy, sorry to dig up this old issue, but this feature is something I'm looking for, I'll explain my use case. I have a bit of software that scans the network using arp-scan to find IP addresses associated with a list of mac addresses it knows about. But, I want to test this locally on a single machine without changing the code, but even if I put another interface in the same subnet on the host it never appears in the arp-scan results. I don't think there's any workaround for this ( I've tried a few things ) but thought I'd add fuel for thought with this particular scenario. |
No problem at all. That's why I leave unresolved issues open. One limitation to be aware of is that arp-scan only uses the first IP address on the interface. It's possible to have many IP addresses on one interface with modern kernels. With that limitation in mind I don't think there's any reason why it can't be added if there's actually a use case. I've probably sofened my stance a little now that most of the large long-standing requests have been addressed :-) |
I would actually expect for completeness to have the MAC of the interface used for scanning and its corresponding IP address listed as part of the scan results in cases like --localnet.
In fact this MAC can only be seen using -v -v options.
Is there some special reason this is not included? Could there at least be a switch to include / exclude it with whatever default?
Thanks
Emil
The text was updated successfully, but these errors were encountered: