DISCLAIMER: There is no guarantee that anything here is safe to use. Use at your own risk.

Patches for arping I have cooked up.

Some debian packages binary and source, containing all the patches described below.

These patches change vlan tag handling and add options -0 -t -T -S -p -C -u to arping utility from the iputils project.

This patch enables arping to detect when an arp reply is received with a vlan tag. The default behavior is to not accept it as a valid reply. Previously, arping would not detect that the reply was actually from a vlan, possibly a vlan subinterface. To restore default behavior, the -t switch is added to instruct arping to accept tagged replies as valid. The -T switch is added so that you can specify a vlan tag, which by default will 802.1q encapsulate the request as well as ensure that any replies match. To send unencapsulated requests while using the -T switch, the -u switch is also provided. Additionally, this patch adds netlink querying of interfaces to determine which vlan tag may be associated with it. Snippets of code lifted from libpcap and public examples.

This patch changes default behavior of arping. While it may have been less instrusive to flip the meaning of -t, the current behavior is just wrong, albeit, not necessarily arping's fault. You actually have to add code (and plenty of it) to detect that a packet has a tag, and although you have subinterfaces for those tags, linux happily delivers those replies to you on the parent interface as well. Perhaps its a linux bug.

This patch adds the -S switch to arping, which enables strict checking that replies are received on the interface they were sent from. This would also resolve most of the vlan tag handling, but not all potential scenarios. In addition, when used with -T, arping can also accept replies from interfaces tagged with the same vlan as the sending interface.

This patch adds the -C switch to arping, which allows you to instruct arping as to how many valid replies need to be received before exiting with success. Contrast with -f whose behavior is now equivalent to -C1

This patch adds the -0 switch (zero) which instructs arping to use all zeros for the unspecified hardware address in arp requests. Arping by default will continue to use all ones (ff:ff:ff:ff:ff:ff), which is different enough from normal that tcpdump makes note of it.

This patch adds the -p option, which enables specifying what text (or hex values) to use as padding in the ARP packet, up to 384 bytes in length. Ethernet arp packets have some padding due to their quite short length and there is at least one application (I believe VSS) that makes use of it.

Now it would be cool if replies echo'd the padding back (because there really is no good way to ensure that a reply is indeed a reply to your specific request), but I would not bet on it.

Inspiration and some code from the packit utility.