<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Hi CLUEbies,<br>
    <br>
    I installed arpwatch on a CentOS6 system on a network I manage to
    try to figure out when someone connects something to the network
    that steps on one of the IP addresses of a server.&nbsp; For important
    servers (e.g. iSCSI SAN initiator or target), having an IP conflict
    is Bad.&nbsp; The Arpwatch that comes with CentOS works fine out of the
    box.&nbsp; It maintains an ARP table and notifies me via e-mail whenever
    an IP address changes MAC addresses, among other things.&nbsp; It sends a
    lot of e-mails.<br>
    <br>
    The problem is that frankly I don't care if an IP address in the
    DHCP range changes MAC addresses.&nbsp; DHCP addresses are dynamic and
    it's perfectly fine if another one of these changes MAC addresses.&nbsp;
    There are 150 IPs in this DHCP range which is not a subnet (it does
    not fall on any subnet boundaries).&nbsp; The DHCP IPs are all in the
    same subnet as the rest of the network.&nbsp; I don't want to get an
    e-mail from arpwatch every time something requests and gets an IP
    address, which used to be leased to something else, in the DHCP
    range of IPs.<br>
    <br>
    Does anyone have any great ideas how to do this?&nbsp; This is apparently
    a lot harder than it seems.&nbsp; Here's what I've tried or looked at so
    far:<br>
    <br>
    There seems to be no really good way to get arpwatch to ignore MAC
    changes in a DHCP range.&nbsp; The suggestions I've found when googling
    are:<br>
    <ul>
      <li>Configure the mail-sending program, or the mail-receiving
        program, to filter out messages from arpwatch that match one of
        these IP addresses.&nbsp; This is great, I would only have to
        manually code 150 mail filters, one for each IP.</li>
      <li>Recompile arpwatch, if I could find a usable patch.&nbsp; Even if I
        could, the patch would be huge and ungainly, because it seems
        that a pcap capture filter is required.&nbsp;
        <a class="moz-txt-link-freetext" href="http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=272779">http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=272779</a>&nbsp; This
        might work I suppose, assuming that the pcap_compile function
        will accept a 5,000 character capture filter.<br>
      </li>
    </ul>
    I see that Debian's arpwatch might also have a -z option to exclude
    a subnet.&nbsp; From looking at the code I think that the problem is that
    arpwatch uses libpcap, with a (arp or rarp) capture filter, to do
    its packet capturing.&nbsp; To get pcap to ignore a range of IPs, you
    would wind up with a huge pcap capture filter like this:<br>
    <br>
    (arp or rarp) and not host 192.168.1.100 and not host 192.168.1.101
    and not host 192.168.1.102 and not host 192.168.1.103 and so on and
    so forth ad nauseum.&nbsp; <br>
    <br>
    This ServerFault article shows examples of a big pcap capture filter
    to exclude subnets:
<a class="moz-txt-link-freetext" href="http://serverfault.com/questions/123540/tcpdump-filter-that-excludes-private-ip-traffic">http://serverfault.com/questions/123540/tcpdump-filter-that-excludes-private-ip-traffic</a><br>
    <br>
    Thanks,<br>
    Jim<br>
    <pre class="moz-signature" cols="72">--
Jim Ockers, P.E., P.Eng. (<a class="moz-txt-link-abbreviated" href="mailto:ockers@ockers.net">ockers@ockers.net</a>)
Contact info: <a class="moz-txt-link-freetext" href="http://www.ockers.net/">http://www.ockers.net/</a>
</pre>
  </body>
</html>