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: <28f1ab73ad2697578078e05cc40e9b29643d3470.camel@gmail.com>
Subject: Re: Lost beacon behavior changed as of 01afc6fed (hwsim)
From:   James Prestwood <prestwoj@gmail.com>
To:     Johannes Berg <johannes@sipsolutions.net>,
        "linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>
Date:   Mon, 10 Aug 2020 10:17:58 -0700
In-Reply-To: <65bbc2f69fe966d471eff3287a191919311ac641.camel@sipsolutions.net>
References: <ada14dfad76b93d654606c3b397de059d968096b.camel@gmail.com>
         (sfid-20200702_001244_354404_5FEC9FBA) <65bbc2f69fe966d471eff3287a191919311ac641.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

Hi,

> 
> But I suspect that it could be that you're testing this in the wrong
> way? From your description, it almost seems like you turn off the AP
> interface, and roam after that? I'm not sure that's really realistic.

Yes, your right. I guess we just got away with this since the behavior
was different previously.

> If
> you wanted to test the "a few beacons were lost" behaviour, then
> you'd
> really have to lose a few beacons only (perhaps by adding something
> to
> wmediumd?), and not drop the AP off the air entirely.

Yeah, I think this is what we will have to do. Target beacons
specifically to block (and just a few) vs everything. 

> 
> If the AP is in fact completely unreachable, then I'm pretty sure
> real
> hardware will behave just like hwsim here, albeit perhaps a bit
> slower,
> though not by much. And then you'd have the same issue there.
> 
> The fact that hwsim behaved differently would likely have been just a
> timing thing - it didn't advertise REPORTS_TX_ACK_STATUS, so we'd
> wait a
> bit longer until deciding that the AP really was truly gone. If the
> ACK
> status is reported we just send a (few?) quick nullfunc(s) and decide
> that very quickly. But that's independent on hwsim or real hardware.
> 
> 
> johannes
> 

Thanks,
James