Hi Jouni,
For the brcmfmac we started working on Multiple-BSSID support and came
across some issues with hostapd that are listed listed below.
BSS1 setup on netdev wlan0
BSS2 setup on netdev wlan0_0
* get_station() done on wrong netdev
observed:
Upon association of STA1 with BSS2 (wlan0_0) a get_station() is done for
STA1 with wlan0 as netdev.
expected:
get_station() for STA1 with wlan0_0 as netdev. We verified that wlan0_0
ifindex was used in NL80211_CMD_NEW_STATION event.
* cleanup of wlan0_0 not done upon terminating hostapd
observed:
Upon terminating hostapd, only change interface from AP->STA is received
for wlan0_0 and wlan0. The stop_ap is only done for BSS1. So ending up
with additional netdev, ie. wlan0_0.
expected:
following sequence seems more appropriate:
stop_ap() for BSS2
if_remove() for BSS2
stop_ap() for BSS1
if_change() AP->STA for BSS1
Do you think it makes sense to correct these scenarios according the
described expected behaviour? Maybe the behaviour is only expected by me
and there is a good reason for the current behaviour.
Regards,
Arend
On 28 November 2014 at 10:27, Arend van Spriel <[email protected]> wrote:
> For the brcmfmac we started working on Multiple-BSSID support and came
> across some issues with hostapd that are listed listed below.
>
> BSS1 setup on netdev wlan0
> BSS2 setup on netdev wlan0_0
>
> * get_station() done on wrong netdev
>
> observed:
> Upon association of STA1 with BSS2 (wlan0_0) a get_station() is done for
> STA1 with wlan0 as netdev.
> expected:
> get_station() for STA1 with wlan0_0 as netdev. We verified that wlan0_0
> ifindex was used in NL80211_CMD_NEW_STATION event.
Did you do any progress on this?
According to the nl80211.h you are correct of course, every
NL80211_CMD_foo_STATION command should include NL80211_ATTR_IFINDEX.
There are two functions in driver_nl80211.c where
NL80211_CMD_GET_STATION is used.
1) nl80211_get_link_signal
It fills NL80211_ATTR_IFINDEX in the following way:
NLA_PUT_U32(msg, NL80211_ATTR_IFINDEX, drv->ifindex);
2) i802_read_sta_data
It fills NL80211_ATTR_IFINDEX in the following way:
NLA_PUT_U32(msg, NL80211_ATTR_IFINDEX, if_nametoindex(bss->ifname));
Did you track down which of the above functions in the one sending
wrong NL80211_ATTR_IFINDEX?
On 12/04/14 13:03, Rafał Miłecki wrote:
> On 28 November 2014 at 10:27, Arend van Spriel<[email protected]> wrote:
>> For the brcmfmac we started working on Multiple-BSSID support and came
>> across some issues with hostapd that are listed listed below.
>>
>> BSS1 setup on netdev wlan0
>> BSS2 setup on netdev wlan0_0
>>
>> * get_station() done on wrong netdev
>>
>> observed:
>> Upon association of STA1 with BSS2 (wlan0_0) a get_station() is done for
>> STA1 with wlan0 as netdev.
>> expected:
>> get_station() for STA1 with wlan0_0 as netdev. We verified that wlan0_0
>> ifindex was used in NL80211_CMD_NEW_STATION event.
>
> Did you do any progress on this?
Nope.
> According to the nl80211.h you are correct of course, every
> NL80211_CMD_foo_STATION command should include NL80211_ATTR_IFINDEX.
>
> There are two functions in driver_nl80211.c where
> NL80211_CMD_GET_STATION is used.
>
> 1) nl80211_get_link_signal
> It fills NL80211_ATTR_IFINDEX in the following way:
> NLA_PUT_U32(msg, NL80211_ATTR_IFINDEX, drv->ifindex);
>
> 2) i802_read_sta_data
> It fills NL80211_ATTR_IFINDEX in the following way:
> NLA_PUT_U32(msg, NL80211_ATTR_IFINDEX, if_nametoindex(bss->ifname));
>
> Did you track down which of the above functions in the one sending
> wrong NL80211_ATTR_IFINDEX?
Nope. We simply return empty sta_info. We used the hostapd that comes
with Ubuntu 12.04 (i think) to assure it is usable. I suppose the code
you mention here is driver_nl80211.c from the git repo. I intended to
retry the scenario with hostapd build from git.
Regards,
Arend
On 1 March 2015 at 18:12, Jouni Malinen <[email protected]> wrote:
> On Fri, Nov 28, 2014 at 10:27:29AM +0100, Arend van Spriel wrote:
>> For the brcmfmac we started working on Multiple-BSSID support and came
>> across some issues with hostapd that are listed listed below.
>
> Did you get test these with a more recent hostapd version (ideally,
> hostap.git master branch snapshot)? I was unable to reproduce either
> issue..
Could this be something similar to the problem handled in:
nl80211: report new station / assoc event for the correct BSS
http://patchwork.ozlabs.org/patch/418401/
http://w1.fi/cgit/hostap/commit/?id=7c4027f60411aca6e90a0074499c5427c8268baa
NL80211_CMD_GET_STATION is not handled in driver_nl80211_event.c, but
maybe there is similar place somewhere else?
On Fri, Nov 28, 2014 at 10:27:29AM +0100, Arend van Spriel wrote:
> For the brcmfmac we started working on Multiple-BSSID support and came
> across some issues with hostapd that are listed listed below.
Did you get test these with a more recent hostapd version (ideally,
hostap.git master branch snapshot)? I was unable to reproduce either
issue..
> BSS1 setup on netdev wlan0
> BSS2 setup on netdev wlan0_0
>
> * get_station() done on wrong netdev
>
> observed:
> Upon association of STA1 with BSS2 (wlan0_0) a get_station() is done for
> STA1 with wlan0 as netdev.
> expected:
> get_station() for STA1 with wlan0_0 as netdev. We verified that wlan0_0
> ifindex was used in NL80211_CMD_NEW_STATION event.
I'm not sure which get_station operation would happen upon association..
Anyway, hostapd uses get_station() to fetch STA statistics for
accounting and inactivity checking. The former can be triggered through
control interface, so I used that to test this. In multi-BSS
configuration, NL80211_CMD_GET_STATION was issued to the correct ifindex
depending on which BSS the STA was associated with.
> * cleanup of wlan0_0 not done upon terminating hostapd
>
> observed:
> Upon terminating hostapd, only change interface from AP->STA is received
> for wlan0_0 and wlan0. The stop_ap is only done for BSS1. So ending up
> with additional netdev, ie. wlan0_0.
> expected:
> following sequence seems more appropriate:
> stop_ap() for BSS2
> if_remove() for BSS2
> stop_ap() for BSS1
> if_change() AP->STA for BSS1
All dynamically added interfaces get removed in my tests.
> Do you think it makes sense to correct these scenarios according the
> described expected behaviour? Maybe the behaviour is only expected by me
> and there is a good reason for the current behaviour.
Your expectation sounds correct and that matches what I see hostapd
doing currently..
--
Jouni Malinen PGP id EFC895FA