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 >
