From owner-cvs-all Fri Aug 9 10:30:11 2002 Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B431337B400; Fri, 9 Aug 2002 10:30:03 -0700 (PDT) Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id E737943E72; Fri, 9 Aug 2002 10:30:02 -0700 (PDT) (envelope-from archie@dellroad.org) Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.1.1.20]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id KAA03952; Fri, 9 Aug 2002 10:18:37 -0700 (PDT) Received: (from archie@localhost) by arch20m.dellroad.org (8.11.6/8.11.6) id g79HGno08306; Fri, 9 Aug 2002 10:16:49 -0700 (PDT) (envelope-from archie) From: Archie Cobbs Message-Id: <200208091716.g79HGno08306@arch20m.dellroad.org> Subject: Re: cvs commit: src/sys/netinet in_rmx.c ip_input.c ip_var.h In-Reply-To: <20020809145837.GD38763@sunbay.com> "from Ruslan Ermilov at Aug 9, 2002 05:58:37 pm" To: Ruslan Ermilov Date: Fri, 9 Aug 2002 10:16:49 -0700 (PDT) Cc: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org X-Mailer: ELM [version 2.4ME+ PL88 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Ruslan Ermilov writes: > > Modified files: (Branch: RELENG_4) > > sys/netinet in_rmx.c ip_input.c ip_var.h > > Log: > > MFC: in_rmx.c,v 1.39, ip_input.c,v 1.165, and ip_var.h,v 1.54: > > > > Invalidate cached forwarding route (ipforward_rt) whenever a new > > route is added to the routing table, otherwise we may end up using > > the wrong route when forwarding. > > > > PR: kern/10778 > > Spotted by: Sergey Starosek , > > Andrew Rukavishnikov > > I thought I merged this years ago; today we have spent two hours > figuring out why the server running mpd(8)'s PPTP with manually > added host routes was not (randomly) forwarding IP datagrams to > the remote end of the PPTP connection. It was a BIG surprise > when I figured out I did not MFC this fix. Welcome to the club of people who have been stumped for hours by this bug :-) I'm glad we're finally rid of it (after 3 years). > BTW, Archie, kudos for making mpd(8) work in a scenario documented > in the BUGS section of libalias(3). How this is done? The PPTP spec assumes that only one control connection (i.e., TCP port 1723) will exist between any two IP addresses. Originally, mpd was written to honor that. However, unless you are identifying the peer by its IP address, there's no real need to disallow multiple connections from the same IP address. So mpd was changed to allow multiple connections when possible. Although this violates the spec, it's a beneficial change. Consider it a bug in the spec :-) FYI, you may notice that L2TP, which came after PPTP, doesn't make this useless assumption. Any number of L2TP control connections may exist between two peers. Cheers, -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message