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: <f38178e49d50486bbf29e46b1514b92ff8681814.camel@gmail.com>
Subject: Re: 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:54:32 -0800
In-Reply-To: <76d03f421dd7db33755675e424541a64aac95310.camel@gmail.com>
References: <76d03f421dd7db33755675e424541a64aac95310.camel@gmail.com>
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

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
>