This message generated a parse failure. Raw output follows here. Please use 'back' to navigate. From devnull@lkml.org Tue May 28 21:39:47 2024 Received: from entropy.muc.muohio.edu (IDENT:root@entropy.muc.muohio.edu [134.53.213.10]) by herbie.ucs.indiana.edu (8.9.3/8.9.3) with ESMTP id CAA03901 for ; Fri, 7 May 1999 02:45:41 -0500 (EST) Received: from vger.rutgers.edu (vger.rutgers.edu [128.6.190.2]) by entropy.muc.muohio.edu (8.8.7/8.8.7) with ESMTP id DAA23384; Fri, 7 May 1999 03:45:32 -0400 Received: by vger.rutgers.edu via listexpand id <155622-31805>; Fri, 7 May 1999 01:33:50 -0400 Received: by vger.rutgers.edu id <155540-31807>; Thu, 6 May 1999 23:25:55 -0400 Received: from www.hr.vc-graz.ac.at ([193.171.240.3]:14399 "EHLO www.hr.vc-graz.ac.at" ident: "NO-IDENT-SERVICE[2]") by vger.rutgers.edu with ESMTP id <156975-31807>; Thu, 6 May 1999 20:24:13 -0400 Received: from friedl.dyn.priv.at (hr-1.hr.vc-graz.ac.at [193.171.240.11]) by www.hr.vc-graz.ac.at (8.8.8/8.8.7) with ESMTP id DAA23707; Fri, 7 May 1999 03:04:02 +0200 Received: from fl.priv.at (localhost [127.0.0.1]) by friedl.dyn.priv.at (8.8.8/8.8.7) with ESMTP id DAA03375; Fri, 7 May 1999 03:04:29 +0200 Message-Id: <37323C1D.C041DA89@fl.priv.at> Date: Fri, 07 May 1999 03:04:29 +0200 From: Friedrich Lobenstock X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.0.36 i586) X-Accept-Language: de, en Mime-Version: 1.0 To: Alan Cox Cc: Linux Kernel Mailing List Subject: Re: [PATCH] tunneling icmp patch (long!) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-kernel@vger.rutgers.edu Precedence: bulk X-Loop: majordomo@vger.rutgers.edu X-Orcpt: rfc822;linux-kernel-outgoing-dig Alan Cox wrote: > > ... > Please don't run patches like this on the real internet. The moment you get > a loop in your tunnel you will upset quite a few people > > .... > The TTL must always be decreasing. It is valid for it to decrease only one > across a tunnel transit, but you cannot go setting the TTL higher than > it was before without risking a loop e.g: this host: eth0 = A.A.A.X and eth0:0 = 10.3.1.1 tunnelling partner: eth0 = B.B.B.X and eth1 = 10.2.1.1 tunneling: 10.2.1.0/24 <-> 10.3.1.0/24 Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 10.2.1.0 B.B.B.X 255.255.255.0 UG 0 0 0 tunl0 A.A.A.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 10.3.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo 0.0.0.0 A.A.A.Y 0.0.0.0 UG 0 0 0 eth0 traceroute to 10.2.1.111 (10.2.1.111), 30 hops max, 40 byte packets 1 10.2.1.1 (10.2.1.1) 92 ms 90 ms 106 ms 2 10.2.1.111 (10.2.1.111) 105 ms 71 ms 58 ms  Without my patch this would be totally different. You get this: traceroute to 10.2.1.111 (10.2.1.111), 30 hops max, 40 byte packets 1 * * * 2 * * * 3 * * * 4 * * * 5 * * * 6 * * * 7 * * * 8 * * * 9 * * * 10 10.2.1.111 (10.2.1.111) 77 ms 70 ms 76 ms This shows you that there is a tunnel. For me a tunnel should be totally transparent to the user. This is not true in the unpatched version of the ipip module but how can this be done without the hazard of building endless loops. MfG / Regards Friedrich - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/