From owner-freebsd-current@FreeBSD.ORG  Sun May 11 19:07:43 2008
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Delivered-To: freebsd-current@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id D51EB106567A
	for <freebsd-current@freebsd.org>; Sun, 11 May 2008 19:07:43 +0000 (UTC)
	(envelope-from dillon@apollo.backplane.com)
Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2])
	by mx1.freebsd.org (Postfix) with ESMTP id AC3898FC26
	for <freebsd-current@freebsd.org>; Sun, 11 May 2008 19:07:43 +0000 (UTC)
	(envelope-from dillon@apollo.backplane.com)
Received: from apollo.backplane.com (localhost [127.0.0.1])
	by apollo.backplane.com (8.14.1/8.14.1) with ESMTP id m4BJ7c94005448;
	Sun, 11 May 2008 12:07:41 -0700 (PDT)
Received: (from dillon@localhost)
	by apollo.backplane.com (8.14.1/8.13.4/Submit) id m4BJ7YE7005447;
	Sun, 11 May 2008 12:07:34 -0700 (PDT)
Date: Sun, 11 May 2008 12:07:34 -0700 (PDT)
From: Matthew Dillon <dillon@apollo.backplane.com>
Message-Id: <200805111907.m4BJ7YE7005447@apollo.backplane.com>
To: Bakul Shah <bakul@bitblocks.com>
References: <20080511070708.A1AF05B4D@mail.bitblocks.com>
Cc: freebsd-current@freebsd.org, Julian Elischer <julian@elischer.org>
Subject: Re: tcp over slow links broken? 
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Discussions about the use of FreeBSD-current
	<freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>, 
	<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
	<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sun, 11 May 2008 19:07:43 -0000


:On Sat, 10 May 2008 23:33:56 PDT Julian Elischer <julian@elischer.org>  wrote:
:> Bakul Shah wrote:
:...
:> 
:> that is just plain  wierd...  B seems to have gone deaf.
:
:Yup! As if the wrong segment is being queued up.

    Hmm.  It looks like C has gone deaf, not B.  B is retransmitting from
    sequence 4744 which is the last sequence that C acked.  C is then not
    acking any further packets.

14:22:42.411144 IP B.55535 > C.ssh: . 7664:9124(1460) ack 2016 win 65535
14:22:42.411259 IP B.55535 > C.ssh: . 9124:10584(1460) ack 2016 win 65535
14:22:42.468350 IP C.ssh > B.55535: . ack 4744 win 65535
14:22:42.490556 IP C.ssh > B.55535: . ack 4744 win 65535
14:22:42.830171 IP B.55535 > C.ssh: . 4744:6204(1460) ack 2016 win 65535
14:22:43.470135 IP B.55535 > C.ssh: . 4744:6204(1460) ack 2016 win 65535
14:22:44.549944 IP B.55535 > C.ssh: . 4744:6204(1460) ack 2016 win 65535
14:22:46.509750 IP B.55535 > C.ssh: . 4744:6204(1460) ack 2016 win 65535
14:22:50.229210 IP B.55535 > C.ssh: . 4744:6204(1460) ack 2016 win 65535

    This sounds like a packet filter state issue.  My guess is that
    PF running on B is getting confused.  Either PF is getting confused,
    or the packet is getting munged somehow to the point where PF refuses
    to bridge it.

    The A->C path (the one that is working) is going through PF's NAT rules.
    The B->C path is probably going through a different set of PF rules.

    I suggest capturing a trace on C to see if C is actually receiving 
    B's retransmissions.

 					-Matt