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: <967e9193bc7d6573c4f0226e5801f2aeed92dc1c.camel@gmail.com>
Subject: Re: Auth/Assoc/Connect events coming before CMD_CONNECT response
 (hwsim)
From:   James Prestwood <prestwoj@gmail.com>
To:     Johannes Berg <johannes@sipsolutions.net>
Cc:     linux-wireless@vger.kernel.org
Date:   Wed, 27 May 2020 16:03:08 -0700
In-Reply-To: <68be99836859c4216a667e5784ed0e519cc1143c.camel@sipsolutions.net>
References: <CAPv5Ue7kNRRf9esOKkQ=Kkx8f0_vdkiPYg24pzVsv3Dg71Ow_Q@mail.gmail.com>
         <259da597c3902c79c9d5c6e171e109dcb68564eb.camel@sipsolutions.net>
         <CAPv5Ue4Cp=Eeo+xy1K0CRz-AC3p-tUnEuRjuL1dyt0yiKhpwpA@mail.gmail.com>
         (sfid-20200501_193303_702944_53D89397) <68be99836859c4216a667e5784ed0e519cc1143c.camel@sipsolutions.net>
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.32.5 (3.32.5-1.fc30) 
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: linux-wireless-owner@vger.kernel.org
Precedence: bulk

HiJohannes,

On Tue, 2020-05-26 at 14:38 +0200, Johannes Berg wrote:
> Hi James,
> 
> > > I guess you could "fix" that by running with wmediumd?
> > 
> > We do run with wmediumd, although I hadn't looking into this much.
> 
> Well, I was sort of assuming that even just running wmediumd would
> introduce the latency of another userspace roundtrip, and, perhaps
> more
> importantly, disconnect the code paths.
> 
> I didn't really think you need any additional delay, and yes, I don't
> think wmediumd supports adding additional delay, but it does add its
> own
> fake medium acquisition delay.
> 
> So maybe that means my theory was wrong?

I was actually incorrect thinking we used wmediumd, we don't :) We have
our own hwsim thing that is effectively taking the place of wmediumd.
And with this I added a very small delay to resending out the frames
and it totally fixed the issue.

Thanks,
James
> 
> johannes
>