Error while enabling AP using wpa_supplicant
Jouni Malinen
j at w1.fi
Sun Jan 29 07:27:21 PST 2017
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
More information about the Hostap
mailing list