From owner-freebsd-net@FreeBSD.ORG Sun Aug 24 06:05:33 2008 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 BE832106567B for ; Sun, 24 Aug 2008 06:05:33 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.232]) by mx1.freebsd.org (Postfix) with ESMTP id 86E2A8FC0C for ; Sun, 24 Aug 2008 06:05:33 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so1862888rvf.43 for ; Sat, 23 Aug 2008 23:05:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=GyP2Oc7kJJiMuXVH73VBzg/f+YQWNTjkrCD8DXxR6YQ=; b=vPwWOO/ZLebzscP9mesJvHnqa3w1MpAHkqGlz6HPcp/fkqNQWVSZVmYp6frfO6wgX3 jhjo0kmINnyPrPraAKfyxoyj6Qbb6MLgyv6c+tWUsnuvg0RW0ynPuGGM+jVj42U2eBdL pP+/NH+9Br/p12S0MFVvNFQgdqQxiZK6Z+SBo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=BMZxBvOZuQ8OW/xVjIamKymSfAen/jJ/74whtjnDS6jO1jU0sgzzx9Vr9UfWQUeaJe kBKzek2bLORWfSJ/6FL4/gVhuyGQb9PHbIgZa/9B81l0uOsY84jnL1w7ZqG5RTwkdgZ+ GWyxkYiiWVTJgA97yukp9/cdHwzXSAZdp7bqc= Received: by 10.140.135.19 with SMTP id i19mr1445307rvd.70.1219557933197; Sat, 23 Aug 2008 23:05:33 -0700 (PDT) Received: by 10.141.101.21 with HTTP; Sat, 23 Aug 2008 23:05:33 -0700 (PDT) Message-ID: <3c1674c90808232305s42cc9187k58e195d5092261e1@mail.gmail.com> Date: Sat, 23 Aug 2008 23:05:33 -0700 From: "Kip Macy" Sender: mat.macy@gmail.com To: "Julian Elischer" In-Reply-To: <48B0F8AD.1090601@elischer.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200808221719.m7MHJY25090566@lava.sentex.ca> <20080822191146.T66593@maildrop.int.zabbadoz.net> <200808221922.m7MJMcUN091064@lava.sentex.ca> <3c1674c90808231916l2c92a8e4sae0f191af31b5870@mail.gmail.com> <200808240312.m7O3CZS0098145@lava.sentex.ca> <48B0F722.3050005@elischer.org> <3c1674c90808232255s30a6fce7ma8e081e935a6adbc@mail.gmail.com> <48B0F8AD.1090601@elischer.org> X-Google-Sender-Auth: dfc3fcc510062e69 Cc: "Bjoern A. Zeeb" , Mike Tancsa , freebsd-net@freebsd.org Subject: Re: strange TCP issue on RELENG_7 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: Sun, 24 Aug 2008 06:05:33 -0000 Yes, he has the same issue. -Kip On Sat, Aug 23, 2008 at 10:59 PM, Julian Elischer wrote: > Kip Macy wrote: >> >> On Sat, Aug 23, 2008 at 10:52 PM, Julian Elischer >> wrote: >>> >>> Mike Tancsa wrote: >>>> >>>> At 10:16 PM 8/23/2008, Kip Macy wrote: >>>>> >>>>> Can you help me out a bit with your workload? >>>>> >>>>> tcp_offload_connect(...) needs to determine which interface an address >>>>> corresponds to see if that interface supports TCP offload. The code >>>>> does the exact same thing as ip_output does except it doesn't have the >>>>> inpcb locked (which isn't used as part of the route lookup). >>>> >>>> This is the only RELENG_7 box that I have where it routes tcp packets >>>> asymmetrically, so that sounds like it might be the portion that is >>>> badly >>>> interacting. The server has just one default gateway, which is out em0, >>>> but >>>> clients all over the net will connect to IP addresses aliased on lo0 and >>>> to >>>> the one IP on em1. But all connections exit out em0 other than >>>> connected >>>> routes of course. >>>> >>>> ---Mike >>>> >>>>> Julian has worked in this code most recently, maybe he has some idea >>>>> what is going on. >>>>> >>> huh? wha? I haven't been following this thread.. what's up? >>> >> Julian - see previous e-mails, the arp cache gets messed up as a >> result of calling rtalloc in tcp_offload.c - which is done to >> determine which interface will be used for connection. Any thoughts on >> why it may end up with dozens of bogus entries? >> >> -Kip > > has anyone tried the same scenario on -current? > > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >