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

[Josh Howlett]

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