brcmfmac: Getting IEs from CMD_ROAM

brcmfmac: Getting IEs from CMD_ROAM

[James Prestwood]

Hi,

Adding FW roaming support to IWD has led me down this rabbit hole with
CMD_ROAM, and I am attempting to understand how wpa_supplicant handles
this. The brcmfmac card I am using sends a CMD_ROAM event which
contains some response IEs but no RSN element (nor any scan information
like frequency, rssi, etc, thats another topic). This prevents the
supplicant from being able to complete the 4-way handshake.

Now, I have a dirty hack to re-use the previous BSS's RSN element which
*works* but this will break e.g. roaming between WPA1 <-> WPA2, plus
802.11 requires that the authenticator IE is verified during the 4-way, 
which cant reliably happen if we just use an arbitrary RSN element from
another BSS.

Is this a known issue? I'm trying to read the code in wpa_supplicant
and its making my head spin. It does attempt to parse the RSN element
from CMD_ROAM, but I expect that fails since its not included. If it
doesn't get it from CMD_ROAM where does it get it from? Or does it
spoof it like I am?

Thanks,
James

Re: brcmfmac: Getting IEs from CMD_ROAM

[James Prestwood]

Sorry for the noise, apparently you do a GET_SCAN after CMD_ROAM to
obtain this info. I'll be writing a docs change soon to describe this.

On Thu, 2021-03-11 at 14:00 -0800, James Prestwood wrote:
> Hi,
> 
> Adding FW roaming support to IWD has led me down this rabbit hole
> with
> CMD_ROAM, and I am attempting to understand how wpa_supplicant
> handles
> this. The brcmfmac card I am using sends a CMD_ROAM event which
> contains some response IEs but no RSN element (nor any scan
> information
> like frequency, rssi, etc, thats another topic). This prevents the
> supplicant from being able to complete the 4-way handshake.
> 
> Now, I have a dirty hack to re-use the previous BSS's RSN element
> which
> *works* but this will break e.g. roaming between WPA1 <-> WPA2, plus
> 802.11 requires that the authenticator IE is verified during the 4-
> way, 
> which cant reliably happen if we just use an arbitrary RSN element
> from
> another BSS.
> 
> Is this a known issue? I'm trying to read the code in wpa_supplicant
> and its making my head spin. It does attempt to parse the RSN element
> from CMD_ROAM, but I expect that fails since its not included. If it
> doesn't get it from CMD_ROAM where does it get it from? Or does it
> spoof it like I am?
> 
> Thanks,
> James
>