Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <a2c1706527d11312b504f8d445bcbba7738f9c8c.camel@sipsolutions.net>
Subject: Re: poor beacon/scan reliability with mac80211_hwsim
From:   Johannes Berg <johannes@sipsolutions.net>
To:     James Prestwood <prestwoj@gmail.com>,
        "linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>
Date:   Wed, 23 Mar 2022 19:50:13 +0100
In-Reply-To: <928be46d97a3da3fd677c9d87f9be6a02f4d3277.camel@gmail.com>
References: <928be46d97a3da3fd677c9d87f9be6a02f4d3277.camel@gmail.com>
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.42.4 (3.42.4-1.fc35) 
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Precedence: bulk

Hi James,

> We use mac80211_hwsim and our own 'hwsim' daemon to test conditions
> like poor signal strength or dropped frames. For quite a while we've
> noticed very poor reliability related to scanning when
> HWSIM_CMD_REGISTER is used to process frames. Scan results are just
> empty.
> 
> We've put in some work arounds like only registering for tests that
> absolutely need it and repeatedly scanning until the expected network
> is found, but there are cases where this is not possible.
> 
> I'm hoping for some ideas on how to actually fix this problem rather
> than continue trying to come up with workarounds. I have tried removing
> any frame processing (just an empty function) and noticed the problem
> still occurs, basically just calling HWSIM_CMD_REGISTER causes these
> problems.
> 
> I will admit this seems to happen more on slower systems, like inside a
> virtual machine environment, or in tests which create more than just a
> few radios (like ~5-6+) so it does seem like mac80211_hwsim/wmediumd
> processing the frame is just taking too long for beacons.
> 

That sounds like it's just scheduling? HWSIM_CMD_REGISTER makes all the
frames go through the wmediumd (or whatever other tool you use),
including the beacons - which makes sense, but there's scheduling
overhead. Also probe requests/probe responses will go through, and we
only wait for a limited time on each channel for a response/beacon.

Though I'm surprised the overhead and all is enough to make the jump out
to userspace and back take 30+ milliseconds (which is the smallest
possible dwell time if you have hwsim hw-scan enabled, otherwise it's
slightly larger).

Maybe, since beacons are sent periodically, and perhaps we can assume
the overhead is always similar, then you could do passive scanning?

No good answers to this, I guess ...

Though if you can run tests under UML/time-travel that would get rid of
this problem ;-)

johannes