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 [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
