From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S262801AbVA1WVg (ORCPT ); Fri, 28 Jan 2005 17:21:36 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262798AbVA1WVf (ORCPT ); Fri, 28 Jan 2005 17:21:35 -0500 Received: from arnor.apana.org.au ([203.14.152.115]:48140 "EHLO arnor.apana.org.au") by vger.kernel.org with ESMTP id S262796AbVA1WVX (ORCPT ); Fri, 28 Jan 2005 17:21:23 -0500 From: Herbert Xu To: wweissmann@gmx.at (Wilfried Weissmann) Subject: Re: multiple neighbour cache tables for AF_INET Cc: linux-kernel@vger.kernel.org, linux-net@vger.kernel.org, davem@davemloft.net, 282492@bugs.debian.org Organization: Core In-Reply-To: <24939.1106917237@www31.gmx.net> X-Newsgroups: apana.lists.os.linux.kernel,apana.lists.os.linux.net User-Agent: tin/1.7.4-20040225 ("Benbecula") (UNIX) (Linux/2.4.27-hx-1-686-smp (i686)) Message-Id: Date: Sat, 29 Jan 2005 09:19:49 +1100 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Wilfried Weissmann wrote: > > The kernels 2.4.28+ and 2.6.9+ with IPv4 and ATM-CLIP enabled have bugs in > the neighbour cache code. neigh_delete() and neigh_add() only work properly > if one cache table per address family exist. After ATM-CLIP installed a > second cache table for AF_INET, neigh_delete() and neigh_add() only examine > the first table (the ATM-CLIP table if IPv4 and ATM-CLIP are compiled into > the kernel). neigh_dump_info() is also affected if the neigh_dump_table() > call fails. Indeed, this has been the case for a very long time. IMHO you need to give the user a way to specify which table they want to operate on. If they don't specify one, then the current behaviour of choosing the first table found is reasonble. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt