* Re: [PATCH] nl80211: report new station / assoc event for the correct BSS
2014-12-14 9:25 ` [PATCH] nl80211: report new station / assoc event for the correct BSS Arend van Spriel
@ 2014-12-14 15:46 ` Jouni Malinen
2014-12-14 20:11 ` Rafał Miłecki
1 sibling, 0 replies; 3+ messages in thread
From: Jouni Malinen @ 2014-12-14 15:46 UTC (permalink / raw)
To: Arend van Spriel
Cc: Rafał Miłecki, Hante Meuleman, hostap@lists.shmoo.com,
linux-wireless@vger.kernel.org
On Sun, Dec 14, 2014 at 10:25:45AM +0100, Arend van Spriel wrote:
> On 12/13/14 23:31, Rafał Miłecki wrote:
> >On 6 December 2014 at 16:06, Rafał Miłecki<zajec5@gmail.com> wrote:
> >>drv->ctx always points to the first BSS and we should report event using
> >>BSS related to the interface we got NL80211_CMD_NEW_STATION from.
> >>This fixes STA association for drivers using NL80211_CMD_NEW_STATION and
> >>multiple virtual interfaces.
> >>As you can see in the log called "Before", hostapd was getting event from
> >>wlan0-1 but then association was happening on the wlan0. This was breaking AP
> >>mode on virtual interfaces (BSS other than the first one).
> >>If you review this patch and it appears to be OK, I guess we will need similar
> >>modification for other events.
> I would say you are right in your analysis. I have not tried this
> patch. I will ask Hante as he added Multiple-BSSID support. I assume
> this bug is not visible to any mac80211-based driver, right?
I think this is the first time I've heard of anyone using the multi-BSS
design where multiple BSSes are maintained within a single struct
hostapd_data instance with a driver that does not use hostapd as the AP
SME and MLME. As such, this is getting to areas that have never been
even assumed to work.. Not that I have anything against making this
work, but it should be understood that this was not part of the criteria
for the event message design and yes, this would indeed require fixing
number of other places as well.
In practice, all cases where the driver takes care of authentication and
association frame exchanges have used multi-BSS design in a way that
hostapd gets two "radios" configured (e.g., two configuration files on
the command line, each pointing to a separate virtual interface). I'd
assume that could be used with nl80211 as well, but it may be reasonable
to extend the internal BSS control case (bss=<ifname> in hostapd.conf)
to provide a more consistent alternative for all drivers using the
nl80211 interface.
--
Jouni Malinen PGP id EFC895FA
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH] nl80211: report new station / assoc event for the correct BSS
2014-12-14 9:25 ` [PATCH] nl80211: report new station / assoc event for the correct BSS Arend van Spriel
2014-12-14 15:46 ` Jouni Malinen
@ 2014-12-14 20:11 ` Rafał Miłecki
1 sibling, 0 replies; 3+ messages in thread
From: Rafał Miłecki @ 2014-12-14 20:11 UTC (permalink / raw)
To: Arend van Spriel
Cc: Jouni Malinen, hostap@lists.shmoo.com, Hante Meuleman,
linux-wireless@vger.kernel.org
On 14 December 2014 at 10:25, Arend van Spriel <arend@broadcom.com> wrote:
> On 12/13/14 23:31, Rafał Miłecki wrote:
>>
>> On 6 December 2014 at 16:06, Rafał Miłecki<zajec5@gmail.com> wrote:
>>>
>>> drv->ctx always points to the first BSS and we should report event using
>>> BSS related to the interface we got NL80211_CMD_NEW_STATION from.
>>> This fixes STA association for drivers using NL80211_CMD_NEW_STATION and
>>> multiple virtual interfaces.
>>>
>>> Before:
>>> nl80211: Drv Event 19 (NL80211_CMD_NEW_STATION) received for wlan0-1
>>> (ifindex:7)
>>> nl80211: New station 02:00:00:00:01:00
>>> wlan0: STA 02:00:00:00:01:00 IEEE 802.11: associated
>>>
>>> After:
>>> nl80211: Drv Event 19 (NL80211_CMD_NEW_STATION) received for wlan0-1
>>> (ifindex:7)
>>> nl80211: New station 02:00:00:00:01:00
>>> wlan0-1: STA 02:00:00:00:01:00 IEEE 802.11: associated
>>>
>>> Signed-off-by: Rafał Miłecki<zajec5@gmail.com>
>>> ---
>>> Hi guys :)
>>>
>>> I recently heard about possible problems with handling BSS-es from Arend
>>> and was
>>> working with nl80211 / hostapd anyway, so decided to take a look at this.
>>>
>>> I think I found some bug in handling events that can be exposed when
>>> using
>>> multiple virtual interfaces, hardware authentication and cfg80211_new_sta
>>> (which
>>> gets translated into NL80211_CMD_NEW_STATION).
>>>
>>> As you can see in the log called "Before", hostapd was getting event from
>>> wlan0-1 but then association was happening on the wlan0. This was
>>> breaking AP
>>> mode on virtual interfaces (BSS other than the first one).
>>>
>>> Please note, that this bug (I believe it's a bug) won't be exposed when
>>> running
>>> mac80211_hwsim. In such case authentication is handled in hostapd and
>>> assoc
>>> happens in handle_assoc_cb (not hostapd_notif_assoc) which handles BSS-es
>>> correctly.
>>>
>>> If you review this patch and it appears to be OK, I guess we will need
>>> similar
>>> modification for other events.
>>
>>
>> Any opinions on this?
>
>
> I would say you are right in your analysis. I have not tried this patch. I
> will ask Hante as he added Multiple-BSSID support. I assume this bug is not
> visible to any mac80211-based driver, right?
Yes. What I wrote about mac80211_hwsim applies to (almost?) all
mac80211 drivers (they usually don't handle authentication in
hardware).
--
Rafał
^ permalink raw reply [flat|nested] 3+ messages in thread