From owner-freebsd-hackers Thu Apr 11 15:23:11 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id PAA17867 for hackers-outgoing; Thu, 11 Apr 1996 15:23:11 -0700 (PDT) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id PAA17853 for ; Thu, 11 Apr 1996 15:22:47 -0700 (PDT) Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id AAA28331; Fri, 12 Apr 1996 00:21:59 +0200 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id AAA20820; Fri, 12 Apr 1996 00:21:59 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.7.5/8.6.9) id AAA06535; Fri, 12 Apr 1996 00:09:03 +0200 (MET DST) From: J Wunsch Message-Id: <199604112209.AAA06535@uriah.heep.sax.de> Subject: Re: PPP routing problem To: freebsd-hackers@freebsd.org (FreeBSD hackers) Date: Fri, 12 Apr 1996 00:09:02 +0200 (MET DST) Cc: scrappy@ki.net (Marc G. Fournier) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: from "Marc G. Fournier" at Apr 11, 96 10:15:51 am X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL24 ME8a] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As Marc G. Fournier wrote: > > Don't use proxyarp. :) > > > I'm not, or at least not to the best of my knowledge. OKay, now > I feel stupid...how do I disable proxyarp? How do I know if I'm using it? Well, of course, you don't need to have proxyarp. It's quite possible that your PPP client was invisible from the outside world. Proxyarp is just `arp -s', e.g. from within the ip-up script. It's used to ``wire'' a PPP (or SLIP) external host into your local ethernet, so the PPP gateway will act as a proxy, using its own ethernet address on behalf of the remote PPP end. Nevertheless, you've assigned your remote PPP machine an address out of the range of your local ethernet. Everything works fine as long as this machine is connected. Now, the machine disconnects, the interface route out to it disappears, but as soon as the next packet for this IP address arrives, a regular ARP resolve is attempted. It never succeeds, but the half-baked entry to link#1 remains in the routing table. The only workaround i've found for it by now (short of understanding the routing code in the kernel) was to run ``arp -d'' for this IP address in the ip-up script, and retrying the ifconfig. This still leaves a minor window where a new incoming packet for this IP address could trigger another ARP attempt. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-)