Andi,
On Mon, Sep 04, 2000 at 10:45:06AM +0200, Andi Kleen wrote:
> On Mon, Sep 04, 2000 at 10:22:42AM +0800, Andrey Savochkin wrote:
> > Andi, there may be two reasons of this behavior:
> > 1. skb that triggered ARP request had a.b.c.1 source, either because
> > a) the socket had been bound to that address, or
> > b) preferred source in the routing table is wrong;
> > 2. the request source address was selected basing on interface address list,
> > and produced a wrong result.
> > I would say that 1b case is the least likely for me.
> > If the reason of this behavior is 1a or 2, it's a kernel bug in my opinion.
>
> The prefered source address is usually 0 in the fib.
I can't say for sure, I never add routing table entries without prefsrc :-)
>
> The problem is likely that ip_route_output_slow() does never passes in the
> daddr into inet_select_addr(), so it does not even have the necessary
> information.
>
> I'm not sure if it is worth fixing though.
Well, let's put aside the preferred source.
What if the application explicitly bound the socket to a.b.c.1?
The ARP request to d.e.f.2 will still have a.b.c.1 as the source.
Do you still think that it's ok?
d.e.f.2 may not have a clue about a.b.c.1 reachable by the same media.
I think that it should be fixed.
>From IP point of view, the configuration where not all nodes are aware of the
topology is not so good, but acceptable and working (using asymmetric path for
different directions). However, this ARP issue make the configuration
completely non-working. Packets just can't go because link-level address
resolution doesn't work.
So, I think that we have to be sure that we use the "best" address for this
destination.
What about an unconditional use of inet_select_addr() or fib_select_addr()
based on prefsrc with inet_select_addr() fallback?
Andrey
This archive was generated by hypermail 2b29 : Thu Sep 07 2000 - 21:00:17 EST