From owner-freebsd-hackers Thu Jan 18 13:19:07 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id NAA03437 for hackers-outgoing; Thu, 18 Jan 1996 13:19:07 -0800 (PST) Received: from tesla.cview.com (root@tesla.cview.com [204.95.57.17]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id NAA03413 Thu, 18 Jan 1996 13:18:56 -0800 (PST) Received: by tesla.cview.com (Smail3.1.29.0 #1) id m0td1jH-00068VC; Thu, 18 Jan 96 15:18 CST Message-Id: Date: Thu, 18 Jan 96 15:18 CST From: malenovi@cview.com (Nik Malenovic) To: freebsd-current@freebsd.org Subject: Re: pppd route/proxy problem Newsgroups: cview.freebsd.current In-Reply-To: Organization: CView Inc. Cc: pete@pelican.com, freebsd-hackers@freebsd.org Sender: owner-hackers@freebsd.org Precedence: bulk [notice redirection to -hackers as well] In article you write: >I think this is an old problem that has never been resolved, but I may [...] >The problem is that if the other end of a connection sends something to >the ip addr while pppd is down, an 'incomplete' entry goes into the >arp table. Under some circumstances a race occurs and that incomplete >entry never times out. Even if it does, the proxy entry either doesn't >end up in the table or doesn't work when written while the incomplete >entry is present. [...] yeah it's a problem all right. it's that, since you are doing proxy arp, your IP number of dialup PPP client is the same as IP # on the local wire. well, the 4.x BSD networking code, puts incomplete arp entries on use of the IP # on the local wire that do not respond. solution is to nuke (incomplete) arp entry (arp -d command) in the ppplogin shell. another solution is not to do proxyarp, and have PPP client IP be located on the separate subnet (non-ethernet subnet) the third solution is to hack arp code, and remove creation of incomplete IP entries on their use. (i.e. the time when the IP number is being used, during broadcasts 'who-has such-and-such-IP', until the IP is determined to be down by the broadcasting interface) notice that BSDI, FreeBSD have this bug. I suspect NetBSD is the same. I have no clue about Linux. I've heard that SunOS/et al. do not have this problem. Nik