(RADIATOR) CHAP works, PAP doesn't

[Gerard Ranke]

Hello everybody,

We have this strange problem where our users can authenticate via CHAP, but not
via PAP. I believe this has been bugging us at least since Radiator 2.16.1, but
it only became apparent since our ISP changed their dialup hardware, and their
default went from CHAP to PAP. Now our Macintosh users are in trouble, since
they can't force their ppp client to only accept CHAP.
Here's some background info:

Our Radiator version is now 3.3.1.
We authenticate our users from flat file <AuthBy FILE> with clear text
passwords.
Testing locally with radpwtst works ok for both PAP and CHAP.
As said, when dialing in via our ISP, everything is fine as long as you use
CHAP, which has me believing that the shared secrets are configured correctly
on both our and our ISP's radius servers.
Clients that try to authenticate via PAP through our ISP have rubbish where
their password should be in the PasswordLogFile. I don't believe it's just
encoded, since it really messes up the PasswordLogFile itself.

When searching through the mailing list archive, I came across an issue with
similar symptoms, where some NAS-'s would have problems with long secrets with
'foreign' characters in them. So we changed the secrets and made them 8
characters long, but it didn't have any affect. Setting the trace level to 4
didn't show me anything new, just rubbish where the password should have been.
So I'm kinda stuck here, and any comments on this would be very much
appreciated. Thanks for time reading this!

Gerard Ranke
cc
Utrecht School of Arts
The Netherlands

-- 

===
Archive at http://www.open.com.au/archives/radiator/
Announcements on radiator-announce at open.com.au
To unsubscribe, email 'majordomo at open.com.au' with
'unsubscribe radiator' in the body of the message.