From owner-freebsd-net@FreeBSD.ORG Fri Apr 4 22:23:41 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 3CD661065671 for ; Fri, 4 Apr 2008 22:23:41 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outM.internet-mail-service.net (outm.internet-mail-service.net [216.240.47.236]) by mx1.freebsd.org (Postfix) with ESMTP id 1445E8FC21 for ; Fri, 4 Apr 2008 22:23:41 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Fri, 04 Apr 2008 18:10:48 -0700 Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id 3D60E2D600F; Fri, 4 Apr 2008 15:23:38 -0700 (PDT) Message-ID: <47F6AA6B.30601@elischer.org> Date: Fri, 04 Apr 2008 15:23:39 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: Ivan Voras References: <47F5B17E.5000304@elischer.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Trouble with IPFW or TCP? 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: Fri, 04 Apr 2008 22:23:41 -0000 Ivan Voras wrote: > Ian Smith wrote: > >> That's pretty well described under keep-state and elsewhere. Good ol' >> ipfw(8) has yet to let me down, and like Ivan I recall keep-state rules >> (albeit only for UDP) without any check-state working just fine. >> >> Not that any of that helps solve Ivan's problem .. > > Thanks for verifying this. I've reread what I posted and I think I > wasn't clear about one thing: it's not exactly a "hard" problem - as I > said, connections do get established and apparently they get processed > (the effects of those HTTPS messages are present). What troubles me is > that I wouldn't expect that to happen, considering the ipfw log messages > I've posted. In short, either: > > a) The senders (or something in between like a broken router; but note > that the 7.x machine behind the same infrastructure isn't generating the > symptomatic log records) keeps sending spurious packets long after the > TCP session (communication) is actually completed. Someone with better > knowledge of TCP flows could maybe verify that. HTTPS messages are sent > every 15 minutes and I'd expect various timers to timeout the connection > if the ACKs aren't processed. > > b) The receiving side somehow bounces the packets around, reinserting > them after the TCP session is done. This would be weird. The server from > which the posted logs and traces come from isn't running anything > special like netgraph, bpf applications, routed. It's basically a web > server. > > > check that the ipfw dynamic sessions are not generating keepalives.. they should stop doing so when they see the FIN, but if they don't see it, they could generate keepalives forever. (there is an option to disable this)