Hi,
Commit 1204aa17f3b4 ("brcmfmac: set WIPHY_FLAG_HAVE_AP_SME flag")
appears to have broken hostapd 2.4, thereby causing a user visible
regression when upgrading across the 4.18 boundary (e.g. 4.13 to
4.19).
The presence of this flag causes nl80211 to add an additional
attribute to the netlink wiphy reply:
if ((rdev->wiphy.flags & WIPHY_FLAG_HAVE_AP_SME) &&
nla_put_u32(msg, NL80211_ATTR_DEVICE_AP_SME,
rdev->wiphy.ap_sme_capa))
goto nla_put_failure;
which is then parsed by hostapd using a presence/absence test for
this property (the value of the property is meaningless):
nla_parse(tb, NL80211_ATTR_MAX, genlmsg_attrdata(gnlh, 0),
genlmsg_attrlen(gnlh, 0), NULL);
...
if (tb[NL80211_ATTR_DEVICE_AP_SME])
info->device_ap_sme = 1;
This causes hostapd to then attempt to subscribe to management
frames (via nl80211_mgmt_subscribe_ap_dev_sme()):
if (nl80211_register_frame(bss, bss->nl_mgmt,
(WLAN_FC_TYPE_MGMT << 2) |
(WLAN_FC_STYPE_ACTION << 4),
NULL, 0) < 0)
and brcmfmac does not support passing any management frames in AP
mode (brcmf_txrx_stypes[NL80211_IFTYPE_AP] is empty). That causes
nl80211_register_frame() to fail, and hostapd fails to initialise.
Checking the hostapd versions (including up to 2.7) shows that
nothing has changed, so this change has broken the ability for
hostapd to be used with brcmfmac - thereby causing a user-visible
regression.
Can this commit be reverted to fix this regression please?
Thanks.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
