Date: Thu, 18 Jan 96 15:18 CST From: malenovi@cview.com (Nik Malenovic) To: freebsd-current@freebsd.org Cc: pete@pelican.com, freebsd-hackers@freebsd.org Subject: Re: pppd route/proxy problem Message-ID: <m0td1jH-00068VC@tesla.cview.com> In-Reply-To: <DLE8wz.9n5@cview.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[notice redirection to -hackers as well] In article <DLE8wz.9n5@cview.com> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?m0td1jH-00068VC>