/proc/sys/net/ipv4/config/eth0/arp_filter not working?

/proc/sys/net/ipv4/config/eth0/arp_filter not working?

[Felix von Leitner]

Hi!

I'm having trouble with the Linux kernel answering ARP requests it
shouldn't answer.

In particular, I have added the IP 10.0.0.23 to lo using ip from
iproute2.  On another machine, I have added the IP 10.0.0.23 to eth0
using ip.  Now, an ARP request from a third machine is answered by both.

According to the documentation I found, the kernel (2.6.0-test11) should
not answer ARP requests for the lo alias if I write 1 to
/proc/sys/net/ipv4/config/eth0/arp_filter, and to be on the safe side, I
also wrote 1 to /proc/sys/net/ipv4/config/lo/arp_filter.  However, the
kernel still answers the ARP requests.

Any takers?

Felix

Re: /proc/sys/net/ipv4/config/eth0/arp_filter not working?

[Jose Luis Domingo Lopez]

On Tuesday, 09 December 2003, at 15:58:47 +0100,
Felix von Leitner wrote:

> Any takers?
> 
For Linux network related questions, please check
linux-net@vger.kernel.org, where Linux networking gurus go more often
than linux-kernel.

Greetings.

-- 
Jose Luis Domingo Lopez
Linux Registered User #189436     Debian Linux Sid (Linux 2.6.0-test10-mm1)

Re: /proc/sys/net/ipv4/config/eth0/arp_filter not working?

[David S. Miller]

On Tue, 9 Dec 2003 15:58:47 +0100
Felix von Leitner <felix-kernel@fefe.de> wrote:

> According to the documentation I found, the kernel (2.6.0-test11) should
> not answer ARP requests for the lo alias if I write 1 to
> /proc/sys/net/ipv4/config/eth0/arp_filter, and to be on the safe side, I
> also wrote 1 to /proc/sys/net/ipv4/config/lo/arp_filter.  However, the
> kernel still answers the ARP requests.

Read the documentation again more clearly:

====================
arp_filter - BOOLEAN
        1 - Allows you to have multiple network interfaces on the same
        subnet, and have the ARPs for each interface be answered
        based on whether or not the kernel would route a packet from
        the ARP'd IP out that interface (therefore you must use source
        based routing for this to work). In other words it allows control
        of which cards (usually 1) will respond to an arp request.
====================

This is telling you that you need to set up your routes correctly
in order for the ARP packets to be filtered the way you want.

The decision to block ARP packets is not just based upon this sysctl
value, it is instead made if this sysctl value is set _AND_ the routes
indicate that we would not use this device for a route to reach that
destination which is trying to be resolved by the ARP request.