Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Message-ID: <76d03f421dd7db33755675e424541a64aac95310.camel@gmail.com>
Subject: brcmfmac: Getting IEs from CMD_ROAM
From:   James Prestwood <prestwoj@gmail.com>
To:     "linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>
Date:   Thu, 11 Mar 2021 14:00:49 -0800
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.36.5 (3.36.5-1.fc32) 
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Precedence: bulk

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