Strong, Mark wrote:

I get this in the debug

[chap] login attempt by "xxxxxxxxxx" with CHAP password [chap] Using clear text password "password" for user xxxxxxxxxx authentication. [chap] Password check failed

(a) the "clear text" password is wrong (b) the client isn't doing CHAP correctly. There are no other choices.

I've tried with radtest using type chap, and it works fine,

Because FreeRADIUS correctly implements CHAP, and has done so for nearly 14 years. Other people seem to have major issues with the simplest parts of the RADIUS protocol.

I'm thinking there's a problem with the access-request (but I don't control that end, it's a large Telco in AU).

Their system is broken.

What I want to know is, do I have enough attributes in this access-request for CHAP to work?

Yes. In theory. ...

I don't see one of these "CHAP-Challenge" from the NAS

And that's likely the problem. But not for the reason you may think. RFC 2865 Section 5.3 says that the CHAP-Challenge doesn't need to exist. If it doesn't exist, the 16-byte authentication vector from the Access-Request is used instead.

I'm not sure what pieces freeradius needs to munge together to come up with the same password hash that rolls in from the Telco.

FreeRADIUS needs either the CHAP-Challenge, or the *original* authentication vector. And that gives you the problem. When a packet is proxied, the authentication vector for the proxied packet is *completely* different from the input packet. When FreeRADIUS proxies a packet with CHAP-Password, it copies the original authentication vector into a CHAP-Challenge attribute. So the home server has everything it needs in order to do CHAP. RFC 2865, item (1) at the top of Page 10 says to do this, and FreeRADIUS is RFC compliant. The "large Australian telco" doesn't do that. It's broken.

I didn't post the full debug just so I didn't have to redact so much. If this access request turns out to be ok, I can post the full debug.

That's fine. You posted enough. Alan DeKok.