On Fri, 9 Jun 2000, Andrey Savochkin wrote:
> On Fri, Jun 09, 2000 at 08:57:57AM +0300, Julian Anastasov wrote:
> > > which patch are you speaking about ?
> > I looked it one month ago:
> > ftp://ftp.sw.com.sg/pub/Linux/people/saw/kernel/v2.3/route.generic
> > I see it is not changed from long time ago and I
> > don't know its status. Andrey?
> I haven't added anything radically new. Just ported to to the recent
> kernels. I'm going to merge it into the mainstream kernel, but not right
> now. There is a discussion between me and Alexey Kuznetsov about some points
> of the patch. It hasn't been finished yet because of a lack of time on both
> sides. On the other hand, 2.4.0test isn't the right moment to introduce such
> patches :-)
I want to ask you about arp_solicit. Is
inet_addr_type() going to die? I see it is still used. My
question is: can arp_solicit continue to use
inet_addr_type() as in the current kernel and not to call
fib_local_source()? You still can call fib_select_addr. Is
there a good reason to change it?
By this way we limit the local addresses that we can
announce in our ARP probes. I'm not sure if this will break
something but that will allow addresses not included in the
"local" table not to be announced. This will help to hide
these addresses. But I agree, may be this is a hack. We will
allow to accept locally traffic for more IP addresses but to
send probes with the preferred addresses from the same
logical network defined in the "local" table. For me, there
is this difference: why we should allow all IP addresses
which we treat as local in the incoming traffic to be
treated as local in the outgoing traffic. If we want to use
them as source in the ARP probes we can include them in the
"local" table. Is that sounds reasonable? The user can
select which addresses to hide by not including them in the
"local" table. This is the only difference we can make for
the ARP and the other traffic by using only FIB calls. We
still can talk with this IP, we only change ARP behaviour.
If we don't want to talk IP with these hidden addresses we
can completely remove them from all tables.
Julian Anastasov <uli@xxxxxxxxxxxxxxxxxxxxxx>