Hello I've managed to compile pam_radius-1.3.17 both 32Bit and 64Bit. I had to add -lsocket as part of linking to get it to work and modified the make file to have -m64 to compile on 64bit When I compile it for 64Bit this is my make output: gcc -Wall -fPIC -m64 -c pam_radius_auth.c -o pam_radius_auth.o pam_radius_auth.c: In function `ipstr2long': pam_radius_auth.c:185: warning: subscript has type `char' pam_radius_auth.c: In function `good_ipaddr': pam_radius_auth.c:221: warning: subscript has type `char' pam_radius_auth.c: In function `host2server': pam_radius_auth.c:277: warning: subscript has type `char' pam_radius_auth.c: In function `rad_converse': pam_radius_auth.c:1027: warning: passing arg 3 of `pam_get_item' from incompatible pointer type pam_radius_auth.c:1030: warning: passing arg 2 of pointer to function from incompatible pointer type pam_radius_auth.c: In function `pam_sm_authenticate': pam_radius_auth.c:1081: warning: passing arg 2 of `pam_get_user' from incompatible pointer type pam_radius_auth.c:1097: warning: passing arg 3 of `pam_get_item' from incompatible pointer type pam_radius_auth.c:1102: warning: assignment from incompatible pointer type pam_radius_auth.c:1121: warning: passing arg 3 of `pam_get_item' from incompatible pointer type pam_radius_auth.c:1135: warning: passing arg 3 of `pam_get_item' from incompatible pointer type pam_radius_auth.c:1168: warning: passing arg 3 of `pam_get_item' from incompatible pointer type pam_radius_auth.c: In function `pam_private_session': pam_radius_auth.c:1300: warning: passing arg 2 of `pam_get_user' from incompatible pointer type pam_radius_auth.c:1321: warning: passing arg 3 of `pam_get_item' from incompatible pointer type pam_radius_auth.c: In function `pam_sm_chauthtok': pam_radius_auth.c:1407: warning: passing arg 2 of `pam_get_user' from incompatible pointer type pam_radius_auth.c:1428: warning: passing arg 3 of `pam_get_item' from incompatible pointer type pam_radius_auth.c:1437: warning: passing arg 3 of `pam_get_item' from incompatible pointer type pam_radius_auth.c:1442: warning: passing arg 3 of `pam_get_item' from incompatible pointer type gcc -Wall -fPIC -m64 -m64 -I/usr/local/include -R/usr/local/lib/sparcv9 -c md5.c gcc -R/usr/local/lib/sparcv9 -m64 -shared pam_radius_auth.o md5.o -lpam -lsocket -lc -o pam_radius_auth.so Which is all well and good. But when I try and use the 64Bit version of pamtester it core dumps. The 32Bit version compiles fine, and 32bit version of pamtester also works fine. ./pamtester jpam peter authenticate Password: Bus Error (core dumped) In /var/adm/messages I get: Sep 22 13:51:46 sf2428 genunix: [ID 603404 kern.notice] NOTICE: core_log: pamtester[13662] core dumped: /var/core/core_sol9_pamtester_0_0_1285120305_13662 Any suggestions on what to do with gdb or to debug this problem?? I've seen a number of posts such as this one: http://networking.itags.org/networking-tech/58575/ Talking about changing the typedef for md5.h -#define uint32 u_int32_t +#define uint32 uint32_t However 1.3.17 already seems to have this patch. struct MD5Context { uint32_t buf[4]; uint32_t bits[2]; unsigned char in[64]; }; I'm no C developer so not sure where to go to from here. Any suggestions would be gratefully accepted. Cheers Peter
Peter Lambrechtsen wrote:
Hello
I've managed to compile pam_radius-1.3.17 both 32Bit and 64Bit.
I had to add -lsocket as part of linking to get it to work and modified the make file to have -m64 to compile on 64bit
When I compile it for 64Bit this is my make output: ... But when I try and use the 64Bit version of pamtester it core dumps.
Well... gdb should help to track it down.
Any suggestions on what to do with gdb or to debug this problem??
$ gdb --args ./pamtester jpam peter authenticate (gdb) run (gdb) bt
I've seen a number of posts such as this one: http://networking.itags.org/networking-tech/58575/
Talking about changing the typedef for md5.h
-#define uint32 u_int32_t +#define uint32 uint32_t
However 1.3.17 already seems to have this patch.
struct MD5Context { uint32_t buf[4]; uint32_t bits[2]; unsigned char in[64]; };
I'm no C developer so not sure where to go to from here.
I don't have a 64-bit Solaris machine, so I can't help much. Alan DeKok.
On Wed, Sep 22, 2010 at 6:06 PM, Alan DeKok <aland@deployingradius.com>wrote:
Any suggestions on what to do with gdb or to debug this problem??
$ gdb --args ./pamtester jpam peter authenticate (gdb) run (gdb) bt
This is what I get back: (gdb) run Starting program: /usr/local/bin/sparcv9/pamtester jpam peter authenticate procfs:4337 -- process not stopped. procfs: ...giving up... (gdb) bt procfs: couldn't find pid 7326 (kernel thread 1) in procinfo list. procfs: couldn't find pid 7326 (kernel thread 1) in procinfo list. If I try it on the 32bit version I get: (gdb) run Starting program: /usr/local/bin/pamtester jpam peter authenticate (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) Password: pamtester: successfully authenticated Program exited normally. (gdb) quit
I'm no C developer so not sure where to go to from here.
I don't have a 64-bit Solaris machine, so I can't help much.
Pretty much all sparc machines have been 64Bit for a very long time, so if you have a sparc machine it's probably 64bit just need to add the -m64 on the complier switches. I can also sort out remote access into a machine. Just e-mail me directly. Cheers for the response. Peter
Peter Lambrechtsen wrote:
This is what I get back:
(gdb) run Starting program: /usr/local/bin/sparcv9/pamtester jpam peter authenticate procfs:4337 -- process not stopped. procfs: ...giving up... (gdb) bt procfs: couldn't find pid 7326 (kernel thread 1) in procinfo list. procfs: couldn't find pid 7326 (kernel thread 1) in procinfo list.
Well... that's an issue for Solaris && gdb documentation, unfortunately. Alan DeKok.
On Wed, Sep 22, 2010 at 9:55 PM, Alan DeKok <aland@deployingradius.com>wrote:
Peter Lambrechtsen wrote:
This is what I get back:
(gdb) run Starting program: /usr/local/bin/sparcv9/pamtester jpam peter authenticate procfs:4337 -- process not stopped. procfs: ...giving up... (gdb) bt procfs: couldn't find pid 7326 (kernel thread 1) in procinfo list. procfs: couldn't find pid 7326 (kernel thread 1) in procinfo list.
Well... that's an issue for Solaris && gdb documentation, unfortunately.
Yes, it seems to be an odd quirk when compiling code on Solaris 9, and running it on Solaris 10. I was hoping to have a module that would work on both, but that is looking less likely. I've got PADL pam_ldap working fine compiled on 9 and working on 10 for both 32Bit and 64Bit. So I am trying to figure out what gcc and / or ld switch is missing that is causing it to not work. Otherwise I will just install gcc on the box and recompile on solaris 10.
On Wed, Sep 22, 2010 at 10:55 PM, Alan DeKok <aland@deployingradius.com>wrote:
Peter Lambrechtsen wrote:
This is what I get back:
(gdb) run Starting program: /usr/local/bin/sparcv9/pamtester jpam peter authenticate procfs:4337 -- process not stopped. procfs: ...giving up... (gdb) bt procfs: couldn't find pid 7326 (kernel thread 1) in procinfo list. procfs: couldn't find pid 7326 (kernel thread 1) in procinfo list.
Well... that's an issue for Solaris && gdb documentation, unfortunately.
We have debugged this partially, and are trying to apply patches to Solaris to find out what's going on. It seems around like 734 in pam_radius_auth.c: if ((hp = gethostbyname(hostname)) == (struct hostent *) NULL) { ipaddr = 0x00000000; /* no client IP address */ } else { ipaddr = ntohl(*(UINT4 *) hp->h_addr); /* use the first one available */ } That gethostbyname returns an h_addr IP address of "0.0.0.1" on our solaris box when running in 64Bit, but not in 32Bit. The box has IPV6 fully disabled so we are not sure why it's doing that. Otherwise we many to using gethostbyname_r rather than gethostbyname and get it working that way I'll submit a patch. And use the get_ipaddr function at line 242 only once rather than having two seprate places where gethostbyname is called to return an IP Address Cheers Peter
Peter Lambrechtsen wrote:
It seems around like 734 in pam_radius_auth.c:
if ((hp = gethostbyname(hostname)) == (struct hostent *) NULL) { ipaddr = 0x00000000; /* no client IP address */ } else { ipaddr = ntohl(*(UINT4 *) hp->h_addr); /* use the first one available */ }
That gethostbyname returns an h_addr IP address of "0.0.0.1" on our solaris box when running in 64Bit, but not in 32Bit. The box has IPV6 fully disabled so we are not sure why it's doing that.
Ah... "0.0.0.1" is "::1" in IPv6. OK, the module *should* check the "h_addrtype" field. It's not doing that right now.
Otherwise we many to using gethostbyname_r rather than gethostbyname and get it working that way I'll submit a patch. And use the get_ipaddr function at line 242 only once rather than having two seprate places where gethostbyname is called to return an IP Address
OK, thanks. Alan DeKok.
Interestingly it seems to have come down to how UINT4 was defined. Changing in the radius.h UINT4 from being a unsigned long to a unit32_t seemed to have sorted the problem: -------Begin Patch --- radius.h.orig Fri Sep 24 15:17:05 2010 +++ radius.h Wed Sep 29 10:56:36 2010 @@ -36,7 +36,7 @@ #define AUTH_STRING_LEN 128 /* maximum of 254 */ #ifndef UINT4 -typedef unsigned long UINT4; +typedef uint32_t UINT4; #endif typedef struct pw_auth_hdr { -------End Patch That has seemed to sort the problem. On Tue, Sep 28, 2010 at 8:31 PM, Alan DeKok <aland@deployingradius.com>wrote:
Peter Lambrechtsen wrote:
It seems around like 734 in pam_radius_auth.c:
if ((hp = gethostbyname(hostname)) == (struct hostent *) NULL) { ipaddr = 0x00000000; /* no client IP address */ } else { ipaddr = ntohl(*(UINT4 *) hp->h_addr); /* use the first one available */ }
That gethostbyname returns an h_addr IP address of "0.0.0.1" on our solaris box when running in 64Bit, but not in 32Bit. The box has IPV6 fully disabled so we are not sure why it's doing that.
Ah... "0.0.0.1" is "::1" in IPv6.
OK, the module *should* check the "h_addrtype" field. It's not doing that right now.
Otherwise we many to using gethostbyname_r rather than gethostbyname and get it working that way I'll submit a patch. And use the get_ipaddr function at line 242 only once rather than having two seprate places where gethostbyname is called to return an IP Address
OK, thanks.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Peter Lambrechtsen wrote:
Interestingly it seems to have come down to how UINT4 was defined.
Changing in the radius.h UINT4 from being a unsigned long to a unit32_t seemed to have sorted the problem:
OK. That change should have been made long ago. Any system which doesn't have "uint32_t" is 6-7 years old, and not worth supporting in the mainstream release. Alan DeKok.
participants (2)
-
Alan DeKok -
Peter Lambrechtsen