From owner-freebsd-stable@FreeBSD.ORG Fri Jul 17 23:13:35 2009 Return-Path: Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2F570106566C for ; Fri, 17 Jul 2009 23:13:35 +0000 (UTC) (envelope-from news@citylink.dinoex.sub.org) Received: from uucp.dinoex.sub.de (uucp.dinoex.sub.de [194.45.71.2]) by mx1.freebsd.org (Postfix) with ESMTP id 98C708FC12 for ; Fri, 17 Jul 2009 23:13:34 +0000 (UTC) (envelope-from news@citylink.dinoex.sub.org) Received: from uucp.dinoex.sub.de (uucp@uucp.dinoex.sub.de [194.45.71.2] (may be forged)) by uucp.dinoex.sub.de (8.14.3/8.14.2) with ESMTP id n6HNCqI8047862 for ; Sat, 18 Jul 2009 01:12:52 +0200 (CEST) (envelope-from news@citylink.dinoex.sub.org) X-MDaemon-Deliver-To: Received: from citylink.dinoex.sub.org (uucp@localhost) by uucp.dinoex.sub.de (8.14.3/8.14.2/Submit) with UUCP id n6HNCq6r047861 for freebsd-stable@FreeBSD.ORG; Sat, 18 Jul 2009 01:12:52 +0200 (CEST) (envelope-from news@citylink.dinoex.sub.org) Received: from gate.oper.dinoex.org (gate-e [192.168.98.2]) by citylink.dinoex.sub.de (8.14.3/8.14.2) with ESMTP id n6HME68D026386 for ; Sat, 18 Jul 2009 00:14:06 +0200 (CEST) (envelope-from news@gate.oper.dinoex.org) Received: from gate.oper.dinoex.org (gate-e [192.168.98.2]) by gate.oper.dinoex.org (8.14.3/8.14.3) with ESMTP id n6HME2t3026307 for ; Sat, 18 Jul 2009 00:14:02 +0200 (CEST) (envelope-from news@gate.oper.dinoex.org) Received: (from news@localhost) by gate.oper.dinoex.org (8.14.3/8.14.3/Submit) id n6HME2rg026300 for freebsd-stable@FreeBSD.ORG; Sat, 18 Jul 2009 00:14:02 +0200 (CEST) (envelope-from news) From: pmc@citylink.dinoex.sub.org (Peter Much) Message-ID: Date: Fri, 17 Jul 2009 21:59:21 GMT Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=ISO-8859-1 References: <7090AD67-2082-4AFA-B130-C20A7DC970FA@mac.com> Mime-Version: 1.0 Organization: dread of the bookshelf X-Newsreader: trn 4.0-test76 (Apr 2, 2001) Sender: To: freebsd-stable@FreeBSD.ORG X-Milter: Spamilter (Reciever: uucp.dinoex.sub.de; Sender-ip: 194.45.71.2; Sender-helo: uucp.dinoex.sub.de; ) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (uucp.dinoex.sub.de [194.45.71.2]); Sat, 18 Jul 2009 01:12:53 +0200 (CEST) Cc: Subject: Re: Can an app crash from a single TCP packet lost in transmission? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2009 23:13:35 -0000 aka Chuck Swiger schrieb mit Datum Fri, 17 Jul 2009 13:49:10 -0700 in m2n.fbsd.stable: |On Jul 17, 2009, at 12:12 PM, Peter Much wrote: |[ ... ] |> One other thing did happen between 03:51 and 03:52 - the DSL |> internet connection did disconnect/reconnect and obtained a new |> IP adress. Afterwards, a script does flush and reload an ipfw table() |> with the new local adresses - and during this process one(!) packet |> of the database session was dropped. | |Well, there you go: having your IP change is certainly going to break |existing network connections; Uh, is that so? Maybe I wasnt clear enough: the failing database connection is a LOCALHOST-LOCALHOST connection - and it uses the (fixed) IP of one of the LAN interfaces, not the dynamic internet IP on the tun/PPP interface. Changing the IP on one interface while using another interface is, to all my knowledge, normal business. And even IF there were problem with that, then I would expect the connection to timeout and fail, I would NOT expect a memory leak to appear and drive the system out of swap within seconds. !I don't believe there is anything which |is going to move the existing connection state in a NAT translation |layer or whatever over to the new IP. Nay, that doesnt work. |Presumably you can obtain a |static IP and avoid such issues. I have a static internet IP on the machine, also, for HTTPS. I have lots of interfaces there. And I did run some tests in the meantime. The problem is in the PostgresQL library; it doesnt depend on a changed IP; - I only need to steal one packet out of the transmission, then the database client will grow to VSZ=1500GB and bigger. That's perfect reproduceable. The postgresQL is 8.2, rather old by now - but I really wonder that noone else did get into this during all the time. rgds, PMc