On Thu, Aug 29, 2019 at 10:55 PM Johannes Berg <johannes@xxxxxxxxxxxxxxxx> 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?
