Meyers, Dan wrote:
Secondly, my colleague's machine actually responds to the Access-Challenge sent at the end of the packet where the ntlm_auth is done, whereas my machine does not. This is the crucial point I think. Without this final response the Access-Accept is never sent back. My colleague is using Windows XP with the Intel Pro/Set Wireless drivers and supplicant. If he changes to using the XP inbuilt supplicant, everything stops working. I am on Windows 7 using the inbuilt supplicant. As best we can tell, this is the problematic difference. The Intel supplicant is presumably getting and responding to the Access-Challenge where the windows inbuilt supplicant is not, but I don't know why or what could be causing it. My machine also doesn't respond to the Access-Challenge under Ubuntu 9.10, using the Gnome inbuilt supplicant. This is most likely a CA cert problem. The comments in the default "eap.conf" give a very specific warning about this (access-challenge which is never replied to) and explain the issue.
This being the case, why does my machine successfully respond to all the other Access-Challenges before the MSCHAPv2 password is dealt with? The trace I gave was for an Access-Challenge id 107. Ids 100 (my initial
Ok, good point. It wasn't readily apparent to me what in the "wall of text" (as you put it!) was the failing session and what was the succeeding one. Sorry for the noise. As per Ivan's suggestion, it must be Samba mis-calculating the MSCHAP response in that case.