netdev
[Top] [All Lists]

Re: arpfilter merged, next part?

To: Julian Anastasov <ja@xxxxxx>
Subject: Re: arpfilter merged, next part?
From: Andrey Savochkin <saw@xxxxxxxxxxxxx>
Date: Thu, 7 Jun 2001 20:45:56 -0400
Cc: "David S. Miller" <davem@xxxxxxxxxx>, ak@xxxxxx, kuznet@xxxxxxxxxxxxx, netdev@xxxxxxxxxxx
In-reply-to: <Pine.LNX.4.30.0105272307540.12611-100000@u.domain.uli>; from "Julian Anastasov" on Sun, May 27, 2001 at 11:34:19PM
References: <20010524175734.A23528@saw.sw.com.sg> <Pine.LNX.4.30.0105272307540.12611-100000@u.domain.uli>
Sender: owner-netdev@xxxxxxxxxxx
Hi,

Sorry that it took so long, I was moving...

On Sun, May 27, 2001 at 11:34:19PM +0000, Julian Anastasov wrote:
> 
> On Thu, 24 May 2001, Andrey Savochkin wrote:
> 
> > You may specify any you IP for rt_src for outgoing routes, just be setting
> > pref_src for them.
> > If you put your shared IP (or omit pref_src), you'll certainly end up with a
> > non-working configuration.
> > Just set pref_src to an address that you want to appear in communications.
> 
>       No, the pref src from the original skb->dst appears as source
> in our probes which is bad in my case. Of course, the preferred
> address to the target (after ip_route_output) is our last chance.

pref_src is an attribute of output routes only.
We get it through rt_src of skb->dst only if skb->dst is the output route.
It was you who pointed out first that the check if it's the output route is
mandatory!

>       In my case, sometimes we try to probe for the nexthop when
> sending IP packets, so in arp_solicit we can see these shared
> addresses in the output route in skb->dst. This is the reason
> I'm adding symmetric flag for the output routes. The scenario is:
> 
> 192.168.0.100: shared
> 10.0.0.1: world client (reachable through nexthop router, i.e. not
> direct client)
> 192.168.0.1: our nexthop router
> 
> The packet:
> 10.0.0.1 -> 192.168.0.100
> 
> Our probe:
> who-has 192.168.0.1 tell 192.168.0.100
>                        ^^^^^^^^^^^^^
> 
> 192.168.0.100 appears as pref src in skb->dst, bad in my case, i.e.
> if we use rt_src from skb->dst. So, we must fallback to the
> preferred src in the route to the target (ip_route_output).

We do fall back in `arp-filter-src2.patch'
after the check if skb->dst is output route.

[snip]
> > Take a peek at
> > ftp://ftp.sw.com.sg/pub/Linux/people/saw/kernel/v2.4/route.generic
> > (it's against 2.4.0)
> 
>       Very good. I looked in the new version. I see that you always
> fallback to the preferred source address to the target in arp_solicit.
> This is good for me :) Not sure what we break, though :)

It's an old code.
The current ideas and the patch that I sent are better.
We need to call ip_route_output sometimes.

        Andrey

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