Red Hat Bugzilla – Bug 467157
Review Request: arping - ping by ARP
Last modified: 2009-05-22 13:04:12 EDT
Spec URL: http://ispbrasil.com.br/arping/arping.spec
SRPM URL: http://ispbrasil.com.br/arping/arping-2.08-1.fc9.src.rpm
Arping is a util to find out it a specific IP address on the LAN is
'taken' and what MAC address owns it. Sure, you *could* just use
'ping' to find out if it's taken and even if the computer blocks ping
(and everything else) you still get an entry in your ARP cache. But
what if you aren't on a routable net? Or the host blocks ping (all
ICMP even)? Then you're screwed. Or you use arping.
We already ship this as part of iputils. What is the difference in this version?
*** Bug 239470 has been marked as a duplicate of this bug. ***
Looking at the previous submission, it seems that this arping has advantages over th eone in iputils.
What features, and why aren't they in upstream arping? (For something this simple, excessive redundancy seems bad.)
for me there are no reason for duplicate, since the arping from iputils do the same thing.
(In reply to comment #5)
> for me there are no reason for duplicate, since the arping from iputils do the
> same thing.
No problem, just close the bug. Manuel in the other submission said that
there were interesting features, but if he wants it he can submit it ;-)
The main difference [that was interesting for me] is that this version allows arpinging based on MAC address. Unfortunately it does work only under some very specific conditions which made me give up in using it. Or in other words, I lost interest in it. It does not provide anything that I do not already have in nmap.
So should this be closed now? Honestly the only thing I've ever needed arping for is to ping directly to a MAC address (for debugging weird single-segment-multiple-subnet routing problems) so I guess I can see the utility, but the package can't be accepted as long as it conflicts with iputils.
in the other review it was renamed arping-ng. Anyway since there is
nobody willing to submit this package, this should just be closed.
*** This bug has been marked as a duplicate of bug 477971 ***