Hello,
On Thu, 24 May 2001, Andrey Savochkin wrote:
> > 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.
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.
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).
> > 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.
I always consider the source address announcement as 2nd
part of the problem (the first one is the remote probe filtering).
And the atomicity is needed depending on the way we control both
cases.
> 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 ...'.
Right. But you will see in the other thread that I started
now that I use "ip addr add" with the same end goal: to mark the
local route.
> > 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... :-)
OK, we will try to avoid such things, where possible :)
> [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)
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 :)
> [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.
Yes, see the other thread :)
> Andrey
Regards
--
Julian Anastasov <ja@xxxxxx>
|