WPA2 Enterprise PEAP MSCHAPv2 connection problem

[Dan Williams]

On Tue, 2009-11-17 at 22:54 +0200, Jouni Malinen wrote:
> On Sun, Nov 15, 2009 at 05:49:13PM -0500, Alistair Tonner wrote:
> > I'm trying (still) to connect to a corporate wifi installation that is 
> > painless on winders and is based on (afaik) cisco AP's, and a connection
> > to AD across RADIUS server(s)
> 
> >         eap=PEAP
> >         identity="user.name at corp.win.domain"
> >         anonymous_identity="user.name"
> 
> Have you tested this without the anonymous_identity parameter? Some PEAP
> servers may not like the different identity used in Phase 1 and Phase 2.
> 
> >         ca_cert2="/etc/ssl/certs/cert_from_wisma_server.cer"
> >         ca_path2="/etc/ssl/certs"
> >         phase2="auth=MSCHAPV2"
> 
> Since you are not using EAP-TLS in phase2, the trusted CA configuration
> should be for phase1, i.e., it would be either ca_cert or ca_path.
> Please also note that you can only set one of the ca_cert or ca_path

Are ca_cert and ca_path really mutually exclusive?  The config file
documentation (for 0.6.8 at least) for ca_path says:

"ca_cert may also be included in that case, but it is not required."

Dan

> options. Anyway, I do not think that this would be the reason for the
> failure (but it would reduce the security since the current
> configuration would not make the client verify the server certificate).
> 
> 
> > The following is from a connection attempt with -d and I assume is
> > telling me that something is broken, but I've no idea *what* is broken.
> 
> > EAP-PEAP: Encrypting Phase 2 data - hexdump(len=34):
> > [REMOVED]                                                                                                          
> > SSL: 90 bytes left to be sent out (of total 90
> > bytes)                                                                                                                   
> 
> > TX EAPOL:
> > dst=00:19:2f:32:29:20                                                                                                                                         
> 
> > RTM_NEWLINK: operstate=0 ifi_flags=0x1003
> > ([UP])                                                                                                                        
> > RTM_NEWLINK, IFLA_IFNAME: Interface 'wlan0'
> > added                                                                                                                       
> > Wireless event: cmd=0x8b15 len=24   
> > <SNIP>
> 
> What happened after this? This event could be disconnect event, but the
> log excerpt here is not long enough to confirm that.
>