Re: Panic in ieee80211 tx mgmt timeout

From: Stefan Esser <se_at_freebsd.org>
Date: Wed, 29 Jun 2011 11:03:48 +0200
On 29.06.2011 10:27, Bernhard Schmidt wrote:
> On Wednesday, June 29, 2011 10:03:02 Adrian Chadd wrote:
>> On 29 June 2011 14:03, Bernhard Schmidt <bschmidt_at_freebsd.org> wrote:
>>
>>> It's name is ieee80211_tx_mgt_timeout used to track AUTH/ASSOC
>>> requests. Afaik there is even a similar PR about that.
>>>
>>> Adrian, you've got a AP set up to drop either a AUTH or ASSOC
>>> response frame?
>>
>> Tell me how and I'll set it up.
>>
>> A panic at that point in the function indicates maybe ni is NULL?
>> or ni->vap is now NULL, maybe?
> 
> vap should never be NULL, so, I'd guess it's ni.

No, neither vap no vap->ni appear to cause NULL dereferences.

The panic message indicates a fault address of 0xffffff809c7a1000, which
is the value of arg passed to ieee80211_tx_mgt_timeout().

The fault occurs on the first instruction within that function and I
take this to mean, that it points outside kernel VM space. (I have got
to admit, that I do not know the exact memory layout for amd64, though.)

> Hmm.. I'd guess there is some kind of racy behavior, if the driver is
> telling us that it was able to send the AUTH req frame, net80211 sets
> up the timeout callback. What happens if the AUTH resp as well as the
> callback hit at the same time? It should be locked appropriately, but
> is it?
> 
> This will drop the AUTH response:

I have received a number of messages that might indicate a lost race:

ieee80211_new_state_locked: pending AUTH -> SCAN transition lost

repeats with between a few seconds and 20 minutes between messages.

> Index: sys/net80211/ieee80211_hostap.c
> ===================================================================
> --- sys/net80211/ieee80211_hostap.c	(revision 223661)
> +++ sys/net80211/ieee80211_hostap.c	(working copy)
> _at__at_ -978,7 +978,7 _at__at_ hostap_auth_open(struct ieee80211_node *ni, struct
>  		    "%s", "station authentication defered (radius acl)");
>  		ieee80211_notify_node_auth(ni);
>  	} else {
> -		IEEE80211_SEND_MGMT(ni, IEEE80211_FC0_SUBTYPE_AUTH, seq + 1);
> +		//IEEE80211_SEND_MGMT(ni, IEEE80211_FC0_SUBTYPE_AUTH, seq + 1);
>  		IEEE80211_NOTE_MAC(vap,
>  		    IEEE80211_MSG_DEBUG | IEEE80211_MSG_AUTH, ni->ni_macaddr,
>  		    "%s", "station authenticated (open)");
> _at__at_ -1158,7 +1158,7 _at__at_ hostap_auth_shared(struct ieee80211_node *ni, stru
>  		estatus = IEEE80211_STATUS_SEQUENCE;
>  		goto bad;
>  	}
> -	IEEE80211_SEND_MGMT(ni, IEEE80211_FC0_SUBTYPE_AUTH, seq + 1);
> +	//IEEE80211_SEND_MGMT(ni, IEEE80211_FC0_SUBTYPE_AUTH, seq + 1);
>  	return;
>  bad:
>  	/*
> 
> 

I could try that patch for a few hours ...

Regards, STefan
Received on Wed Jun 29 2011 - 07:16:20 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:15 UTC