Shared secret is wrong, except that it isn't?

[Seferovic Edvin]

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: freeradius-users-bounces+edvin.seferovic=kolp.at at lists.freeradius.org
[mailto:freeradius-users-bounces+edvin.seferovic=kolp.at at lists.freeradius.or
g] On Behalf Of Peter Seebach
Sent: Mittwoch, 29. März 2006 21:49
To: freeradius-users at 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