On Tue, May 22, 2001 at 11:29:44AM +0300, Julian Anastasov wrote:
> 
> 3. rt is not released after ip_route_output

Yes, it's a bug.

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

Yes, we do.
Checking rt_iif looks like a correct way to do it.

[snip]
> i.e.:
> 
> - is it right to avoid the input routes?

Yes, afaik

> - is rt_src always local in 2.4

For output routes, it is.
It's either a local address or a preffered source from FIB.
We, actually, do not need to bother about whether it's local or not because
it's what administrator explicitly specified as a source for outgoing
packets.
But, nevertheless, preffered sources are currently checked for being local
when the entry is being added.

> - ONLINK

I'm not sure about it.
Providing ONLINK, you only reduce the chances of ip_route_output to succeed
and increase chances to not to send any packet.
If the destination doesn't belong to the directly attached network, something
is wrong, but, well, why not to send the packet if we have it?
The source we select is legal...

A fixed patch is attached.

> > The second patch is for Julian.
[snip]
> 
> 	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.

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

	Andrey