Hi, I'll preface this with some background: Long ago support for multiple authenticated BSS's was removed due to its complexity. CMD_AUTHENTICATE now changes state/channel, and is not recoverable if authentication fails (i.e. disconnect). The spec actually allows/intends for multiple authentications to be supported and FT specifically can really benefit from this. As a workaround we started playing around with using CMD_FRAME/offchannel for authentication, bypassing the kernels state. This works, and we can authenticate, fail, try another BSS etc. all without the kernel knowing, then proceed to association. The small problem is dealing with OCV. Prior, we would call CMD_AUTHENTICATE (channel changes), then GET_INTERFACE in order to obtain the channel/operating class to build the OCI element. Now, since authentication is done offchannel we cannot use GET_INTERFACE. Deriving the OCI based on capabilities is certainly possible, after all this is what the kernel does, but rather than trying to mirror/maintain that code I thought it would be great if the kernel could append the OCI automatically to the association request. This would also save a round trip since GET_INTERFACE wouldn't be needed. Does this sound reasonable? Thanks, James