| Message ID | 1455548043-22427-48-git-send-email-ilan.peer@intel.com |
|---|---|
| State | Rejected |
| Headers | show |
On Mon, Feb 15, 2016 at 04:53:59PM +0200, Ilan Peer wrote: > According to Multiband Operation specification (r17, section 3.5.2), > a BSS Transition Management Request with the disassociation imminent > bit set should always be accepted. The spec includes an exception for this: "another AP, if one [is] available". > This is enforced in case the request did not include a candidate list. > However, in case a candidate list was included but none of the APs in > the candidate list was found in the scan results, the request is > rejected. > > Fix that by always accepting a request with the disassociation imminent > bit set even if no roaming candidate was found. This does not sound fixing to me.. Surely the request need to be rejected if the requested action cannot be performed.
> -----Original Message----- > From: Jouni Malinen [mailto:j@w1.fi] > Sent: Sunday, February 21, 2016 10:30 > To: Peer, Ilan > Cc: hostap@lists.infradead.org; Stern, Avraham > Subject: Re: [PATCH 24/25] MBO: Always accept BTM request with > disassociation imminent bit set > > On Mon, Feb 15, 2016 at 04:53:59PM +0200, Ilan Peer wrote: > > According to Multiband Operation specification (r17, section 3.5.2), a > > BSS Transition Management Request with the disassociation imminent bit > > set should always be accepted. > > The spec includes an exception for this: "another AP, if one [is] available". > Could not find this in the version that I have (v17). What I have states that: "On receipt of an unsolicited BTM Request frame with a Disassociation Imminent bit set to one, the MBO STA shall be capable of responding with a BTM Response frame that shall contain the Status Code field (§ 8.6.14.10 in [3]) indicating accept. The MBO STA may also include the Target BSSID field (§ 8.6.14.10 in [3]). When the Disassociation Imminent bit is set to one, the STA shall not reject the Transition Management Request" > > This is enforced in case the request did not include a candidate list. > > However, in case a candidate list was included but none of the APs in > > the candidate list was found in the scan results, the request is > > rejected. > > > > Fix that by always accepting a request with the disassociation > > imminent bit set even if no roaming candidate was found. > > This does not sound fixing to me.. Surely the request need to be rejected if > the requested action cannot be performed. > We were also confused about this :) Maybe the reason for this is that as Disassociation Imminent is set the station does not have much choice and eventually would be disassociated so whether it initiated a transition to one of the candidates or not does not really matter. Anyway, we could clarify this with the relevant people this week. Regards, Ilan.
On Sun, Feb 21, 2016 at 09:19:01AM +0000, Peer, Ilan wrote: > > From: Jouni Malinen [mailto:j@w1.fi] > > On Mon, Feb 15, 2016 at 04:53:59PM +0200, Ilan Peer wrote: > > > According to Multiband Operation specification (r17, section 3.5.2), a > > > BSS Transition Management Request with the disassociation imminent bit > > > set should always be accepted. > > > > The spec includes an exception for this: "another AP, if one [is] available". > Could not find this in the version that I have (v17). What I have states that: > > "On receipt of an unsolicited BTM Request frame with a Disassociation Imminent bit set to one, the MBO STA shall be capable of responding with a BTM Response frame that shall contain the Status Code field (§ 8.6.14.10 in [3]) indicating accept. The MBO STA may also include the Target BSSID field (§ 8.6.14.10 in [3]). When the Disassociation Imminent bit is set to one, the STA shall not reject the Transition Management Request" I'm reviewing this based on the latest draft (r19). Anyway, that "shall not reject" is there.. Interesting. IMHO, this looks pretty bad requirement and as such, if it is needed, it will need to be made conditional on CONFIG_MBO (if not even something stronger; I'm willing to ignore pointless requirements in the spec in the default behavior). I'd say the spec should really be modified to not say that, though, since there is no such requirement in the IEEE 802.11 standard and it does not make any sense to be forced to accept something that cannot be done. > We were also confused about this :) Maybe the reason for this is that as Disassociation Imminent is set the station does not have much choice and eventually > would be disassociated so whether it initiated a transition to one of the candidates or not does not really matter. Sure, but it should be valid behavior for a non-AP STA to wait for the AP to disconnect it if there are no other options for the non-AP STA to find alternative connection. Misusing BSS Transition Management frames to cause disconnection is not really the best approach for something like this since the AP can already use the standard Deauthentication frame as notification.
> -----Original Message----- > From: Jouni Malinen [mailto:j@w1.fi] > Sent: Sunday, February 21, 2016 12:37 > To: Peer, Ilan > Cc: hostap@lists.infradead.org; Stern, Avraham > Subject: Re: [PATCH 24/25] MBO: Always accept BTM request with > disassociation imminent bit set > > On Sun, Feb 21, 2016 at 09:19:01AM +0000, Peer, Ilan wrote: > > > From: Jouni Malinen [mailto:j@w1.fi] On Mon, Feb 15, 2016 at > > > 04:53:59PM +0200, Ilan Peer wrote: > > > > According to Multiband Operation specification (r17, section > > > > 3.5.2), a BSS Transition Management Request with the > > > > disassociation imminent bit set should always be accepted. > > > > > > The spec includes an exception for this: "another AP, if one [is] available". > > > Could not find this in the version that I have (v17). What I have states that: > > > > "On receipt of an unsolicited BTM Request frame with a Disassociation > Imminent bit set to one, the MBO STA shall be capable of responding with a > BTM Response frame that shall contain the Status Code field (§ 8.6.14.10 in > [3]) indicating accept. The MBO STA may also include the Target BSSID field (§ > 8.6.14.10 in [3]). When the Disassociation Imminent bit is set to one, the STA > shall not reject the Transition Management Request" > > I'm reviewing this based on the latest draft (r19). Anyway, that "shall not > reject" is there.. Interesting. IMHO, this looks pretty bad requirement and as > such, if it is needed, it will need to be made conditional on CONFIG_MBO (if > not even something stronger; I'm willing to ignore pointless requirements in > the spec in the default behavior). > I'd say the spec should really be modified to not say that, though, since there > is no such requirement in the IEEE 802.11 standard and it does not make any > sense to be forced to accept something that cannot be done. > I've asked our representatives to handle this the WFA, so we can wait for their clarifications/changes on this. > > We were also confused about this :) Maybe the reason for this is that > > as Disassociation Imminent is set the station does not have much choice and > eventually would be disassociated so whether it initiated a transition to one of > the candidates or not does not really matter. > > Sure, but it should be valid behavior for a non-AP STA to wait for the AP to > disconnect it if there are no other options for the non-AP STA to find > alternative connection. Misusing BSS Transition Management frames to cause > disconnection is not really the best approach for something like this since the > AP can already use the standard Deauthentication frame as notification. > Indeed. Looking at this again, this is also actually not compatible with the spec that requires the station to disconnect after accepting the BTM. Thanks, Ilan.
diff --git a/wpa_supplicant/wnm_sta.c b/wpa_supplicant/wnm_sta.c index ff1dd66..eda996d 100644 --- a/wpa_supplicant/wnm_sta.c +++ b/wpa_supplicant/wnm_sta.c @@ -877,10 +877,18 @@ send_bss_resp_fail: if (!reply_on_fail) return 0; - /* Send reject response for all the failures */ + /* Send a response for all the failures */ if (wpa_s->wnm_reply) { wpa_s->wnm_reply = 0; + /* If disassoc imminent is set, we must not reject */ + if (wpa_s->wnm_mode & WNM_BSS_TM_REQ_DISASSOC_IMMINENT || + wpa_s->wnm_mode & WNM_BSS_TM_REQ_ESS_DISASSOC_IMMINENT) { + wpa_printf(MSG_DEBUG, + "WNM: Accept BTM request because disassociation imminent bit is set"); + status = WNM_BSS_TM_ACCEPT; + } + wnm_send_bss_transition_mgmt_resp(wpa_s, wpa_s->wnm_dialog_token, status, 0, NULL);