On Thu, Aug 29, 2019 at 10:55 PM Johannes Berg
<johan...@sipsolutions.net> wrote:
>
> On Thu, 2019-08-29 at 14:04 -0300, Ramon Fontes wrote:
> > Yes, that's what I (we?) expect.
> >
> > Yes, wmediumd has some log files, but they don't help me to identify
> > the reason of the problem. I also unsuccessfully tried to modified the
> > wmediumd code. Both wmediumd and mac80211_hwsim work fine up to kernel
> > version 4.17. The problem comes only from kernel 4.18. Since there are
> > some wmediumd related-codes in mac80211_hwsim, I was wondering whether
> > something wasn't missing in mac80211_hwsim (or even some needed
> > changes in wmediumd) that is causing such problem.
>
> Hmm, but are there? There's basically no change in hwsim between 4.17
> and 4.18, only a few error path cleanups/fixes and the SUPPORTS_PS
> change which also shouldn't matter for this?
>
> > Another weird thing
> > is the channel, since the channel is the same as defined in hostapd
> > and doesn't match 5Ghz channels.
>
> You mean the DS element? That's just from the frame itself.
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?
