[RFC] nl80211: set NLMODE correctly for AP interface
Tue May 13 07:06:59 PDT 2014
On Tue, May 13, 2014 at 03:46:05PM +0530, Avinash Patil wrote:
> We add interface manually by "iw dev interface wlan0 add uap0 type
> __ap" and then we start AP operations using supplicant.
> Typical configuration file would be like this:
> #wpa_supplicant -Dnl80211 -i uap0 -c ap.conf
Does this fail for you without the change? If so, could you please share
a wpa_supplicant debug log showing the failure?
> >> diff --git a/src/drivers/driver_nl80211.c b/src/drivers/driver_nl80211.c
> >> @@ -4698,7 +4698,7 @@ wpa_driver_nl80211_finish_drv_init(struct
> >> - if (drv->hostapd)
> >> + if (drv->hostapd || nl80211_get_ifmode(bss) == NL80211_IFTYPE_AP)
> >> nlmode = NL80211_IFTYPE_AP;
> > This breaks the case of something first setting wlan0 to non-station
> > mode (e.g., "iw wlan0 set type __ap") followed by wpa_supplicant started
> > on wlan0. The expectation there is that wpa_supplicant runs operations
> > in station mode until requested to something else (e.g., start AP mode).
> I did not fully understand this scenario but I think you are referring
> to similar situation as I described earlier except while I am adding
> interface, in this case interface type is changed.
I'm talking about the exact same way of adding the vif, but different
wpa_supplicant configuration, i.e., a configuration that does not enable
AP mode operations.
> > Why would this change be needed in the first place? Doesn't
> > wpa_supplicant set the interface to AP mode when the AP mode network is
> > being configured?
> This handles a case where AP<=>STA change_virtual_interface is not
> supported but we know that interface on which supplicant is started is
> AP interface.
> To ensure that this check applies only to statically created
> interface, we can add one more check:
> if (drv->hostapd || (nl80211_get_ifmode(bss) ==
> NL80211_IFTYPE_AP && !bss->if_dynamic))
> nlmode = NL80211_IFTYPE_AP;
The problem here is that this function does not know what wpa_supplicant
will do next. In the example I described, the new operation would not be
AP mode and as such, changing to AP mode here would not be correct. In
the example you are describing, the next operation is AP mode, but the
code here has no way of knowing that and as such, I don't think it
should use the current iftype of the interface to try to guess what
might be happening next.
Jouni Malinen PGP id EFC895FA
More information about the Hostap