On 23-3-2016 9:47, Rafał Miłecki wrote: > On 22 March 2016 at 21:24, Arend van Spriel > <arend.vanspriel@xxxxxxxxxxxx> wrote: >> On 22-3-2016 7:36, Rafał Miłecki wrote: >>> On 3 March 2016 at 23:37, Rafał Miłecki <zajec5@xxxxxxxxx> wrote: >>>> brcmfmac in general is not capable of removing interfaces. If you take >>>> a look at brcmf_cfg80211_del_iface implementation, you'll see it >>>> returns -EOPNOTSUPP (except for p2p interfaces). >>>> >>>> However there is problem in handling NL80211_CMD_STOP_AP (with the >>>> brcmf_cfg80211_stop_ap callback). Current implementation calls >>>> brcmf_fil_cmd_int_set(ifp, BRCMF_C_DOWN, 1) >>>> if mbss support is enabled/used. >>>> >>>> Above call results in firmware generating BRCMF_E_LINK event. This >>>> event is handled with the following forward-traced functions chain: >>>> 1) brcmf_notify_connect_status >>>> 2) brcmf_notify_connect_status_ap >>>> 3) brcmf_remove_interface >>>> 4) brcmf_del_if >>>> 5) brcmf_net_detach >>>> 6) unregister_netdev >>>> >>>> So the result of NL80211_CMD_STOP_AP is interface being removed. The >>>> problem with this behavior is that interface can't be recreated after >>>> that: >>>> # iw phy phy1 interface add wlan1-1 type __ap >>>> [ 3602.929199] brcmfmac: brcmf_ap_add_vif: timeout occurred >>>> command failed: I/O error (-5) >>>> >>>> I hit this problem when trying to restart hostapd using BCM43602 and 2 BSSes. >>>> >>>> Could you analyze this problem and see if you see some way of solving >>>> this problem, please? >>> >>> Hi, any ideas / help regarding this issue? >> >> Restarting hostapd obviously is a valid scenario. My guess is we would >> need to avoid interface removal in brcmf_notify_connect_status_ap. But >> first I would like to know in which state the firmware is upon >> brcmf_ap_add_vif. Can you provide a full log with FWCON debug level enabled? > > Sure, hope it helps! Ah. Actually would like to see some driver logging as well so 'debug=0x101410'. > 3) killall hostapd > [ 234.424528] device wlan1-1 left promiscuous mode > [ 234.429453] br-lan: port 3(wlan1-1) entered disabled state > [ 234.842185] brcmfmac: CONSOLE: 026816.727 wl0: link down (wl0) > [ 234.842224] brcmfmac: CONSOLE: 026816.727 wl0: link down (wl0.2) This part at least is interesting and I would like to know how brcmfmac deals with this order of events. Regards, Arend -- 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
