netdev
[Top] [All Lists]

Re: arpfilter merged, next part?

To: "David S. Miller" <davem@xxxxxxxxxx>
Subject: Re: arpfilter merged, next part?
From: Andrey Savochkin <saw@xxxxxxxxxxxxx>
Date: Sun, 20 May 2001 21:57:19 -0700
Cc: ak@xxxxxx, kuznet@xxxxxxxxxxxxx, Julian Anastasov <uli@xxxxxxxxxxxxxxxxxxxxxx>, netdev@xxxxxxxxxxx
In-reply-to: <200105170437.VAA26847@xxxxxxxxxxxxxxx>; from "David S. Miller" on Wed, May 16, 2001 at 09:37:39PM
References: <200105170437.VAA26847@xxxxxxxxxxxxxxx>
Sender: owner-netdev@xxxxxxxxxxx
Hi,

On Wed, May 16, 2001 at 09:37:39PM -0700, David S. Miller wrote:
> Andrey, what is the status of the hacks you were
> going to work on?  Arpfilter is pushed to Linus as of
> 2.4.5-pre3, and it would be nice to get your stuff into
> 2.4.5 as well.

Here are the patches.

The first one implements selection of IP addresses of ARP requests based on
the routing table.  It allows to eliminate pollution of ARP caches of
neighbors by our local IP addresses for which we don't want to provide our
link-level address.
Additionally, it skips arp filtering mechanism for PACKET_HOST packets, which
was proposed by Alexey, if I remember.

Two comments:
1. I don't completely understand how the current code works for the case
of forwarding of packets and looking up for link-level address of the next
gateway.  Do I get it right that IP source of ARP request will be wrong?
Or I misunderstand what we queue in neigh->arp_queue?
2. The big `if'
        if (arp->ar_op == __constant_htons(ARPOP_REQUEST) &&
            ip_route_input(skb, tip, sip, 0, dev) == 0)
looks suspicious.
If ip_route_input fails (e.g., because rejecting route is installed), we fall
back into just updating of the neighbor state to NUD_REACHABLE.
The packets from this neighbor are rejected.
Is it a good reason to immediately consider it as "reachable"?

The second patch is for Julian.
I understand that the current scheme is not extremely convenient for you.
As you explained, for the configuration
        Source/Gateway - Redirector - Host,
where Redirector and Host has the same IP address and the address isn't
exposed on Host, arp_filter patch requires you to block all IP communications
between Source/Gateway and Host.
If you want to have more filtering abilities, the second patch provides the
first step: a per-rtentry flag no blocking IP communications and disallowing
answering ARP requests.  You just need to add an interface to set this flag
from the userspace, by iproute.

        Andrey

Attachment: arp-filter-src1.patch
Description: Text document

Attachment: arp-filter-access1.patch
Description: Text document

<Prev in Thread] Current Thread [Next in Thread>