mac80211: reply to directed probes in IBSS
Johannes Berg
maintainerRFC 1/1 mac80211: reply to directed probes in IBSS
From: Johannes Berg <[email protected]>
At least the WMM spec says we should reply to
unicast probe request frames that go to us.
--- net/mac80211/ibss.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
net/mac80211/ibss.c +1 -1
@@ -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 &&
Quoted 20 lines · Johannes Berg
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(-)net/mac80211/ibss.c 2011-02-01 13:47:44.000000000 +0100 renamed from net/mac80211/ibss.c 2011-02-01 12:58:16.000000000 +0100 +1
-1@@ -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;
Quoted 1 line
if (
memcmp(mgmt->bssid, ifibss->bssid, ETH_ALEN)!= 0 &&
Hi Johannes,
tested with the same thing (in addition of passing therx_status structure) and it is working fine.
net/mac80211/ibss.c +0 -0
@@ -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
Quoted 7 lines
--
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
Johannes Berg
maintainerQuoted 21 lines · Mohammed Shafi
Quoted 20 lines · Johannes Berg
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(-)net/mac80211/ibss.c 2011-02-01 13:47:44.000000000 +0100 renamed from net/mac80211/ibss.c 2011-02-01 12:58:16.000000000 +0100 +1
-1@@ -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;
Quoted 5 lines
net/mac80211/ibss.c 2011-02-01 13:47:44.000000000 +0100 static void ieee80211_rx_mgmt_probe_req( · line 695
Quoted 1 line
net/mac80211/ibss.c 2011-02-01 13:47:44.000000000 +0100 renamed from net/mac80211/ibss.c 2011-02-01 12:58:16.000000000 +0100 +0
-0if (memcmp(mgmt->bssid, ifibss->bssid, ETH_ALEN) != 0 &&Hi Johannes,
tested with the same thing (in addition of passing therx_statusstructure) 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
Quoted 28 lines · Johannes Berg
Quoted 21 lines · Mohammed Shafi
Quoted 20 lines · Johannes Berg
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(-)net/mac80211/ibss.c 2011-02-01 13:47:44.000000000 +0100 renamed from net/mac80211/ibss.c 2011-02-01 12:58:16.000000000 +0100 +1
-1@@ -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;Quoted 5 lines
Quoted 1 line
if (
memcmp(mgmt->bssid, ifibss->bssid, ETH_ALEN)!= 0 &&Hi Johannes,
tested with the same thing (in addition of passing therx_statusstructure) and it is working fine.
Quoted 4 lines
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
Quoted 4 lines
johannes
Quoted 30 lines · Mohammed Shafi
Quoted 28 lines · Johannes Berg
Quoted 26 lines · Mohammed Shafi
Quoted 20 lines · Johannes Berg
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(-)net/mac80211/ibss.c 2011-02-01 13:47:44.000000000 +0100 renamed from net/mac80211/ibss.c 2011-02-01 12:58:16.000000000 +0100 +1
-1@@ -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;Quoted 1 line
if (
memcmp(mgmt->bssid, ifibss->bssid, ETH_ALEN)!= 0 &&Hi Johannes,
tested with the same thing (in addition of passing therx_statusstructure) and it is working fine.
Quoted 6 lines
Quoted 4 lines
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
Quoted 8 lines
thanks,
shafiQuoted 4 lines
johannes
Quoted 2 lines · Johannes Berg
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.
Signature · 1 line
Jouni Malinen PGP id EFC895FA
Johannes Berg
maintainerQuoted 11 lines · Jouni Malinen
Quoted 2 lines · Johannes Berg
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
Quoted 2 lines · Johannes Berg
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.
Signature · 1 line
Jouni Malinen PGP id EFC895FA