From owner-freebsd-net@FreeBSD.ORG Mon Jul 27 19:52:39 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6AB4C106566C for ; Mon, 27 Jul 2009 19:52:39 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outQ.internet-mail-service.net (outq.internet-mail-service.net [216.240.47.240]) by mx1.freebsd.org (Postfix) with ESMTP id 522148FC08 for ; Mon, 27 Jul 2009 19:52:39 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id 2D95D2324; Mon, 27 Jul 2009 12:52:39 -0700 (PDT) X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id C9E4A2D6022; Mon, 27 Jul 2009 12:52:38 -0700 (PDT) Message-ID: <4A6E058A.6060004@elischer.org> Date: Mon, 27 Jul 2009 12:52:42 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Oleg Sharoyko References: <1248704237.96833.127.camel@brain.cc.rsu.ru> <4A6DE356.6040006@elischer.org> <4A6DEE30.6000108@sfedu.ru> <4A6DFFA1.1010709@elischer.org> In-Reply-To: <4A6DFFA1.1010709@elischer.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Wrong outgoing interface with multiple routing tables X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2009 19:52:39 -0000 So there are two possible ways a daemon might assign a fib to a socket that it is accepting: 1/ the accept socket could take the FIB of the process. 2/ the accept socket could take the fib of the incoming SYN packet. I chose #1, but it is possible something in changes between 6 and 7 broke the "chain of custody" for the fib. This code is in production in 6.x based systems but was only introduced to FreeBSD in 7.x. The process makes a socket which inherits the fib from it. The socket includes an INET PCB (Protocol Control Block) which gets a copy too.. when "listen() is called and a syn comes in, a new entry is made in the syncache code and this includes a new connection block which is supposed to inherrit the fib number from the originating listen socket. Eventually a new socket is created and it is supposed to inherit teh fibnum from the syncache entry, and to copy it to the inpcb attached to it. It's possible that somewhere this has been broken by changes. but I don't see it right at the moment.