Discussion:
pptp, take 3
(too old to reply)
der Mouse
2011-03-29 20:01:07 UTC
Permalink
Some of you may recall that, recently, I've been trying to set up a
NetBSD 5.1 box as a PPTP endpoint. This is the latest on this, with an
informal bug report (a proper PR will follow).

After struggling with options settings, I got some really weird
behaviour: the NetBSD end would be ConfAcking MPPE negotiation
incorrectly:

Mar 29 15:53:51 potato pppd[19491]: rcvd [CCP ConfReq id=0x2 <mppe +H -M -S +L -D -C>]
Mar 29 15:53:51 potato pppd[19491]: sent [CCP ConfAck id=0x2 <mppe +H -M -S +L -D -C>]

I dove into the code and FINALLY figured this out. One simple fix
later and the link came up far enough to answer pings.

The problem is, ccp.h declares "bool mppe", then uses the 0x7f bits of
that field as flags. This works fine when bool is a typedef or #define
for a char or u_char or some such. But, in 5.1, it's a #define to
_Bool, which is apparently a built-in boolean type, and all the
foo->mppe |= 8 and the like got compiled into foo->mppe = 1 - this
verified by compiling with -save-temps and looking at the .s file.

I changed it to "u_char mppe" and everything started to work.

There may still be problems; this is only a preliminary success - but
if you've been having trouble with MPPE versus NetBSD, it might be
worth looking at this.

/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML ***@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Iain Hibbert
2011-03-29 20:33:55 UTC
Permalink
Post by der Mouse
I changed it to "u_char mppe" and everything started to work.
There may still be problems; this is only a preliminary success - but
if you've been having trouble with MPPE versus NetBSD, it might be
worth looking at this.
this has already been fixed in -current (was changed to u_short) and
was pulled up to -5 branch but I guess that it missed 5.1 ..

iain

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
der Mouse
2011-03-29 20:49:16 UTC
Permalink
Post by Iain Hibbert
this has already been fixed in -current (was changed to u_short) and
was pulled up to -5 branch but I guess that it missed 5.1 ..
Guess it must have!

Okay, no PR will be forthcoming from me after all, since it would just
duplicate 41627 and 42390. :-)

Mouse

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Christos Zoulas
2011-03-30 23:27:31 UTC
Permalink
Post by der Mouse
Some of you may recall that, recently, I've been trying to set up a
NetBSD 5.1 box as a PPTP endpoint. This is the latest on this, with an
informal bug report (a proper PR will follow).
After struggling with options settings, I got some really weird
behaviour: the NetBSD end would be ConfAcking MPPE negotiation
Mar 29 15:53:51 potato pppd[19491]: rcvd [CCP ConfReq id=0x2 <mppe +H -M -S +L -D -C>]
Mar 29 15:53:51 potato pppd[19491]: sent [CCP ConfAck id=0x2 <mppe +H -M -S +L -D -C>]
I dove into the code and FINALLY figured this out. One simple fix
later and the link came up far enough to answer pings.
The problem is, ccp.h declares "bool mppe", then uses the 0x7f bits of
that field as flags. This works fine when bool is a typedef or #define
for a char or u_char or some such. But, in 5.1, it's a #define to
_Bool, which is apparently a built-in boolean type, and all the
foo->mppe |= 8 and the like got compiled into foo->mppe = 1 - this
verified by compiling with -save-temps and looking at the .s file.
I changed it to "u_char mppe" and everything started to work.
There may still be problems; this is only a preliminary success - but
if you've been having trouble with MPPE versus NetBSD, it might be
worth looking at this.
Head has u_short mppe; what version are you using?

christos


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Loading...