From: Johannes Berg <[email protected]>
At least the WMM spec says we should reply to
unicast probe request frames that go to us.
Signed-off-by: Johannes Berg <[email protected]>
---
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 &&
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
On Mon, Feb 14, 2011 at 3:58 PM, Mohammed Shafi
<[email protected]> wrote:
> On Mon, Feb 14, 2011 at 3:42 PM, Johannes Berg
> <[email protected]> wrote:
>> On Tue, 2011-02-08 at 16:41 +0530, Mohammed Shafi wrote:
>>> On Tue, Feb 1, 2011 at 6:19 PM, Johannes Berg <[email protected]> wrote:
>>> > From: Johannes Berg <[email protected]>
>>> >
>>> > At least the WMM spec says we should reply to
>>> > unicast probe request frames that go to us.
>>> >
>>> > Signed-off-by: Johannes Berg <[email protected]>
>>> > ---
>>> > ?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
>>
>>
>
On Tue, 2011-02-08 at 16:41 +0530, Mohammed Shafi wrote:
> On Tue, Feb 1, 2011 at 6:19 PM, Johannes Berg <[email protected]> wrote:
> > From: Johannes Berg <[email protected]>
> >
> > At least the WMM spec says we should reply to
> > unicast probe request frames that go to us.
> >
> > Signed-off-by: Johannes Berg <[email protected]>
> > ---
> > 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
On Tue, Feb 1, 2011 at 6:19 PM, Johannes Berg <[email protected]> wrote:
> From: Johannes Berg <[email protected]>
>
> At least the WMM spec says we should reply to
> unicast probe request frames that go to us.
>
> Signed-off-by: Johannes Berg <[email protected]>
> ---
> ?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 [email protected]
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
>
On Mon, Feb 14, 2011 at 3:42 PM, Johannes Berg
<[email protected]> wrote:
> On Tue, 2011-02-08 at 16:41 +0530, Mohammed Shafi wrote:
>> On Tue, Feb 1, 2011 at 6:19 PM, Johannes Berg <[email protected]> wrote:
>> > From: Johannes Berg <[email protected]>
>> >
>> > At least the WMM spec says we should reply to
>> > unicast probe request frames that go to us.
>> >
>> > Signed-off-by: Johannes Berg <[email protected]>
>> > ---
>> > ?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
>
>
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
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