From owner-freebsd-stable Wed Mar 6 12:51:33 2002 Delivered-To: freebsd-stable@freebsd.org Received: from smtp.netcologne.de (smtp.netcologne.de [194.8.194.112]) by hub.freebsd.org (Postfix) with ESMTP id 2ACA137B416 for ; Wed, 6 Mar 2002 12:51:29 -0800 (PST) Received: from xdsl-213-168-118-131.netcologne.de (xdsl-213-168-118-131.netcologne.de [213.168.118.131]) by smtp.netcologne.de (8.12.2/8.12.2) with ESMTP id g26KpO3s019820 for ; Wed, 6 Mar 2002 21:51:25 +0100 (MET) Received: (qmail 810 invoked by uid 1001); 6 Mar 2002 20:50:41 -0000 Date: Wed, 6 Mar 2002 21:50:41 +0100 From: Thomas Seck To: freebsd-stable@FreeBSD.ORG Subject: Re: ppp and growing ip alias list Message-ID: <20020306205041.GA470@laurel.seck.home> Mail-Followup-To: freebsd-stable@FreeBSD.ORG References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.27i Organization: private site in Germany X-PGP-KeyID: DF46EE05 X-PGP-Fingerprint: A38F AE66 6B11 6EB9 5D1A B67D 2444 2FE1 DF46 EE05 Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG # Sameer R. Manek (manek@ecst.csuchico.edu): > On my 4.5-stable box, I've noticed what I think is a bug with ppp. Nope, this is a feature. It is very useful when you get only dynamic IPs and use the -auto option to re-establish the connection after a disconnect or a "close-on-idle" (which is what I use). This feature works around the problem that the IP packet that triggers the opening of a closed link is sent with the address that was assigned to the interface the last time it was up. There is a good chance that the new address of the interface will be different from the address which is written into the packet. Thus, replies to this packet will never get back to you so the sending application has to resend them after a timeout. This is usually not a problem should the application use UDP. A dial-up connection is usually brought up by DNS lookups via UDP. You will see the problem when you run a caching DNS resolver on your machine such as dnscache from the net/djbdns port. When the DNS requests are answered by your resolver without opening the dial-up link, an application that wants to establish a TCP connection will bring the connection up with the first TCP SYN packet. The handshake is thus initialized with a packet that has a wrong sender address and will obviously fail. You will notice ugly timeouts. The "iface-alias" in conjunction with "nat enable yes" will solve this problem. See ppp(8) for more information about this. --Thomas To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message