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 [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
