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, 24 May 2001 17:57:34 -0700
Cc: "David S. Miller" <davem@xxxxxxxxxx>, ak@xxxxxx, kuznet@xxxxxxxxxxxxx, netdev@xxxxxxxxxxx
In-reply-to: <Pine.LNX.4.10.10105231121570.1499-100000@l>; from "Julian Anastasov" on Wed, May 23, 2001 at 12:45:21PM
References: <20010522214540.A17295@xxxxxxxxxxxxx> <Pine.LNX.4.10.10105231121570.1499-100000@l>
Sender: owner-netdev@xxxxxxxxxxx
Hi,

On Wed, May 23, 2001 at 12:45:21PM +0300, Julian Anastasov wrote:
> 
> On Tue, 22 May 2001, Andrey Savochkin wrote:
> 
> > >   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
> >
> > You already have it, it's preferred source in your routes.
> 
>       Not always, I assume in my case the current rt_src will be used
> which is in fact the same shared IP (it is local and can appear in rt_src

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.

> before arp_solicit), may be we will not reach this ip_route_output that
> we are adding now. But I'll make some tests with #2 soon.
> 
> > > - RTF_NOARPREPLY: is it for unicast routes only? The filtering isn't
> > > for routes to local (ip_route_input)?
> >
> > I don't understand you well.
> > RTF_NOARPREPLY is for local routes.
> 
>       Yes, the flag usage in arp.c is right but why it is defined in
> include/linux/route.h where UNICAST routes only are created (I'm
> looking in fib_semantics.c:fib_convert_rtentry). Is the flag for the
> "route" command or for "ip route"?

I meant it as a flag to be added to "ip route".
"route" command operates in a dream world, and doesn't have a clue about real
routing tables.

> > Generally, receiving arp request we check if it's for our local address (by
> > that ip_route_input).
> > We ammend this check by additional one, whether ARP replies are disabled for
> > this local address or not.
> 
>       So, do I need something like this (and flag in another .h file)?:
> 
> ip route change table local local 10.0.0.1 dev eth0 noarpreply

Kind of it, only I would use `ip route add'.

>       Not an atomic operation but anyway. I'll be very happy if this

I don't really understand what kind of atomicity you speak about.
What races to you expect.
And, in any case, if you _create_ the route with the appropriate flag, it's
clean.
Just set this local address not through an additional layer (`ip addr add'),
but directly, by `ip route add local ...'.

> flag is applied automatically to the IFF_LOOPBACK interface(s) for

I hate all automatic actions :-)
You have all the tools that you need.
Each operation using proper tools is a single change in the kernel
structures, with well-defined consequences.
I hope that this world can live without magic for a little bit longer... :-)

[snip]
>       Currently, due to the fixed priority 0 of the local table it seems
> I can't add these addresses to table local if I need to apply different
> behavior (drop/reply) for some requestors. And Alexey claims it is very
> bad to add local addresses that are not in the local table due to many
> dark places in the net/ code. We found, for example, one case with
> icmp_send that is not very helpful with local addresses not in the
> local table. It seems the net code is not very ready for such games.

It looks that I've spotted all (or almost all) such placed and have fixed it.
At least, I have computers with local routes not in the local table (and the
routes are not /32, of course), and it works.
Take a peek at
ftp://ftp.sw.com.sg/pub/Linux/people/saw/kernel/v2.4/route.generic
(it's against 2.4.0)

[snip]
>       And I have to test the arp_solicit support for my case. I'm
> not sure if it is solved with patch #1.

Let me know if it's fine for you.

        Andrey

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