From owner-freebsd-stable@FreeBSD.ORG Tue Aug 31 21:44:39 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 69CF51065673 for ; Tue, 31 Aug 2010 21:44:39 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta08.emeryville.ca.mail.comcast.net (qmta08.emeryville.ca.mail.comcast.net [76.96.30.80]) by mx1.freebsd.org (Postfix) with ESMTP id 52BB58FC15 for ; Tue, 31 Aug 2010 21:44:39 +0000 (UTC) Received: from omta21.emeryville.ca.mail.comcast.net ([76.96.30.88]) by qmta08.emeryville.ca.mail.comcast.net with comcast id 105P1f0011u4NiLA89keo7; Tue, 31 Aug 2010 21:44:38 +0000 Received: from koitsu.dyndns.org ([98.248.41.155]) by omta21.emeryville.ca.mail.comcast.net with comcast id 19ke1f0073LrwQ28h9keiL; Tue, 31 Aug 2010 21:44:38 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id E32389B425; Tue, 31 Aug 2010 14:44:37 -0700 (PDT) Date: Tue, 31 Aug 2010 14:44:37 -0700 From: Jeremy Chadwick To: Mike Tancsa Message-ID: <20100831214437.GA81938@icarus.home.lan> References: <201008312102.o7VL2MJr000894@lava.sentex.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201008312102.o7VL2MJr000894@lava.sentex.ca> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@freebsd.org Subject: Re: if_rtdel: error 47 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Aug 2010 21:44:39 -0000 On Tue, Aug 31, 2010 at 05:02:20PM -0400, Mike Tancsa wrote: > On a RELENG_8 box from aug 25th, I started seeing a constant spew of > > Aug 31 00:17:46 gate8 kernel: if_rtdel: error 47 > Aug 31 00:18:29 gate8 kernel: ifa_del_loopback_route: deletion failed > Aug 31 00:18:29 gate8 kernel: if_rtdel: error 3 > Aug 31 00:18:29 gate8 last message repeated 2 times > Aug 31 00:18:37 gate8 kernel: ifa_del_loopback_route: deletion failed > Aug 31 00:18:37 gate8 kernel: if_rtdel: error 3 > Aug 31 00:18:37 gate8 last message repeated 2 times > Aug 31 00:18:38 gate8 kernel: ifa_del_loopback_route: deletion failed > Aug 31 00:18:38 gate8 kernel: if_rtdel: error 3 > Aug 31 00:18:38 gate8 last message repeated 2 times > > What do they mean and how can I find the cause of it ? [...] src/sys/net/if.c 1371 err = rtrequest_fib(RTM_DELETE, rt_key(rt), rt->rt_gateway, 1372 rt_mask(rt), rt->rt_flags|RTF_RNH_LOCKED, 1373 (struct rtentry **) NULL, rt->rt_fibnum); 1374 if (err) { 1375 log(LOG_WARNING, "if_rtdel: error %d\n", err); 1376 } Now looking for return() values in rtrequest_fib(): src/sys/net/route.c 745 int 746 rtrequest_fib(int req, ... 756 if (dst->sa_len == 0) 757 return(EINVAL); ... 764 return rtrequest1_fib(req, &info, ret_nrt, fibnum); 765 } And on to rtrequest1_fib, which has a ton of error conditions which can be returned (some natively, some from other functions like rn_mpath_update(), plus a fun macro in use (senderr)). A lot of this code is #ifdef'd too, based on routing features (FLOWTABLE, RADIX_MPATH) that are defined. Direct values that rtrequest1_fib() returns in whatever circumstance: n/a = 0 = no error EAFNOSUPPORT = 47 = Address family not supported by protocol family EINVAL = 22 = Invalid argument ESRCH = 3 = No such process ENOBUFS = 55 = No buffer space available EEXIST = 17 = File exists EOPNOTSUPP = 45 = Operation not supported Functions that rtrequest1_fib() calls whose error codes are passed directly via return() or senderr: rn_mpath_update() = can return 0 (success) or ESRCH rt_getifa_fib() = can return 0 (success) or 51 (ENETUNREACH) rt_setgate() = can return 0 (success) or ENOBUFS So in summary, your error 47 would be the result of code inside of rtrequest1_fib() itself (someone will need to look at that), while your error 3 could be caused by rtequest1_fib() or rn_mpath_update(). I have no familiarity with this code, so someone familiar with the networking layer will have to help. freebsd-net or freebsd-hackers might be worthwhile. Possibly your machine acts as a forwarding gateway and isn't able to properly route/forward/process certain kinds of packets? -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB |