Re: [PATCH] mac80211: Allow probe response frame rx to user space in AP mode

2016-03-09 Thread Thiagarajan, Vasanthakumar
On Wednesday 09 March 2016 02:59 PM, Johannes Berg wrote:
> On Wed, 2016-03-09 at 05:10 +, Thiagarajan, Vasanthakumar wrote:
>
>> When an user space wants to have control over the duration of off-
>> channel (single channel) scan it could use remain-on-channel
>> interface instead of trigger_scan to perform off-channel scan. I dont
>> think BSS cache will be updated with the BSS information received
>> during remain-on-channel. In this case, user space could use probe
>> response frames to build BSS list.
>>
> That's not a use case, that's an implementation?

User space wants to build up a list of preferred BSS and channel from 
off-channel
scan and these information can be shared with other stations around to better
use the spectrum. When the bss list is not available during remain-on channel,
probe response will be used to prepare the list.

>
> FWIW, we have patches pending to add some dwell time control for
> scanning since it's required for some radio resource measurement
> things. It seems like that would address your use case.

Sure, this will work for me. Thanks

VasanthN�r��yb�X��ǧv�^�)޺{.n�+{��*ޕ�,�{ay�ʇڙ�,j��f���h���z��w���
���j:+v���w�j�mzZ+�ݢj"��!�i

Re: [PATCH] mac80211: Allow probe response frame rx to user space in AP mode

2016-03-09 Thread Johannes Berg
On Wed, 2016-03-09 at 05:10 +, Thiagarajan, Vasanthakumar wrote:

> When an user space wants to have control over the duration of off-
> channel (single channel) scan it could use remain-on-channel
> interface instead of trigger_scan to perform off-channel scan. I dont
> think BSS cache will be updated with the BSS information received
> during remain-on-channel. In this case, user space could use probe
> response frames to build BSS list.
> 
That's not a use case, that's an implementation?

FWIW, we have patches pending to add some dwell time control for
scanning since it's required for some radio resource measurement
things. It seems like that would address your use case.

johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] mac80211: Allow probe response frame rx to user space in AP mode

2016-03-08 Thread Thiagarajan, Vasanthakumar
On Tuesday 08 March 2016 10:25 PM, Johannes Berg wrote:
> On Mon, 2016-03-07 at 12:42 +0530, Vasanthakumar Thiagarajan wrote:
>> Especially during off-channel scan user space might be interested
>> in probe reponse frames along with beacon to build a list
>> of preferred channel and bssid which could be sent to the stations
>> around for better spectrum management. Do not drop probe response
>> frame in AP mode and advertise driver's capability to receive probe
>> response frame in AP mode to user space.
>
> I'm not convinced that this is a good idea - these frames will still
> populate the BSS cache, and it's not really quite well-specified what
> happens when you have both [1]
>
> I also don't understand the use case; "might be interested" is ... very
> vague.

When an user space wants to have control over the duration of off-channel 
(single channel)
scan it could use remain-on-channel interface instead of trigger_scan to 
perform off-channel
scan. I dont think BSS cache will be updated with the BSS information received 
during
remain-on-channel. In this case, user space could use probe response frames to 
build
BSS list.

Vasanth


Re: [PATCH] mac80211: Allow probe response frame rx to user space in AP mode

2016-03-08 Thread Johannes Berg
On Mon, 2016-03-07 at 12:42 +0530, Vasanthakumar Thiagarajan wrote:
> Especially during off-channel scan user space might be interested
> in probe reponse frames along with beacon to build a list
> of preferred channel and bssid which could be sent to the stations
> around for better spectrum management. Do not drop probe response
> frame in AP mode and advertise driver's capability to receive probe
> response frame in AP mode to user space.

I'm not convinced that this is a good idea - these frames will still
populate the BSS cache, and it's not really quite well-specified what
happens when you have both [1]

I also don't understand the use case; "might be interested" is ... very
vague.

johannes

[1] obviously, today you get both, but an argument could be made for
userspace RX meaning the frame has no action taken in the kernel, like
with action frames.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH] mac80211: Allow probe response frame rx to user space in AP mode

2016-03-06 Thread Vasanthakumar Thiagarajan
Especially during off-channel scan user space might be interested
in probe reponse frames along with beacon to build a list
of preferred channel and bssid which could be sent to the stations
around for better spectrum management. Do not drop probe response
frame in AP mode and advertise driver's capability to receive probe
response frame in AP mode to user space.

Signed-off-by: Vasanthakumar Thiagarajan 
---
 net/mac80211/main.c | 2 ++
 net/mac80211/rx.c   | 2 ++
 2 files changed, 4 insertions(+)

diff --git a/net/mac80211/main.c b/net/mac80211/main.c
index 8190bf2..c8a97da 100644
--- a/net/mac80211/main.c
+++ b/net/mac80211/main.c
@@ -401,6 +401,7 @@ ieee80211_default_mgmt_stypes[NUM_NL80211_IFTYPES] = {
.rx = BIT(IEEE80211_STYPE_ASSOC_REQ >> 4) |
BIT(IEEE80211_STYPE_REASSOC_REQ >> 4) |
BIT(IEEE80211_STYPE_PROBE_REQ >> 4) |
+   BIT(IEEE80211_STYPE_PROBE_RESP >> 4) |
BIT(IEEE80211_STYPE_DISASSOC >> 4) |
BIT(IEEE80211_STYPE_AUTH >> 4) |
BIT(IEEE80211_STYPE_DEAUTH >> 4) |
@@ -412,6 +413,7 @@ ieee80211_default_mgmt_stypes[NUM_NL80211_IFTYPES] = {
.rx = BIT(IEEE80211_STYPE_ASSOC_REQ >> 4) |
BIT(IEEE80211_STYPE_REASSOC_REQ >> 4) |
BIT(IEEE80211_STYPE_PROBE_REQ >> 4) |
+   BIT(IEEE80211_STYPE_PROBE_RESP >> 4) |
BIT(IEEE80211_STYPE_DISASSOC >> 4) |
BIT(IEEE80211_STYPE_AUTH >> 4) |
BIT(IEEE80211_STYPE_DEAUTH >> 4) |
diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index 9127957..9d8f8ea 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -3464,6 +3464,8 @@ static bool ieee80211_accept_frame(struct 
ieee80211_rx_data *rx)
return false;
if (ieee80211_is_public_action(hdr, skb->len))
return true;
+   if (ieee80211_is_probe_resp(hdr->frame_control))
+   return true;
return ieee80211_is_beacon(hdr->frame_control);
}
 
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html