On Fri, Jan 27, 2017 at 02:32:04PM +0000, Jose Blanquicet wrote: > After commit a70cd0db876b2ffad7e3d608e3f9a2fcf2e7a879, it is not > possible to enable AP mode using wpa_supplicant. Which driver are you testing with? This works fine in mac80211_hwsim test cases. Can you provide a debug log showing the full initialization with and without this commit included? > It is failing when calling nl80211_get_wiphy_data_ap() added by this > patch on wpa_driver_nl80211_set_ap(): > > if (beacon_set) > cmd = NL80211_CMD_SET_BEACON; > + else if (!nl80211_get_wiphy_data_ap(bss)) > + return -ENOBUFS; > > In this patch nl80211_get_wiphy_data_ap call was moved from > nl80211_mgmt_subscribe_ap to nl80211_get_wiphy_data_ap, resulting in a > premature call. Could you please clarify what you mean with premature in this context? The nl80211_get_wiphy_data_ap() call was moved to a later point in the process, not earlier, i.e., it used to be immediately after the management frame registration steps while it is now after that and channel configuration. Similarly, the nl80211_register_beacons() call and NL80211_CMD_REGISTER_BEACONS command gets pushed out to happen after channel configuration. That is the operation that your log seemed to indicate as failing with EOPNOTSUPP. As far as cfg80211 is concerned, nl80211_register_beacons() returns -EOPNOTSUPP only if the wiphy does not support WIPHY_FLAG_REPORTS_OBSS. I don't see how that could differ based on whether this operation happens before or after channel configuration. -- Jouni Malinen PGP id EFC895FA _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap