RE: Shared secret is wrong, except that it isn't?
Hi Peter, I had same issue on Suse 9.1/64bit version. Some stupid library was broken ( I think the LIBLTDL = /usr/lib64/libltdl.so was wrong ). That had the whole stuff messed up. Since I am not familiar with NetBSD, maybe you should consider asking the same question on their mailing list about this lib and linking with freeradius. Regards, Edvin -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] g] On Behalf Of Peter Seebach Sent: Mittwoch, 29. März 2006 21:49 To: freeradius-users@lists.freeradius.org Subject: Shared secret is wrong, except that it isn't? Okay, I'm sorta stumped here. I'm getting the exact behavior described for "shared secret is wrong", but I am pretty confident that it isn't. FreeRadius 1.1.1, installed on NetBSD 3.0/amd64. Synopsis: No matter how cleverly I try to make sure I have the right shared secret, I get garbage passwords. My clients file says: 127.0.0.1 foobar I'm using radtest: radtest user pw localhost 10 foobar I get: auth: type "System" Processing the authenticate section of radiusd.conf modcall: entering group authenticate for request 0 rlm_unix: [beta1]: invalid password modcall[authenticate]: module "unix" returns reject for request 0 modcall: leaving group authenticate (returns reject) for request 0 auth: Failed to validate the user. WARNING: Unprintable characters in the password. ? Double-check the shared secret on the server and the NAS! There are no unprintable characters in the password I'm sending. So. The one thing I can think of is the 64-bit environment, because an old version of cistron-radiusd I was skimming once had a comment about assumptions about the size of long and the size of (void *). However, even then, I would expect that a radtest and a radiusd built and running on the same server would, even if they were doing it wrong, do it wrong in precisely compatible ways! So, uhm. Where exactly is this encryption happening? It looks like lib/radius.c is the place where shared secrets are used, but the code seems to be substantially different from the cistron code I vaguely remember from way back when. In particular, I don't remember this MD5 stuff... -s - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Shared secret is wrong, except that it isn't?
In message <[EMAIL PROTECTED]>, Josh Howlett writes: >Have you tried putting the secret in clients.conf? I thought the clients >file was deprecated. I haven't, and you're probably right that it is. I'll have a look at that. -s - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Shared secret is wrong, except that it isn't?
Have you tried putting the secret in clients.conf? I thought the clients file was deprecated. josh. Peter Seebach wrote: Okay, I'm sorta stumped here. I'm getting the exact behavior described for "shared secret is wrong", but I am pretty confident that it isn't. FreeRadius 1.1.1, installed on NetBSD 3.0/amd64. Synopsis: No matter how cleverly I try to make sure I have the right shared secret, I get garbage passwords. My clients file says: 127.0.0.1 foobar I'm using radtest: radtest user pw localhost 10 foobar I get: auth: type "System" Processing the authenticate section of radiusd.conf modcall: entering group authenticate for request 0 rlm_unix: [beta1]: invalid password modcall[authenticate]: module "unix" returns reject for request 0 modcall: leaving group authenticate (returns reject) for request 0 auth: Failed to validate the user. WARNING: Unprintable characters in the password. ? Double-check the shared secret on the server and the NAS! There are no unprintable characters in the password I'm sending. So. The one thing I can think of is the 64-bit environment, because an old version of cistron-radiusd I was skimming once had a comment about assumptions about the size of long and the size of (void *). However, even then, I would expect that a radtest and a radiusd built and running on the same server would, even if they were doing it wrong, do it wrong in precisely compatible ways! So, uhm. Where exactly is this encryption happening? It looks like lib/radius.c is the place where shared secrets are used, but the code seems to be substantially different from the cistron code I vaguely remember from way back when. In particular, I don't remember this MD5 stuff... -s - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Shared secret is wrong, except that it isn't?
Okay, I'm sorta stumped here. I'm getting the exact behavior described for "shared secret is wrong", but I am pretty confident that it isn't. FreeRadius 1.1.1, installed on NetBSD 3.0/amd64. Synopsis: No matter how cleverly I try to make sure I have the right shared secret, I get garbage passwords. My clients file says: 127.0.0.1 foobar I'm using radtest: radtest user pw localhost 10 foobar I get: auth: type "System" Processing the authenticate section of radiusd.conf modcall: entering group authenticate for request 0 rlm_unix: [beta1]: invalid password modcall[authenticate]: module "unix" returns reject for request 0 modcall: leaving group authenticate (returns reject) for request 0 auth: Failed to validate the user. WARNING: Unprintable characters in the password. ? Double-check the shared secret on the server and the NAS! There are no unprintable characters in the password I'm sending. So. The one thing I can think of is the 64-bit environment, because an old version of cistron-radiusd I was skimming once had a comment about assumptions about the size of long and the size of (void *). However, even then, I would expect that a radtest and a radiusd built and running on the same server would, even if they were doing it wrong, do it wrong in precisely compatible ways! So, uhm. Where exactly is this encryption happening? It looks like lib/radius.c is the place where shared secrets are used, but the code seems to be substantially different from the cistron code I vaguely remember from way back when. In particular, I don't remember this MD5 stuff... -s - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html