intermittent eap authentication failure

intermittent eap authentication failure

[Chuck Crisler]

I am running wpa_supplicant v. 0.6.10. I am having a problem remaining on a 
network with PEEP authentication. I can initially get on the network but 
then fail with the first session timeout sent by the AP. Sometimes if the 
ESS is hidden I will have a subsequent probe request fail, causing me to 
re-start the entire process, which will then succeed, only to fail with the 
next session timeout.

Sometime ago I found a conflict between the supplicant and the MAC80211 code 
dealing with Cisco session timeouts. When we were 'deauthenticated', the MAC 
code notified the supplicant AND re-associated with the AP. When the driver 
got the association response, it then notified the supplicant, which was in 
the process of running a scan, which had often already been sent to the 
driver, causing a mess. We modified the driver so that if it received a 
de-auth with reason code 1 (undefined?), it would *NOT* notify the 
supplicant but would re-associate, then notify the supplicant of the new 
association. We modified the supplicant so that when it was in the completed 
state and received an association event, it went through the disassociation 
sequence of calls, then proceeded with whatever was remaining for the 
authentication. Later we determined that we could receive the deauth with a 
reason code = 4 also, so that was added.
Specifically, this is what we do with a COMPLETED->ASSOCIATED transition in 
wpa_supplicant_event_assoc in events.c:

wpa_clear_keys(wpa_s, wpa_s->bssid);
eapol_sm_notify_portEnabled(wpa_s->eapol, FALSE);
eapol_sm_notify_portValid(wpa_s->eapol, FALSE);
if (wpa_key_mgmt_wpa_psk(wpa_s->key_mgmt))
    eapol_sm_notify_eap_success(wpa_s->eapol, FALSE);
wpa_sm_set_config(wpa_s->eapol, NULL, NULL);
wpa_s->new_connection = 1;

This works fine with WPA/WPA2, but seems to fail with PEEP and (I guess) the 
other EAP methods. I don't know EAP well enough yet to understand why this 
is failing or what I need to do to make WPA/WPA2 and EAP all work. Would 
someone please shed some light on this for me?

Thank you,
Chuck Crisler 

Re: intermittent eap authentication failure

[Johannes Berg]

Chuck,

> Sometime ago I found a conflict between the supplicant and the MAC80211 code 
> dealing with Cisco session timeouts. When we were 'deauthenticated', the MAC 
> code notified the supplicant AND re-associated with the AP.

That doesn't seem right, mac80211 will never re-associate by itself.

> We modified the driver so that if it received a 
> de-auth with reason code 1 (undefined?), it would *NOT* notify the 
> supplicant but would re-associate, then notify the supplicant of the new 
> association. 

What's that driver you're talking about? A mac80211 driver that
reassociates by itself doesn't seem right at all.

johannes

Re: intermittent eap authentication failure

[Chuck Crisler]

It is the MAC80211 code. I am looking to find the exact code that 
re-associates. We are running an old kernel (2.6.31.6) but can't update 
right now.

Our app is a mobile video conferencing system (a robot). It is imperative 
that my connection to the network always be good. When you get  a session 
timeout from the AP there isn't any reason to do a scan. The MAC driver can 
send the association request and then notify the supplicant when it receives 
the assosication response. The supplicant can then handle the higher layer 
authentication. With the minor supplicant change that I included earler this 
works with all authentication schemes. However, I have removed the 2 lines 
that dealt with setting the EAP authentication to NULL. I think that they 
were causing the EAP problems. The result is that now I re-connect after a 
session timeout withint 0.75 seconds.

Another problem that I found is that sometimes (not often) the Cisco WLC was 
sending us a second deauthentication while we were still 'disconnected'. The 
MAC driver dutifully sent that to the supplicant which was busy trying to 
re-authenticate, again causing a mess. Now, I have changed the MAC driver to 
drop that second deauth message if we aren't connected. It works a lot 
better.

The response that Daniel Halperin made to Larry Finger concerning the reason 
code 4 (inactivity) isn't correct. That may be the intent but Cisco sends 
that reason code more often. I have received it withint 3 seconds of 
receiving an association response. Again, not often but it does happen. I am 
currently working to understand why the Cisco WLC does this and have 
extensive logging enabled on my WLC. Unfortuantely, all of the failures are 
occurring after the WLC times out my putty session!

More to come.

----- Original Message ----- 
From: "Johannes Berg" <johannes@sipsolutions.net>
To: "Chuck Crisler" <ccrisler@vgocom.com>
Cc: <linux-wireless@vger.kernel.org>
Sent: Tuesday, January 18, 2011 5:52 AM
Subject: Re: intermittent eap authentication failure


> Chuck,
>
>> Sometime ago I found a conflict between the supplicant and the MAC80211 
>> code
>> dealing with Cisco session timeouts. When we were 'deauthenticated', the 
>> MAC
>> code notified the supplicant AND re-associated with the AP.
>
> That doesn't seem right, mac80211 will never re-associate by itself.
>
>> We modified the driver so that if it received a
>> de-auth with reason code 1 (undefined?), it would *NOT* notify the
>> supplicant but would re-associate, then notify the supplicant of the new
>> association.
>
> What's that driver you're talking about? A mac80211 driver that
> reassociates by itself doesn't seem right at all.
>
> johannes
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" 
> in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: intermittent eap authentication failure

[Chuck Crisler]

I will have to reply later about why it is associating. I will have to add a 
printk to my driver but I currently have 2 tests running and don't want to 
stop either.
It looks like it might be called by ieee80211_sta_work() in mlme.c because 
it might still be in the IEEE80211_STA_MLME_ASSOCIATE state. I will confirm 
that.

Chuck
----- Original Message ----- 
From: "Chuck Crisler" <ccrisler@vgocom.com>
To: "Johannes Berg" <johannes@sipsolutions.net>
Cc: <linux-wireless@vger.kernel.org>
Sent: Tuesday, January 18, 2011 9:33 AM
Subject: Re: intermittent eap authentication failure


> It is the MAC80211 code. I am looking to find the exact code that 
> re-associates. We are running an old kernel (2.6.31.6) but can't update 
> right now.
>
> Our app is a mobile video conferencing system (a robot). It is imperative 
> that my connection to the network always be good. When you get  a session 
> timeout from the AP there isn't any reason to do a scan. The MAC driver 
> can send the association request and then notify the supplicant when it 
> receives the assosication response. The supplicant can then handle the 
> higher layer authentication. With the minor supplicant change that I 
> included earler this works with all authentication schemes. However, I 
> have removed the 2 lines that dealt with setting the EAP authentication to 
> NULL. I think that they were causing the EAP problems. The result is that 
> now I re-connect after a session timeout withint 0.75 seconds.
>
> Another problem that I found is that sometimes (not often) the Cisco WLC 
> was sending us a second deauthentication while we were still 
> 'disconnected'. The MAC driver dutifully sent that to the supplicant which 
> was busy trying to re-authenticate, again causing a mess. Now, I have 
> changed the MAC driver to drop that second deauth message if we aren't 
> connected. It works a lot better.
>
> The response that Daniel Halperin made to Larry Finger concerning the 
> reason code 4 (inactivity) isn't correct. That may be the intent but Cisco 
> sends that reason code more often. I have received it withint 3 seconds of 
> receiving an association response. Again, not often but it does happen. I 
> am currently working to understand why the Cisco WLC does this and have 
> extensive logging enabled on my WLC. Unfortuantely, all of the failures 
> are occurring after the WLC times out my putty session!
>
> More to come.
>
> ----- Original Message ----- 
> From: "Johannes Berg" <johannes@sipsolutions.net>
> To: "Chuck Crisler" <ccrisler@vgocom.com>
> Cc: <linux-wireless@vger.kernel.org>
> Sent: Tuesday, January 18, 2011 5:52 AM
> Subject: Re: intermittent eap authentication failure
>
>
>> Chuck,
>>
>>> Sometime ago I found a conflict between the supplicant and the MAC80211 
>>> code
>>> dealing with Cisco session timeouts. When we were 'deauthenticated', the 
>>> MAC
>>> code notified the supplicant AND re-associated with the AP.
>>
>> That doesn't seem right, mac80211 will never re-associate by itself.
>>
>>> We modified the driver so that if it received a
>>> de-auth with reason code 1 (undefined?), it would *NOT* notify the
>>> supplicant but would re-associate, then notify the supplicant of the new
>>> association.
>>
>> What's that driver you're talking about? A mac80211 driver that
>> reassociates by itself doesn't seem right at all.
>>
>> johannes
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-wireless" 
>> in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" 
> in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: intermittent eap authentication failure

[Johannes Berg]

On Tue, 2011-01-18 at 09:54 -0500, Chuck Crisler wrote:
> I will have to reply later about why it is associating. I will have to add a 
> printk to my driver but I currently have 2 tests running and don't want to 
> stop either.
> It looks like it might be called by ieee80211_sta_work() in mlme.c because 
> it might still be in the IEEE80211_STA_MLME_ASSOCIATE state. I will confirm 
> that.

Did you ever consider using compat-wireless? Frankly, my main memory
isn't large enough to hold information about old mac80211 behaviour so I
have to get that information from swap (git tree) and that's really
slow :-)

johannes

Re: intermittent eap authentication failure

[Chuck Crisler]

Yes, I am advocating for compat-wireless. But have repeated lost a political 
battle over that one. :-(

----- Original Message ----- 
From: "Johannes Berg" <johannes@sipsolutions.net>
To: "Chuck Crisler" <ccrisler@vgocom.com>
Cc: <linux-wireless@vger.kernel.org>
Sent: Tuesday, January 18, 2011 9:57 AM
Subject: Re: intermittent eap authentication failure


> On Tue, 2011-01-18 at 09:54 -0500, Chuck Crisler wrote:
>> I will have to reply later about why it is associating. I will have to 
>> add a
>> printk to my driver but I currently have 2 tests running and don't want 
>> to
>> stop either.
>> It looks like it might be called by ieee80211_sta_work() in mlme.c 
>> because
>> it might still be in the IEEE80211_STA_MLME_ASSOCIATE state. I will 
>> confirm
>> that.
>
> Did you ever consider using compat-wireless? Frankly, my main memory
> isn't large enough to hold information about old mac80211 behaviour so I
> have to get that information from swap (git tree) and that's really
> slow :-)
>
> johannes
>
> 

Re: intermittent eap authentication failure

[Chuck Crisler]

What is the reason that the design calls for a scan in response to a session 
timeout? A session timeout doesn't happen because of a roam, so the original 
AP is probably still good. Why scan?

Chuck

----- Original Message ----- 
From: "Johannes Berg" <johannes@sipsolutions.net>
To: "Chuck Crisler" <ccrisler@vgocom.com>
Cc: <linux-wireless@vger.kernel.org>
Sent: Tuesday, January 18, 2011 9:57 AM
Subject: Re: intermittent eap authentication failure


> On Tue, 2011-01-18 at 09:54 -0500, Chuck Crisler wrote:
>> I will have to reply later about why it is associating. I will have to 
>> add a
>> printk to my driver but I currently have 2 tests running and don't want 
>> to
>> stop either.
>> It looks like it might be called by ieee80211_sta_work() in mlme.c 
>> because
>> it might still be in the IEEE80211_STA_MLME_ASSOCIATE state. I will 
>> confirm
>> that.
>
> Did you ever consider using compat-wireless? Frankly, my main memory
> isn't large enough to hold information about old mac80211 behaviour so I
> have to get that information from swap (git tree) and that's really
> slow :-)
>
> johannes
>
> 

Re: intermittent eap authentication failure

[Johannes Berg]

On Tue, 2011-01-18 at 10:21 -0500, Chuck Crisler wrote:
> What is the reason that the design calls for a scan in response to a session 
> timeout? A session timeout doesn't happen because of a roam, so the original 
> AP is probably still good. Why scan?

I don't think there's any design here, and in any case that's
wpa_supplicant's doing. :)

johannes

Re: intermittent eap authentication failure

[Chuck Crisler]

The deauth reason code isn't passed up to the supplicant, so the supplicant 
doesn't have the best info to make a decision. If the notification message 
was changed to include the reason code, then the supplicant wouldn't need to 
do a scan in this case, which makes everything faster (unless you have 
accurate scan results from a background scan). Dropping a scan means 
everything works much faster.

Background scans probably won't work for our app because we are transmitting 
about 2-3 (sometimes more) good sized data packets every ~40 msec. We would 
have to drop video frames to make room for background scanning, but that 
degrades the video quality, and that is noticeable.

Chuck
----- Original Message ----- 
From: "Johannes Berg" <johannes@sipsolutions.net>
To: "Chuck Crisler" <ccrisler@vgocom.com>
Cc: <linux-wireless@vger.kernel.org>
Sent: Tuesday, January 18, 2011 10:23 AM
Subject: Re: intermittent eap authentication failure


> On Tue, 2011-01-18 at 10:21 -0500, Chuck Crisler wrote:
>> What is the reason that the design calls for a scan in response to a 
>> session
>> timeout? A session timeout doesn't happen because of a roam, so the 
>> original
>> AP is probably still good. Why scan?
>
> I don't think there's any design here, and in any case that's
> wpa_supplicant's doing. :)
>
> johannes
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" 
> in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: intermittent eap authentication failure

[Johannes Berg]

On Tue, 2011-01-18 at 10:33 -0500, Chuck Crisler wrote:
> The deauth reason code isn't passed up to the supplicant, 

With -Dnl80211 it should be, no?

johannes