eapol_test giving up and win-like error?

[Phil Mayers]

On 19/01/12 11:07, NdK wrote:
> Il 19/01/2012 10:03, Phil Mayers ha scritto:
>
>>> EAP: deinitialize previously used EAP method (25, PEAP) at EAP deinit
>>> MPPE keys OK: 0  mismatch: 1
>>> FAILURE
> These (plus the timeout one) are the lines printed after FR have already
> cloded session.

Yes.

>
>> Hmm. I see from your original email that Samba&  ntlm_auth are succeeding.
> Yup. I'm quite used to joining machines to AD... Already have about 100
> clients and 5 servers, and this one is the one giving me troubles :(
>
>> There are a couple of buggy version of Samba out there that return
>> invalid response values, and generate these symptoms. Which version of
>> Samba are you running, and on what OS?
> Samba 3.5.6 (latest packaged one) on Debian Squeeze. Once it's working,
> I'll have to move the config to a ZeroShell box with Samba 3.5.10.

That version should be ok; we're on 3.5.4

I'm not sure what the problem is then. From your original post, the 
authentication is failing at the *client*, in the inner EAP section. 
This normally means the final MSCHAP response is invalid, which only 
happens if some crypto has gone wrong somewhere.

>
> Another problem I should fix is the fact that ZS's captive portal passes
> user at realm credentials instead of realm\user ... rewriting w/ a simple
> rule in hints file seems to block the rest, so I left it behind, for now.

You can't alter usernames in EAP. They are usually mixed into the 
challenge/response data, and altering them in-flight means the 
challenge/response will fail.

To be honest, there's too much going on in your setup; my advice would 
be to create a new server (running 2.1.12) and use the default setup. 
Test your EAP with eapol_test. Make small changes, storing the config 
into version control at each step. Identify exactly which point the 
failures start happening at.

Most people don't see this problem, so it's something specific to your 
setup.