Hi Kalle, Mac80211 tries to verify the existence of the current AP by probing or sending a NULL frame (function: ieee80211_mgd_probe_ap_send). It 1st sends a null frame to the AP increments probe_send_count and waits for the ACK to the NULL frame for a finite duration of time. Normally, the sequence of events will be - a. call ieee80211_send_nullfunc() b. increment probe_send_count ( this indicates probing is underway) c. null frame gets transmitted and acked, so mac80211 resets probe_send_count and concludes that the current is still alive. In some cases the sequence of events gets changed - a. call ieee80211_send_nullfunc() (current thread gets scheduled out/pre-empted at this point) b. null frame gets transmitted and acked c. probe_send_count is incremented d. mac80211 waits for some specified timeout and checks that probe_send_count is still > 0. It concludes that AP did not acknowledge the null frame and disassociates from the current AP. e. After a scan STA again re-associate with the same AP. Btw, this verification of current AP by sending null frame occurs after every scan. Regards, Soumik -----Original Message----- From: Kalle Valo [mailto:kvalo@xxxxxxxxxx] Sent: Thursday, May 10, 2012 12:41 PM To: Soumik DAS Cc: John Linville; linux-wireless; Johannes Berg Subject: Re: [PATCH] mac80211: Increment probe_send_count earlier Hi Soumik, Soumik DAS <soumik.das@xxxxxxxxxxxxxx> writes: > At times, null frame gets transmitted and acked before mac80211 gets > to increment probe_send_count. This leads to a situation where > mac80211 waits for ack to null frame, but no ack comes causing > unnecessary disconnection. Can explain a bit more about the scenario when this happens, please? It's not clear for me from the patch. -- Kalle Valo -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
