RE: [PATCH 24/25] MBO: Always accept BTM request with disassociation imminent bit set

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> -----Original Message-----
> From: Jouni Malinen [mailto:j@xxxxx]
> Sent: Sunday, February 21, 2016 10:30
> To: Peer, Ilan
> Cc: hostap@xxxxxxxxxxxxxxxxxxx; 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.




_______________________________________________
Hostap mailing list
Hostap@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/hostap




[Index of Archives]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]

  Powered by Linux