All of lore.kernel.org
 help / color / mirror / Atom feed
* [RFC] mac80211: reply to directed probes in IBSS
@ 2011-02-01 12:49 Johannes Berg
  2011-02-08 11:11 ` Mohammed Shafi
  0 siblings, 1 reply; 8+ messages in thread
From: Johannes Berg @ 2011-02-01 12:49 UTC (permalink / raw)
  To: linux-wireless

From: Johannes Berg <johannes.berg@intel.com>

At least the WMM spec says we should reply to
unicast probe request frames that go to us.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
 net/mac80211/ibss.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- wireless-testing.orig/net/mac80211/ibss.c	2011-02-01 12:58:16.000000000 +0100
+++ wireless-testing/net/mac80211/ibss.c	2011-02-01 13:47:44.000000000 +0100
@@ -689,7 +689,7 @@ static void ieee80211_rx_mgmt_probe_req(
 	       mgmt->bssid, tx_last_beacon);
 #endif /* CONFIG_MAC80211_IBSS_DEBUG */
 
-	if (!tx_last_beacon)
+	if (!tx_last_beacon && !(status->rx_flags & IEEE80211_RX_RA_MATCH))
 		return;
 
 	if (memcmp(mgmt->bssid, ifibss->bssid, ETH_ALEN) != 0 &&



^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [RFC] mac80211: reply to directed probes in IBSS
  2011-02-01 12:49 [RFC] mac80211: reply to directed probes in IBSS Johannes Berg
@ 2011-02-08 11:11 ` Mohammed Shafi
  2011-02-14 10:12   ` Johannes Berg
  0 siblings, 1 reply; 8+ messages in thread
From: Mohammed Shafi @ 2011-02-08 11:11 UTC (permalink / raw)
  To: Johannes Berg; +Cc: linux-wireless

On Tue, Feb 1, 2011 at 6:19 PM, Johannes Berg <johannes@sipsolutions.net> wrote:
> From: Johannes Berg <johannes.berg@intel.com>
>
> At least the WMM spec says we should reply to
> unicast probe request frames that go to us.
>
> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
> ---
>  net/mac80211/ibss.c |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> --- wireless-testing.orig/net/mac80211/ibss.c   2011-02-01 12:58:16.000000000 +0100
> +++ wireless-testing/net/mac80211/ibss.c        2011-02-01 13:47:44.000000000 +0100
> @@ -689,7 +689,7 @@ static void ieee80211_rx_mgmt_probe_req(
>               mgmt->bssid, tx_last_beacon);
>  #endif /* CONFIG_MAC80211_IBSS_DEBUG */
>
> -       if (!tx_last_beacon)
> +       if (!tx_last_beacon && !(status->rx_flags & IEEE80211_RX_RA_MATCH))
>                return;
>
>        if (memcmp(mgmt->bssid, ifibss->bssid, ETH_ALEN) != 0 &&

Hi Johannes,
             tested with the same thing (in addition of passing the
rx_status structure) and it is working fine.

diff --git a/net/mac80211/ibss.c b/net/mac80211/ibss.c
index 775fb63..d26bd22 100644
--- a/net/mac80211/ibss.c
+++ b/net/mac80211/ibss.c
@@ -665,7 +665,8 @@ static void ieee80211_sta_find_ibss(struct
ieee80211_sub_if_data *sdata)

 static void ieee80211_rx_mgmt_probe_req(struct ieee80211_sub_if_data *sdata,
                                        struct ieee80211_mgmt *mgmt,
-                                       size_t len)
+                                       size_t len,
+                                       struct ieee80211_rx_status *rx_status)
 {
        struct ieee80211_if_ibss *ifibss = &sdata->u.ibss;
        struct ieee80211_local *local = sdata->local;
@@ -689,7 +690,7 @@ static void ieee80211_rx_mgmt_probe_req(struct
ieee80211_sub_if_data *sdata,
               mgmt->bssid, tx_last_beacon);
 #endif /* CONFIG_MAC80211_IBSS_DEBUG */

-       if (!tx_last_beacon)
+       if (!tx_last_beacon && !(rx_status->rx_flags & IEEE80211_RX_RA_MATCH))
                return;

        if (memcmp(mgmt->bssid, ifibss->bssid, ETH_ALEN) != 0 &&
@@ -786,7 +787,8 @@ void ieee80211_ibss_rx_queued_mgmt(struct
ieee80211_sub_if_data *sdata,

        switch (fc & IEEE80211_FCTL_STYPE) {
        case IEEE80211_STYPE_PROBE_REQ:
-               ieee80211_rx_mgmt_probe_req(sdata, mgmt, skb->len);
+               ieee80211_rx_mgmt_probe_req(sdata, mgmt, skb->len,
+                                            rx_status);
                break;
        case IEEE80211_STYPE_PROBE_RESP:
                ieee80211_rx_mgmt_probe_resp(sdata, mgmt, skb->len,
~

thanks,
shafi

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

^ permalink raw reply related	[flat|nested] 8+ messages in thread

* Re: [RFC] mac80211: reply to directed probes in IBSS
  2011-02-08 11:11 ` Mohammed Shafi
@ 2011-02-14 10:12   ` Johannes Berg
  2011-02-14 10:28     ` Mohammed Shafi
  2011-02-14 12:28     ` Jouni Malinen
  0 siblings, 2 replies; 8+ messages in thread
From: Johannes Berg @ 2011-02-14 10:12 UTC (permalink / raw)
  To: Mohammed Shafi; +Cc: linux-wireless

On Tue, 2011-02-08 at 16:41 +0530, Mohammed Shafi wrote:
> On Tue, Feb 1, 2011 at 6:19 PM, Johannes Berg <johannes@sipsolutions.net> wrote:
> > From: Johannes Berg <johannes.berg@intel.com>
> >
> > At least the WMM spec says we should reply to
> > unicast probe request frames that go to us.
> >
> > Signed-off-by: Johannes Berg <johannes.berg@intel.com>
> > ---
> >  net/mac80211/ibss.c |    2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > --- wireless-testing.orig/net/mac80211/ibss.c   2011-02-01 12:58:16.000000000 +0100
> > +++ wireless-testing/net/mac80211/ibss.c        2011-02-01 13:47:44.000000000 +0100
> > @@ -689,7 +689,7 @@ static void ieee80211_rx_mgmt_probe_req(
> >               mgmt->bssid, tx_last_beacon);
> >  #endif /* CONFIG_MAC80211_IBSS_DEBUG */
> >
> > -       if (!tx_last_beacon)
> > +       if (!tx_last_beacon && !(status->rx_flags & IEEE80211_RX_RA_MATCH))
> >                return;
> >
> >        if (memcmp(mgmt->bssid, ifibss->bssid, ETH_ALEN) != 0 &&
> 
> Hi Johannes,
>              tested with the same thing (in addition of passing the
> rx_status structure) and it is working fine.

Yeah, I clearly missed that, guess I wasn't paying attention.

The real question though is -- do we want/need this? I can only find
reference to this behaviour in the WMM spec.

johannes


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [RFC] mac80211: reply to directed probes in IBSS
  2011-02-14 10:12   ` Johannes Berg
@ 2011-02-14 10:28     ` Mohammed Shafi
  2011-02-14 10:48       ` Mohammed Shafi
  2011-02-14 12:28     ` Jouni Malinen
  1 sibling, 1 reply; 8+ messages in thread
From: Mohammed Shafi @ 2011-02-14 10:28 UTC (permalink / raw)
  To: Johannes Berg; +Cc: linux-wireless

On Mon, Feb 14, 2011 at 3:42 PM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Tue, 2011-02-08 at 16:41 +0530, Mohammed Shafi wrote:
>> On Tue, Feb 1, 2011 at 6:19 PM, Johannes Berg <johannes@sipsolutions.net> wrote:
>> > From: Johannes Berg <johannes.berg@intel.com>
>> >
>> > At least the WMM spec says we should reply to
>> > unicast probe request frames that go to us.
>> >
>> > Signed-off-by: Johannes Berg <johannes.berg@intel.com>
>> > ---
>> >  net/mac80211/ibss.c |    2 +-
>> >  1 file changed, 1 insertion(+), 1 deletion(-)
>> >
>> > --- wireless-testing.orig/net/mac80211/ibss.c   2011-02-01 12:58:16.000000000 +0100
>> > +++ wireless-testing/net/mac80211/ibss.c        2011-02-01 13:47:44.000000000 +0100
>> > @@ -689,7 +689,7 @@ static void ieee80211_rx_mgmt_probe_req(
>> >               mgmt->bssid, tx_last_beacon);
>> >  #endif /* CONFIG_MAC80211_IBSS_DEBUG */
>> >
>> > -       if (!tx_last_beacon)
>> > +       if (!tx_last_beacon && !(status->rx_flags & IEEE80211_RX_RA_MATCH))
>> >                return;
>> >
>> >        if (memcmp(mgmt->bssid, ifibss->bssid, ETH_ALEN) != 0 &&
>>
>> Hi Johannes,
>>              tested with the same thing (in addition of passing the
>> rx_status structure) and it is working fine.
>
> Yeah, I clearly missed that, guess I wasn't paying attention.
>
> The real question though is -- do we want/need this? I can only find
> reference to this behaviour in the WMM spec.

Yes, Test Engineers say this is necessary for IBSS test case-5.3.1 to pass.
thanks,
shafi

>
> johannes
>
>

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [RFC] mac80211: reply to directed probes in IBSS
  2011-02-14 10:28     ` Mohammed Shafi
@ 2011-02-14 10:48       ` Mohammed Shafi
  0 siblings, 0 replies; 8+ messages in thread
From: Mohammed Shafi @ 2011-02-14 10:48 UTC (permalink / raw)
  To: Johannes Berg; +Cc: linux-wireless

On Mon, Feb 14, 2011 at 3:58 PM, Mohammed Shafi
<shafi.wireless@gmail.com> wrote:
> On Mon, Feb 14, 2011 at 3:42 PM, Johannes Berg
> <johannes@sipsolutions.net> wrote:
>> On Tue, 2011-02-08 at 16:41 +0530, Mohammed Shafi wrote:
>>> On Tue, Feb 1, 2011 at 6:19 PM, Johannes Berg <johannes@sipsolutions.net> wrote:
>>> > From: Johannes Berg <johannes.berg@intel.com>
>>> >
>>> > At least the WMM spec says we should reply to
>>> > unicast probe request frames that go to us.
>>> >
>>> > Signed-off-by: Johannes Berg <johannes.berg@intel.com>
>>> > ---
>>> >  net/mac80211/ibss.c |    2 +-
>>> >  1 file changed, 1 insertion(+), 1 deletion(-)
>>> >
>>> > --- wireless-testing.orig/net/mac80211/ibss.c   2011-02-01 12:58:16.000000000 +0100
>>> > +++ wireless-testing/net/mac80211/ibss.c        2011-02-01 13:47:44.000000000 +0100
>>> > @@ -689,7 +689,7 @@ static void ieee80211_rx_mgmt_probe_req(
>>> >               mgmt->bssid, tx_last_beacon);
>>> >  #endif /* CONFIG_MAC80211_IBSS_DEBUG */
>>> >
>>> > -       if (!tx_last_beacon)
>>> > +       if (!tx_last_beacon && !(status->rx_flags & IEEE80211_RX_RA_MATCH))
>>> >                return;
>>> >
>>> >        if (memcmp(mgmt->bssid, ifibss->bssid, ETH_ALEN) != 0 &&
>>>
>>> Hi Johannes,
>>>              tested with the same thing (in addition of passing the
>>> rx_status structure) and it is working fine.
>>
>> Yeah, I clearly missed that, guess I wasn't paying attention.
>>
>> The real question though is -- do we want/need this? I can only find
>> reference to this behaviour in the WMM spec.
>
> Yes, Test Engineers say this is necessary for IBSS test case-5.3.1 to pass.

Sorry for the incomplete information, few details of the test case is
5.3.1 IBSS Active Scanning Test
Purpose and Description
Active scan tests verify that the STAUT can create an IBSS, respond to
active scans, and pass data.

References
Test case 6.1 in “Wi-Fi 802.11 with WPA2, WPA, and WEP System
Interoperability Test Plan for IEEE
802.11a, b & g Devices”

For the Active Probe

STAUT responds with
Basic rate enumerated in beacon message is per default
channel is correct
record BSSID for
alter comparison to ensure
that it is a random value

> thanks,
> shafi
>
>>
>> johannes
>>
>>
>

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [RFC] mac80211: reply to directed probes in IBSS
  2011-02-14 10:12   ` Johannes Berg
  2011-02-14 10:28     ` Mohammed Shafi
@ 2011-02-14 12:28     ` Jouni Malinen
  2011-02-14 12:31       ` Johannes Berg
  1 sibling, 1 reply; 8+ messages in thread
From: Jouni Malinen @ 2011-02-14 12:28 UTC (permalink / raw)
  To: Johannes Berg; +Cc: Mohammed Shafi, linux-wireless

On Mon, Feb 14, 2011 at 11:12:37AM +0100, Johannes Berg wrote:
> The real question though is -- do we want/need this? I can only find
> reference to this behaviour in the WMM spec.

Yes, we do want and need it. Peer capability discovery in RSN IBSS
depends on this (or a potentially long wait on receiving Beacon frame
from the specific STA). IEEE 802.11REVmb clarifies the rules for IBSS in
10.4.4.3.2 which has the following statement on this: "A STA in an IBSS
shall respond to Probe Request frames sent to the individual address of
the STA." after the sentence that limits responding to just the STA
that transmitted the last Beacon frame.
 
-- 
Jouni Malinen                                            PGP id EFC895FA

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [RFC] mac80211: reply to directed probes in IBSS
  2011-02-14 12:28     ` Jouni Malinen
@ 2011-02-14 12:31       ` Johannes Berg
  2011-02-14 13:38         ` Jouni Malinen
  0 siblings, 1 reply; 8+ messages in thread
From: Johannes Berg @ 2011-02-14 12:31 UTC (permalink / raw)
  To: Jouni Malinen; +Cc: Mohammed Shafi, linux-wireless

On Mon, 2011-02-14 at 14:28 +0200, Jouni Malinen wrote:
> On Mon, Feb 14, 2011 at 11:12:37AM +0100, Johannes Berg wrote:
> > The real question though is -- do we want/need this? I can only find
> > reference to this behaviour in the WMM spec.
> 
> Yes, we do want and need it. Peer capability discovery in RSN IBSS
> depends on this (or a potentially long wait on receiving Beacon frame
> from the specific STA). IEEE 802.11REVmb clarifies the rules for IBSS in
> 10.4.4.3.2 which has the following statement on this: "A STA in an IBSS
> shall respond to Probe Request frames sent to the individual address of
> the STA." after the sentence that limits responding to just the STA
> that transmitted the last Beacon frame.

Ok, good. I submitted the patch, maybe I should resubmit with this
information, but I guess it doesn't matter much.

The next question ends up being under which circumstances we should
_send_ a unicast probe request. Currently, I don't think we ever do.

johannes


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [RFC] mac80211: reply to directed probes in IBSS
  2011-02-14 12:31       ` Johannes Berg
@ 2011-02-14 13:38         ` Jouni Malinen
  0 siblings, 0 replies; 8+ messages in thread
From: Jouni Malinen @ 2011-02-14 13:38 UTC (permalink / raw)
  To: Johannes Berg; +Cc: Mohammed Shafi, linux-wireless

On Mon, Feb 14, 2011 at 01:31:34PM +0100, Johannes Berg wrote:
> The next question ends up being under which circumstances we should
> _send_ a unicast probe request. Currently, I don't think we ever do.

For WMM, we could do that whenever we have frames to send to another STA
in the same IBSS and we have not yet received a Beacon frame from that
STA. Then again, I'm not sure whether we would ever send a frame in such
a state since that would need a STA entry (I hope). I haven't really
looked at the current implementation, but anyway, the key is to use
directed Probe Request in IBSS to make sure we have correct information
about a peer STA's capabilities.

For RSN IBSS, wpa_supplicant is currently pretty much hardcoded to use
RSN with CCMP and PSK. Eventually, it could be extended to probe the
peer before starting key negotiation to figure out which pairwise cipher
to use and to also validate AKM options before ending up in 4-way
handshake. I'm not sure whether this is really needed in practice, but
that option is certainly there in the standard.

-- 
Jouni Malinen                                            PGP id EFC895FA

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2011-02-14 13:39 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-02-01 12:49 [RFC] mac80211: reply to directed probes in IBSS Johannes Berg
2011-02-08 11:11 ` Mohammed Shafi
2011-02-14 10:12   ` Johannes Berg
2011-02-14 10:28     ` Mohammed Shafi
2011-02-14 10:48       ` Mohammed Shafi
2011-02-14 12:28     ` Jouni Malinen
2011-02-14 12:31       ` Johannes Berg
2011-02-14 13:38         ` Jouni Malinen

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.