Actually, studying further, it looks like when drv->device_ap_sme is set to 1 (which is the case with my full MAC driver) the monitor interface is explicitly disabled and we don’t call nl80211_mgmt_subscibe_ap(). So it appears that cfg80211 APIs are always used for receiving management frames and poll command/TX status support doesn’t matter.
Is my understanding correct?
Thanks,
Joel
> On Oct 31, 2016, at 1:39 PM, Joel Cunningham <joel.cunningham@xxxxxx> wrote:
>
> Hi,
>
> I have a question about the monitor interface that is used by driver_nl80211.c. I’m working with a vendor driver that implements a full MAC (thus does not use mac80211). Is it possible to skip using the monitor interface if poll command and TX status are supported and management frames are reported through cfg80211_rx_mgmt()?
>
> I ask because when studying driver_nl80211.c, it seems that code paths which are used when use_monitor is 0 are specific to mac80211. For example in nl80211_mgmt_subscribe_ap() we skip registering for beacon frames.
>
> static const int stypes[] = {
> WLAN_FC_STYPE_AUTH,
> WLAN_FC_STYPE_ASSOC_REQ,
> WLAN_FC_STYPE_REASSOC_REQ,
> WLAN_FC_STYPE_DISASSOC,
> WLAN_FC_STYPE_DEAUTH,
> WLAN_FC_STYPE_PROBE_REQ,
> /* Beacon doesn't work as mac80211 doesn't currently allow
> * it, but it wouldn't really be the right thing anyway as
> * it isn't per interface ... maybe just dump the scan
> * results periodically for OLBC?
> */
> /* WLAN_FC_STYPE_BEACON, */
> };
>
> Thanks,
>
> Joel
>
>
> _______________________________________________
> Hostap mailing list
> Hostap@xxxxxxxxxxxxxxxxxxx
> http://lists.infradead.org/mailman/listinfo/hostap
_______________________________________________
Hostap mailing list
Hostap@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/hostap
