All of lore.kernel.org
 help / color / mirror / Atom feed
* cfg80211_ops: deauthentication & disassociation
@ 2015-01-29 22:55 Rafał Miłecki
  2015-01-30  6:22 ` wim torfs
  0 siblings, 1 reply; 4+ messages in thread
From: Rafał Miłecki @ 2015-01-29 22:55 UTC (permalink / raw)
  To: linux-wireless

Hi,

I'm looking at deauthentication & disassociation with cfg80211 API.
AFAIK both frames can be send by STA as well as AP (according to the
standard). I was looking info few cfg80211 callbacks and have few
questions.

1) @disassoc
I think it's just for disassociating from AP. Is that correct?

2) @del_station
Now, this gets tricky for me. I think this callback is for AP mode to
deauthenticae/disassociate a STA. It seems hostapd follows the same
idea as in driver_nl80211.c it uses NL80211_CMD_DEL_STATION for both:
deauth and disassoc (without building own frame).

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?

On the other hand cfg80211 drivers seem to be doing something more in
the @del_station callback. E.g.:
a) wil6210 seems to be sending some frame:
wmi_send(wil, WMI_DISCONNECT_STA_CMDID, &cmd, sizeof(cmd));
b) brcmfmac does as well:
brcmf_fil_cmd_data_set(ifp, BRCMF_C_SCB_DEAUTHENTICATE_FOR_REASON,
&scbval, sizeof(scbval));
c) mwifiex as well:
mwifiex_send_cmd(priv, HostCmd_CMD_UAP_STA_DEAUTH, ...);


Can you help to understand this, please? Is @del_station handler
supposed to actually send a proper management frame?

-- 
Rafał

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: cfg80211_ops: deauthentication & disassociation
  2015-01-29 22:55 cfg80211_ops: deauthentication & disassociation Rafał Miłecki
@ 2015-01-30  6:22 ` wim torfs
  2015-01-30  8:17   ` Rafał Miłecki
  0 siblings, 1 reply; 4+ messages in thread
From: wim torfs @ 2015-01-30  6:22 UTC (permalink / raw)
  To: Rafał Miłecki; +Cc: linux-wireless

I will try to answer your question, please correct me if I'm wrong.

On 01/29/2015 11:55 PM, Rafał Miłecki wrote:
> Hi,
>
> I'm looking at deauthentication&  disassociation with cfg80211 API.
> AFAIK both frames can be send by STA as well as AP (according to the
> standard). I was looking info few cfg80211 callbacks and have few
> questions.
>
> 1) @disassoc
> I think it's just for disassociating from AP. Is that correct?
>

I also think so, since all code is located in the mlme section
Did not look into that in detail though, so I could be wrong.

> 2) @del_station
> Now, this gets tricky for me. I think this callback is for AP mode to
> deauthenticae/disassociate a STA.

correct, this is only allowed for iftypes of NL80211_IFTYPE_AP, 
NL80211_IFTYPE_AP_VLAN, NL80211_IFTYPE_MESH_POINT or 
NL80211_IFTYPE_P2P_GO. (see net/wireless/nl80211.c: nl80211_del_station)

  It seems hostapd follows the same
> idea as in driver_nl80211.c it uses NL80211_CMD_DEL_STATION for both:
> deauth and disassoc (without building own frame).
>
> 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 hope my explanation is correct and it helps you to make things more clear.

Wim.




^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: cfg80211_ops: deauthentication & disassociation
  2015-01-30  6:22 ` wim torfs
@ 2015-01-30  8:17   ` Rafał Miłecki
  2015-01-30  9:30     ` Johannes Berg
  0 siblings, 1 reply; 4+ messages in thread
From: Rafał Miłecki @ 2015-01-30  8:17 UTC (permalink / raw)
  To: wim torfs; +Cc: linux-wireless

On 30 January 2015 at 07:22, wim torfs <wtorfs@gmail.com> 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ł

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: cfg80211_ops: deauthentication & disassociation
  2015-01-30  8:17   ` Rafał Miłecki
@ 2015-01-30  9:30     ` Johannes Berg
  0 siblings, 0 replies; 4+ messages in thread
From: Johannes Berg @ 2015-01-30  9:30 UTC (permalink / raw)
  To: Rafał Miłecki; +Cc: wim torfs, linux-wireless

On Fri, 2015-01-30 at 09:17 +0100, Rafał Miłecki wrote:

> > 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?

There are two ways - AP SME in firmware, and AP SME in hostapd.

They work differently - in the former case (firmware) the AP station is
added there and hostapd gets notifications about it.

In the latter case, hostapd adds/removes all the stations.

johannes


^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2015-01-30  9:30 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-01-29 22:55 cfg80211_ops: deauthentication & disassociation Rafał Miłecki
2015-01-30  6:22 ` wim torfs
2015-01-30  8:17   ` Rafał Miłecki
2015-01-30  9:30     ` Johannes Berg

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.