On 25 January 2016 at 10:49, Arend van Spriel <arend@xxxxxxxxxxxx> wrote: > On 20-1-2016 13:47, Rafał Miłecki wrote: >> Now, the problem with brcmfmac is that it doesn't report support for any >> management frames in AP mode. It supports sending ACTION (and maybe >> PROBE_RESP) frames, but it can't pass ACTION to the cfg80211. So even if >> we report we can send ACTION (as it seems we do), it won't fix the >> problem. >> >> So this patch will trigger another code path in hostapd that due to >> brcmfmac missing support for receiving & passing ACTION will fail. >> >> Do you have any idea how to handle this? > > The mgmt_tx callback in brcmfmac was added for P2P functionality. So if > anything, a check should be added to assure it is only used on P2P > interfaces. > >> Should hostapd drop depndency on ACTION frames? Should brcmfmac fake >> support for receiving & passing ACTION frames? Or should support for >> ACTION frames be added indeed? > > So why not stick with the current implementation. It may not seem > optimal to first try one thing and fallback to another, but at least it > works. I was thinking about trying with use_monitor=0, but looking in > the code nl80211_setup_ap() that will not resolve it either. I don't like current implementation as it depends on some failure, fallback & inconsistent code in hostapd. It seems hacky to me and I can imagine things going wrong on some simple hostapd change. I beliee it also doesn't allow brcmfmac to implement monitor mode, because once it's done, hostapd won't hit the same fallback path. -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
