Attached is a patch to solve this problem. Since separate arpwatch instances can be run on the relevant VLAN interfaces, if desired, my solution is simply to ignore all 802.1Q frames. This might not be ideal (what about 802.1p priority-only tags? would these ever occur in an ARP/RARP context?) but it is certainly better than the existing situation.
I am on the fence as to whether this is actually a bug in arpwatch, or rather a problem with libpcap or even the Linux kernel. The problem stems from the way Linux packet filtering and the network stack works; essentially the VLAN tag is not handled the same way across network drivers, with packet filtering being performed at such a low level that the VLAN tag may not even be presented to the filter. This is a problem for libpcap, in the sense that reliable kernel packet filters based on the VLAN tag are consequently impossible, and (unwanted) packets may be returned from other VLANs as in the case for arpwatch. Other packages are also negatively affected, e.g. isc-dhcp-server. Nonetheless, it helps to program defensively and handle the 802.1Q frames explicitly, as I do with this patch. -- Rob Leslie r...@mars.org
0001-Ignore-802.1Q-frames.patch
Description: Binary data
