2.4.2 on AMD64 Linux: assumes 4-byte long
I'm new here. I hope this is the right place to post this question; please point me to the correct place if I've gotten it wrong. I've been trying to get 2.4.2 working on Mandrake 10.0 for AMD64, using kernel 2.6.3. I've downloaded this version, along with a corresponding 1.4.0 version of pptp, from the pptp-client site. I'm getting a "Fatal signal 11", which I've traced to the SHA1_Final function on sha1.c during CHAP Challenge phase of connection setup.
Looking in sha1.h and sha1.c source code, I see data structures and functions with longs in them, which sets off alarms. I think there was an assumption when this code was written that a long is 4 bytes long. On an AMD64 64-bit OS, a long is 8 bytes. What leads me to think this is #define in sha1.c:
#define rol(value, bits) (((value) << (bits)) | ((value) >> (32 - (bits))))
Clearly, on a 64-bit long, this won't produce a correct rotate-left. I've googled on sha1.c, and I've found several instances where the code has switched to using u_int32 instead of long, including one by the same author (Steve Reid) here:
http://cvsweb.stop1984.com/index.cgi/entropy/src/sha1.c?rev=1.12&content-type=text/x-cvsweb-markup
As a test, I tried simply changing all the longs to ints in sha1.h and sha1.c. Unfortunately, I went from getting segfaults to getting kernel panics. I'm suspecting this is not a valid thing to do, since the corresponding files that the kernel was built from still have long declarations. I'm guessing these need to match, correct? Or is pppd standalone, and can I change sha1.c/h without worrying about the kernel (which I compiled myself from Mandrake sources)?
I also tried simply changing the definition of rol above to use 64 instead of 32. Predictably, that didn't work.
I'm not an expert in networking. I'd appreciate any and all suggestions anyone can provide to get this working. Thanks.
Signature · 1 line
Guy Rouillier
Re: 2.4.2 on AMD64 Linux: assumes 4-byte long - FIXED!
Sorry for the top post, it's late and I'm tired and I'm replying to my own message anyway. I fixed this problem, and I'm now able to use
pptp/ppp/mppe to connect to a Microsoft server at work. The fix
requires changes to the sha1 code both in ppp-2.4.2 and in the kernel. To whom should I send the fixes? This is my first kernel fix so I don't
really know how to proceed. Hmm, I guess half the fixes go to the ppp
maintainers and the other half go to the kernel people.
Quoted 44 lines · On Sun, 6 Jun 2004 02:19:36 -0400 Guy Rouillier <[email protected]>…
I'm new here. I hope this is the right place to post this question; please point me to the correct place if I've gotten it wrong. I've been trying to get 2.4.2 working on Mandrake 10.0 for AMD64, using kernel 2.6.3. I've downloaded this version, along with a corresponding 1.4.0 version of pptp, from the pptp-client site. I'm getting a "Fatal signal 11", which I've traced to the
SHA1_Finalfunction onsha1.cduring CHAP Challenge phase of connection setup.Looking in
sha1.handsha1.csource code, I see data structures and functions with longs in them, which sets off alarms. I think there was an assumption when this code was written that a long is 4 bytes long. On an AMD64 64-bit OS, a long is 8 bytes. What leads me to think this is #define insha1.c:#define
rol(value, bits)(((value) << (bits)) | ((value) >> (32 - (bits))))Clearly, on a 64-bit long, this won't produce a correct rotate-left. I've googled on
sha1.c, and I've found several instances where the code has switched to usingu_int32instead of long, including one by the same author (Steve Reid) here:http://cvsweb.stop1984.com/index.cgi/entropy/src/sha1.c?rev=1.12&content-type=text/x-cvsweb-markup
As a test, I tried simply changing all the longs to ints in
sha1.handsha1.c. Unfortunately, I went from getting segfaults to getting kernel panics. I'm suspecting this is not a valid thing to do, since the corresponding files that the kernel was built from still have long declarations. I'm guessing these need to match, correct? Or is pppd standalone, and can I change sha1.c/h without worrying about the kernel(which I compiled myself from Mandrake sources)?I also tried simply changing the definition of rol above to use 64 instead of 32. Predictably, that didn't work.
I'm not an expert in networking. I'd appreciate any and all suggestions anyone can provide to get this working. Thanks.
Signature · 5 lines
Guy Rouillier - To unsubscribe from this list: send the line "unsubscribe linux-ppp" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Signature · 5 lines
Guy Rouillier -- Guy Rouillier
Re: 2.4.2 on AMD64 Linux: assumes 4-byte long - FIXED!
In reply to Guy RouillierQuoted 10 lines · On Wed, 9 Jun 2004 16:24:08 +1000 James Cameron <[email protected]> wrote:
You're right.
The patches to the PPP maintainers, chuck 'em at the mailing list, and ask for a response. If that fails, and it has to do with MPPE, send it to Frank Cusack <[email protected]>.
The kernel, if it has to do with the PPP modules, again, chuck 'em at the linux-ppp mailing list. Paul Mackerras is ultimately responsible to promote them to the kernel team. Or you could explain it very carefully and try the LKML (Linux Kernel Mailing List).
James, thank you for the detailed reply. I mentioned this is my first fix to the kernel, right? So I won't be to embarrassed to admit that I'm a little confused about the kernel part. The fix I made definitely
worked. But I took the time to download the stock kernel from
kernel.org, and none of the files I changed are in there! I looked at both the 2.6.3 and 2.6.6 versions. The version I'm working with is Mandrake 2.6.3-9. The files I changed are drivers/net/sha1.c and /drivers/net/sha1.h. In the Mandrake kernel source, /drivers/net also has some files related to mppe: ppp_mppe_compress.c and ppp_mppe.mod.c. The stock kernels from kernel.org don't have any of these four files!
Does that mean these files were added by Mandrake, and I should file a bug report with them instead of ppp-linux? I'm surprised to learn that mppe is not supported by the stock kernel. Appreciate your guiding a newbie through this process.
Quoted 11 lines
http://www.tldp.org/HOWTO/Software-Release-Practice-HOWTO/patching.html
has some good hints to help your patch be accepted.I'm just an interested bystander. ;-)
Signature · 4 lines
James Cameron http://quozl.netrek.org/ HP Open Source, Volunteer http://opensource.hp.com/ PPTP Client Project, Release Engineer http://pptpclient.sourceforge.net/
Signature · 1 line
Guy Rouillier
Re: 2.4.2 on AMD64 Linux: assumes 4-byte long - FIXED!
In reply to Guy RouillierGuy,
Yes, Mandrake's kernel source includes MPPE support, and the kernel.org sources do not. Other distributions also add MPPE support in this way; Debian and SUSE included. Red Hat do not.
I know Debian get their kernel-patch-mppe package from PPP CVS. I suspect Mandrake and SUSE did as well. You should check that the sources match what is in PPP CVS. To get PPP CVS onto your system,
cd /usr/src # (or some other reasonable directory) cvs -d :pserver:[email protected]:/cvsroot co ppp/linux/mppe
If you've made changes to drivers/net/sha1.{c,h} and Mandrake got these from Frank Cusack's work that is in PPP CVS (directory linux/mppe), then you could post them here or to Frank.
Matt Domsch, Jan Dubiec, and some others have also been working on the MPPE patch; they have posted to the PPTP mailing lists.
If you logged a bug report with Mandrake, one would hope that they would elevate this report back to Frank. ;-) There is a risk that they will adjust their patch instead.
Signature · 3 lines
James Cameron http://quozl.netrek.org/ HP Open Source, Volunteer http://opensource.hp.com/ PPTP Client Project, Release Engineer http://pptpclient.sourceforge.net/
Re: 2.4.2 on AMD64 Linux: assumes 4-byte long - FIXED!
In reply to Guy RouillierQuoted 10 lines · On Thu, 10 Jun 2004 14:43:46 +1000 James Cameron <[email protected]> wrote:
Guy,
Yes, Mandrake's kernel source includes MPPE support, and the kernel.org sources do not. Other distributions also add MPPE support in this way; Debian and SUSE included. Red Hat do not.
I know Debian get their kernel-patch-mppe package from PPP CVS. I suspect Mandrake and SUSE did as well. You should check that the sources match what is in PPP CVS. To get PPP CVS onto your system,
Quoted 6 lines
cd
/usr/src# (or some other reasonable directory) cvs -d :pserver:[email protected]:/cvsroot co ppp/linux/mppeIf you've made changes to
drivers/net/sha1.{c,h}and Mandrake got these from Frank Cusack's work that is in PPP CVS (directory linux/mppe), then you could post them here or to Frank.
Thanks. I checked out ppp, and the Mandrake 2.6.3-9 kernel did indeed get sha1.c/h from linux/mppe. I will post two new messages here, one for the fix to ppp/pppd and the other for the kernel fix in linux/mppe.
I appreciate your help.
Quoted 17 lines
Matt Domsch, Jan Dubiec, and some others have also been working on the MPPE patch; they have posted to the PPTP mailing lists.
If you logged a bug report with Mandrake, one would hope that they would elevate this report back to Frank. ;-) There is a risk that they will adjust their patch instead.
Signature · 8 lines
James Cameron http://quozl.netrek.org/ HP Open Source, Volunteer http://opensource.hp.com/ PPTP Client Project, Release Engineer http://pptpclient.sourceforge.net/ - To unsubscribe from this list: send the line "unsubscribe linux-ppp" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Signature · 1 line
Guy Rouillier
Re: 2.4.2 on AMD64 Linux: assumes 4-byte long - FIXED!
In reply to Guy RouillierQuoted 4 lines · Guy Rouillier
Sorry for the top post, it's late and I'm tired and I'm replying to my own message anyway. I fixed this problem, and I'm now able to use pptp/ppp/mppe to connect to a Microsoft server at work.
me too :)
Quoted 4 lines
The fix
requires changes to the sha1 code both in ppp-2.4.2 and in the kernel.
Yes, and I have provided the patch to the list for both changes.
Have you tried my patch (as you wrote were going to do) and found it doesn't work?
Quoted 2 lines
To whom should I send the fixes?
Please CC it to me. I would like to know what else but two-liner you think is needed.
Quoted 59 lines
This is my first kernel fix so I don't
really know how to proceed. Hmm, I guess half the fixes go to the ppp
maintainers and the other half go to the kernel people.Quoted 46 lines · On Sun, 6 Jun 2004 02:19:36 -0400 Guy Rouillier <[email protected]>…
I'm new here. I hope this is the right place to post this question; please point me to the correct place if I've gotten it wrong. I've been trying to get 2.4.2 working on Mandrake 10.0 for AMD64, using kernel 2.6.3. I've downloaded this version, along with a corresponding 1.4.0 version of pptp, from the pptp-client site. I'm getting a "Fatal signal 11", which I've traced to the
SHA1_Finalfunction onsha1.cduring CHAP Challenge phase of connection setup.Looking in
sha1.handsha1.csource code, I see data structures and functions with longs in them, which sets off alarms. I think there was an assumption when this code was written that a long is 4 bytes long. On an AMD64 64-bit OS, a long is 8 bytes. What leads me to think this is #define insha1.c:#define
rol(value, bits)(((value) << (bits)) | ((value) >> (32 - (bits))))Clearly, on a 64-bit long, this won't produce a correct rotate-left. I've googled on
sha1.c, and I've found several instances where the code has switched to usingu_int32instead of long, including one by the same author (Steve Reid) here:http://cvsweb.stop1984.com/index.cgi/entropy/src/sha1.c?rev=1.12&content-type=text/x-cvsweb-markup
As a test, I tried simply changing all the longs to ints in
sha1.handsha1.c. Unfortunately, I went from getting segfaults to getting kernel panics. I'm suspecting this is not a valid thing to do, since the corresponding files that the kernel was built from still have long declarations. I'm guessing these need to match, correct? Or is pppd standalone, and can I change sha1.c/h without worrying about the kernel(which I compiled myself from Mandrake sources)?I also tried simply changing the definition of rol above to use 64 instead of 32. Predictably, that didn't work.
I'm not an expert in networking. I'd appreciate any and all suggestions anyone can provide to get this working. Thanks.
Signature · 5 lines
Guy Rouillier - To unsubscribe from this list: send the line "unsubscribe linux-ppp" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html