From owner-freebsd-net@FreeBSD.ORG Mon Jul 27 20:14:13 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 AC471106564A for ; Mon, 27 Jul 2009 20:14:13 +0000 (UTC) (envelope-from os@sfedu.ru) Received: from mail.r61.net (mail.r61.net [195.208.245.249]) by mx1.freebsd.org (Postfix) with ESMTP id 282698FC08 for ; Mon, 27 Jul 2009 20:14:12 +0000 (UTC) (envelope-from os@sfedu.ru) Received: from mind.local (os.adsl.r61.net [195.208.243.95]) (authenticated bits=0) by mail.r61.net (8.14.3/8.14.1) with ESMTP id n6RKE8rG023973 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 28 Jul 2009 00:14:09 +0400 (MSD) (envelope-from os@sfedu.ru) X-Authentication-Warning: asterix.r61.net: Host os.adsl.r61.net [195.208.243.95] claimed to be mind.local Message-ID: <4A6E0A8B.5000103@sfedu.ru> Date: Tue, 28 Jul 2009 00:14:03 +0400 From: Oleg Sharoyko User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Julian Elischer References: <1248704237.96833.127.camel@brain.cc.rsu.ru> <4A6DE356.6040006@elischer.org> <4A6DEE30.6000108@sfedu.ru> <4A6DFFA1.1010709@elischer.org> <4A6E0121.2020004@sfedu.ru> <4A6E05EC.8050401@elischer.org> In-Reply-To: <4A6E05EC.8050401@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 20:14:13 -0000 Julian Elischer wrote: > great.. in your simple server, can you do the sockopt on the socket > AFTER you did the listen()? > (just as a test). Doesn't help. I have also tried to add setsockopt() after accept() (for a new socket) and in this case the only packet that is being sent out via wrong interface is the SYN+ACK from server. I'll try to look into the kernel code tomorrow and will report any findings. -- Oleg