netdev
[Top] [All Lists]

Re: arpfilter merged, next part?

To: Andrey Savochkin <saw@xxxxxxxxxxxxx>
Subject: Re: arpfilter merged, next part?
From: Julian Anastasov <ja@xxxxxx>
Date: Tue, 22 May 2001 11:29:44 +0300 (EEST)
Cc: "David S. Miller" <davem@xxxxxxxxxx>, ak@xxxxxx, kuznet@xxxxxxxxxxxxx, netdev@xxxxxxxxxxx
In-reply-to: <Pine.LNX.4.10.10105221009220.23837-300000@xxxxxxxxxxxxxxxxxxxxxx>
Sender: owner-netdev@xxxxxxxxxxx
        Hello,

On Tue, 21 May 2001, Andrey Savochkin wrote:

> Hi,
>
> 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?

        I have the same feeling

> 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"?

3. rt is not released after ip_route_output

4. Do we need to distinguish the input/output routes based on
rt_iif != 0, for example:

        /* Determine source IP for the probing packet. */
        rt = NULL;
        saddr = 0;
        if (skb != NULL) {
                rt = (struct rtable*)skb->dst;
                if (!rt->rt_iif) {
                        /* Is it always local? */
                        saddr = rt->rt_src;
                }
        }
        if (saddr == 0) {
                if (ip_route_output(&rt, target, 0, RTO_ONLINK, dev->ifindex) < 
0)
                        /* Never send probes with 0 source as we used to. */
                        return;
                saddr = rt->rt_src;
                ip_rt_put(rt);
                if (!saddr)
                        return;
        }

i.e.:

- is it right to avoid the input routes?

- is rt_src always local in 2.4

- ONLINK

> 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.

        Filtering by routes is not my dream but give me some days to
think on it (of course this patch #2 is not for 2.4.5, I hope :)).

- In my case control over the announced source in the probe is needed

- RTF_NOARPREPLY: is it for unicast routes only? The filtering isn't
for routes to local (ip_route_input)?

>       Andrey


Regards

--
Julian Anastasov <ja@xxxxxx>


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