From owner-freebsd-isp Sat Mar 23 07:30:17 1996 Return-Path: owner-isp Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id HAA25429 for isp-outgoing; Sat, 23 Mar 1996 07:30:17 -0800 (PST) Received: from fyeung5.netific.com (netific.vip.best.com [205.149.182.145]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id HAA25422 for ; Sat, 23 Mar 1996 07:30:13 -0800 (PST) Received: (from fyeung@localhost) by fyeung5.netific.com (8.6.11/8.6.9) id HAA03175; Sat, 23 Mar 1996 07:28:58 GMT From: francis yeung Message-Id: <199603230728.HAA03175@fyeung5.netific.com> Subject: Re: PPP (iijppp) proxy ARP bug? To: nate@sri.MT.net (Nate Williams) Date: Sat, 23 Mar 1996 07:28:58 +0000 () Cc: rob@xs1.simplex.nl, nate@sri.MT.net, steve@edmweb.com, isp@FreeBSD.org In-Reply-To: <199603221552.IAA18897@rocky.sri.MT.net> from "Nate Williams" at Mar 22, 96 08:52:14 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-isp@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Greetings, Nate's fix also works for 2.0.5 release too. Let me know if anyone needs it. Francis > > | > I seem to have found a bug in iijppp. It doesn't always delete the ARP > > | > entry when the connection is closed. Further connections on that IP > > | > address don't work until I manually arp -d the entry. > > | > > | This is a kernel bug which is fixed in -stable. Upgrade your kernel > > | sources to -stable and all will be well. > > > > Can anyone upgrade the kernel sources of 2.1-RELEASE to 2.2-stable (I > > assume you meant that) without expecting problems ? > > It's actually 2.1-stable, and 2.2-current. The next release of -stable > will be 2.1.1, so it's much more like 2.1 than 2.2. > > > And, is it really fixed, or do you mean that ugly hack about first > > checking if there still is an old arp entry before setting up a new > > one ? > > Umm, it's really fixed, but it involves deleting the bogus entry. > The system creating an unresolved entry is correct behavior, and > deleting the unresolved entry when a valid entry is found is correct > behavior. > > This is done in the kernel though, so it's not a user-land hack to work > around kernel bugs. > > > Nate > >