Received-SPF: pass (google.com: best guess record for domain of linux-wireless-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <CAK8U23biuUY9hWE1NOnSbJCRtRVfdg1a27ZOkU5cbaGdzZLYEA@mail.gmail.com>
 <fa029365caf3db963b1c2ec05ae389a8c8fc20fb.camel@sipsolutions.net>
 <CAK8U23aHprXtZm2PV3sj6g4Da_ponK9L0YmSO1tb6xoFgK-ZLA@mail.gmail.com>
 <80d9c12986ec0a13c34672ca1c16f37cae0cc096.camel@sipsolutions.net>
 <CABPxzYLrTC3kS86iyfq+RY=XEgjedu2MWPtn+i+H50jPz3oh3w@mail.gmail.com> <39d646206446159a2b0a67ee7d8667483ade0733.camel@sipsolutions.net>
In-Reply-To: <39d646206446159a2b0a67ee7d8667483ade0733.camel@sipsolutions.net>
From:   Krishna Chaitanya <chaitanya.mgit@gmail.com>
Date:   Fri, 30 Aug 2019 13:51:59 +0530
Message-ID: <CABPxzYL0i+YbKh-xMXsS-xWeQvwfFUvv7vGhugM1e+OFMOSHSg@mail.gmail.com>
Subject: Re: mac80211_hwsim (kernel 4.18+): wmediumd + 2.4Ghz
To:     Johannes Berg <johannes@sipsolutions.net>
Cc:     Ramon Fontes <ramonreisfontes@gmail.com>,
        linux-wireless <linux-wireless@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-wireless-owner@vger.kernel.org
Precedence: bulk

On Fri, Aug 30, 2019 at 1:02 PM Johannes Berg <johannes@sipsolutions.net> wrote:
>
> On Fri, 2019-08-30 at 00:35 +0530, Krishna Chaitanya wrote:
> >
> > Is this supposed to work at all? AFAICS, in hwsim channel matching
> > checks are only done in non-mediumd path (no_nl), and wmediumd also
> > doesn't have any checks? So, hostapd responds to all probe requests in all
> > channels. Am I missing something?
>
> Hmm. Interesting observation, I wasn't aware of that.
>
> That certainly explains the situation though - on 2.4 GHz we'd prefer
> using the DS Element, and thus not use the scan result, while on 5 GHz
> we assume that the reported RX frequency is correct (there's no channel
> overlap).
>
> Still doesn't explain why it should work in 4.17 and not in 4.18, there
> aren't a lot of wifi changes there at all.
Yes the git log also doesn't show any changes in this area.
>
> I guess we should fix that in hwsim, anyone esle want to? :-)
I can give it a try to move the channel matching logic to common
code for both nl and no_nl.