From owner-freebsd-net Wed Aug 1 11:10:20 2001 Delivered-To: freebsd-net@freebsd.org Received: from ra.eng.mindspring.net (ra.eng.mindspring.net [207.69.192.184]) by hub.freebsd.org (Postfix) with SMTP id 352F037B405 for ; Wed, 1 Aug 2001 11:10:17 -0700 (PDT) (envelope-from sj@ra.eng.mindspring.net) Received: (qmail 5425 invoked by uid 52477); 1 Aug 2001 18:09:37 -0000 To: Thomas Pornin Cc: freebsd-net@freebsd.org, freebsd-alpha@freebsd.org Subject: Re: PPPoE + Alpha + 32/64 bits References: <20010801173624.A13674@bolet.ens.fr> From: Sudish Joseph Date: 01 Aug 2001 14:09:36 -0400 In-Reply-To: <20010801173624.A13674@bolet.ens.fr> (Thomas Pornin's message of "Wed, 1 Aug 2001 17:36:25 +0200") Message-ID: Lines: 26 User-Agent: Gnus/5.090003 (Oort Gnus v0.03) XEmacs/21.2 (Hera) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Thomas Pornin writes: > The problem is in the pppoe_finduniq() function. In order to identify > sessions, the PPPoE code sends a tag with the first packet it sends to > the modem; this tag is in fact a 64-bit pointer to some data structure > in kernel space. When a packet of type PADO_CODE or PADS_CODE is > received, the tag is compared with known pointers. > However, only 32 bits are present in the return tag. So, if the original > pointer is 0xfffffc00003b3d00, the tag contains only 0x003b3d00, which > are the first four bytes of data (in little-endian representation). If > I modify the pppoe_finduniq() function to accept matches on these four > bytes, the connection is established, and remains fully functionnal > afterwards. Yes, exactly. I ran into the same issue. See PR kern/27767 (http://www.freebsd.org/cgi/query-pr.cgi?pr=27767) for the bug report. The PR also contains the (gross, alpha-specific) hack I use right now to work around this issue. It simply masks out the upper 32 bits in the pointer when making the comparison. Obviously not a real solution, however it suffices for now since all of the pointers being compared are in the same 32-bit segment. -- Sudish Joseph To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message