Date: 01 Aug 2001 14:09:36 -0400 From: Sudish Joseph <sudish@corp.earthlink.net> To: Thomas Pornin <Thomas.Pornin@ens.fr> Cc: freebsd-net@freebsd.org, freebsd-alpha@freebsd.org Subject: Re: PPPoE + Alpha + 32/64 bits Message-ID: <yviahevr3b4v.fsf@ra.eng.mindspring.net> In-Reply-To: <20010801173624.A13674@bolet.ens.fr> (Thomas Pornin's message of "Wed, 1 Aug 2001 17:36:25 %2B0200") References: <20010801173624.A13674@bolet.ens.fr>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?yviahevr3b4v.fsf>