On 30 January 2015 at 07:22, wim torfs <wtorfs@xxxxxxxxx> wrote: > On 01/29/2015 11:55 PM, Rafał Miłecki wrote: >> So I started analyzing this with the base case: mac80211 >> (ieee80211_del_station). I expected to find a place where mac80211 >> constructs deauth/disassoc management frame and transmits it. But I >> really couldn't. It seems that all ieee80211_del_station does is >> calling __sta_info_destroy / __sta_info_destroy_part1 / >> __sta_info_destroy_part2. >> Did I miss something? Or does mac80211 really ignore sending proper >> management frames in this case? > > If you look further into __sta_info_destroy, you will notice a callback to > cfg80211_del_sta (net/wireless/nl80211.c), notifying the removal of the > station information. > cfg80211_del_sta composes a netlink message, notifying everyone interested > about the removal of the station: > hdr = nl80211hdr_put(msg, 0, 0, 0, NL80211_CMD_DEL_STATION); > > In hostapd, there is a routine that monitors such netlink messages, > process_global_event, which eventually parses the CMD_DEL_STATION event in > nl80211_del_station_event, where a call is made to drv_event_disassoc if the > current device is indeed in AP mode. > So eventually, it is the hostapd that triggers the transmission of the > disassociation packet. I indeed missed the way cfg80211_del_sta works and hostapd's event handler for this. That explains a lot. I've checked ath6kl, brcmfmac and mwifiex and they don't seem to call cfg80211_del_sta. AFAIU it's because they handle sending disassoc/deauth packet on their own (and the don't want e.g. hostapd to do this), is that correct? > I hope my explanation is correct and it helps you to make things more clear. Absolutely, thanks a lot! -- Rafał -- 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
