Hello,
When I use 2.4Ghz band with -only one- AP (running on top of hostapd)
I get a (additional) list of frequencies at 5Ghz. When I do "iw dev ..
scan"
BSS 02:00:00:00:04:00(on sta1-wlan0) -- associated
TSF: 1566905272877856 usec (18135d, 11:27:52)
freq: 2422
beacon interval: 100 TUs
capability: ESS ShortSlotTime (0x0401)
signal: -34.00 dBm
last seen: 0 ms ago
Information elements from Probe Response frame:
SSID: simplewifi
Supported rates: 1.0* 2.0* 5.5* 11.0* 6.0 9.0 12.0 18.0
DS Parameter set: channel 3
ERP: Barker_Preamble_Mode
Extended supported rates: 24.0 36.0 48.0 54.0
Extended capabilities:
* Extended Channel Switching
* Multiple BSSID
* SSID List
* Operating Mode Notification
BSS 02:00:00:00:04:00(on sta1-wlan0)
TSF: 1566905274269230 usec (18135d, 11:27:54)
freq: 5180
beacon interval: 100 TUs
capability: ESS ShortSlotTime (0x0401)
signal: -34.00 dBm
last seen: 0 ms ago
Information elements from Probe Response frame:
SSID: simplewifi
Supported rates: 1.0* 2.0* 5.5* 11.0* 6.0 9.0 12.0 18.0
DS Parameter set: channel 3
...
BSS 02:00:00:00:04:00(on sta1-wlan0)
TSF: 1566905274269230 usec (18135d, 11:27:54)
freq: 5200
beacon interval: 100 TUs
capability: ESS ShortSlotTime (0x0401)
signal: -34.00 dBm
last seen: 0 ms ago
Information elements from Probe Response frame:
SSID: simplewifi
Supported rates: 1.0* 2.0* 5.5* 11.0* 6.0 9.0 12.0 18.0
DS Parameter set: channel 3
...
and so on (please notice that channel number and frequency)..
iw dev scan returns all the 5Ghz frequencies defined in
https://github.com/torvalds/linux/blob/master/drivers/net/wireless/mac80211_hwsim.c#L328
It happens only when wmediumd is being used. When hostapd is running
with 5Ghz it seems to work as expected, since iw returns only the AP
running at 5Ghz. In other words, the problem occurs only when hostapd
is running at 2.4Ghz.
I noticed that it happens from kernel 4.18. If I comment
https://github.com/torvalds/linux/blob/b55f3b841099e641bdb2701d361a4c304e2dbd6f/drivers/net/wireless/mac80211_hwsim.c#L2838,
iw returns only 2422Mhz. However, I couldn't find the reason for such
problem.
There could be some problem with mac80211_hwsim, or am I missing something here?
Best Regards,
Ramon Fontes
Hi,
> When I use 2.4Ghz band with -only one- AP (running on top of hostapd)
> I get a (additional) list of frequencies at 5Ghz. When I do "iw dev ..
> scan"
>
> BSS 02:00:00:00:04:00(on sta1-wlan0) -- associated
> TSF: 1566905272877856 usec (18135d, 11:27:52)
> freq: 2422
> beacon interval: 100 TUs
> capability: ESS ShortSlotTime (0x0401)
> signal: -34.00 dBm
> last seen: 0 ms ago
> Information elements from Probe Response frame:
> SSID: simplewifi
> Supported rates: 1.0* 2.0* 5.5* 11.0* 6.0 9.0 12.0 18.0
> DS Parameter set: channel 3
> ERP: Barker_Preamble_Mode
> Extended supported rates: 24.0 36.0 48.0 54.0
> Extended capabilities:
> * Extended Channel Switching
> * Multiple BSSID
> * SSID List
> * Operating Mode Notification
I guess this is the one you expect?
> BSS 02:00:00:00:04:00(on sta1-wlan0)
> TSF: 1566905274269230 usec (18135d, 11:27:54)
> freq: 5180
[...]
> BSS 02:00:00:00:04:00(on sta1-wlan0)
> TSF: 1566905274269230 usec (18135d, 11:27:54)
> freq: 5200
and these are garbage.
> and so on (please notice that channel number and frequency)..
> iw dev scan returns all the 5Ghz frequencies defined in
> https://github.com/torvalds/linux/blob/master/drivers/net/wireless/mac80211_hwsim.c#L328
> It happens only when wmediumd is being used.
Since you cannot reproduce this without wmediumd (and neither can I) I
assume it's a wmediumd bug, in the sense that it's reporting the frame
on all the channels, or perhaps without any channel information, or so?
Or possibly the hwsim code that handles this is broken, maybe you could
see what wmediumd does (does it have any log files?)
johannes
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. Another weird thing
is the channel, since the channel is the same as defined in hostapd
and doesn't match 5Ghz channels.
On Thu, Aug 29, 2019 at 11:57 AM Johannes Berg
<[email protected]> wrote:
>
> Hi,
>
> > When I use 2.4Ghz band with -only one- AP (running on top of hostapd)
> > I get a (additional) list of frequencies at 5Ghz. When I do "iw dev ..
> > scan"
> >
> > BSS 02:00:00:00:04:00(on sta1-wlan0) -- associated
> > TSF: 1566905272877856 usec (18135d, 11:27:52)
> > freq: 2422
> > beacon interval: 100 TUs
> > capability: ESS ShortSlotTime (0x0401)
> > signal: -34.00 dBm
> > last seen: 0 ms ago
> > Information elements from Probe Response frame:
> > SSID: simplewifi
> > Supported rates: 1.0* 2.0* 5.5* 11.0* 6.0 9.0 12.0 18.0
> > DS Parameter set: channel 3
> > ERP: Barker_Preamble_Mode
> > Extended supported rates: 24.0 36.0 48.0 54.0
> > Extended capabilities:
> > * Extended Channel Switching
> > * Multiple BSSID
> > * SSID List
> > * Operating Mode Notification
>
> I guess this is the one you expect?
>
> > BSS 02:00:00:00:04:00(on sta1-wlan0)
> > TSF: 1566905274269230 usec (18135d, 11:27:54)
> > freq: 5180
> [...]
> > BSS 02:00:00:00:04:00(on sta1-wlan0)
> > TSF: 1566905274269230 usec (18135d, 11:27:54)
> > freq: 5200
>
> and these are garbage.
>
> > and so on (please notice that channel number and frequency)..
> > iw dev scan returns all the 5Ghz frequencies defined in
> > https://github.com/torvalds/linux/blob/master/drivers/net/wireless/mac80211_hwsim.c#L328
> > It happens only when wmediumd is being used.
>
> Since you cannot reproduce this without wmediumd (and neither can I) I
> assume it's a wmediumd bug, in the sense that it's reporting the frame
> on all the channels, or perhaps without any channel information, or so?
>
> Or possibly the hwsim code that handles this is broken, maybe you could
> see what wmediumd does (does it have any log files?)
>
> johannes
>
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.
johannes
On Thu, Aug 29, 2019 at 10:55 PM Johannes Berg
<[email protected]> 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?
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.
I guess we should fix that in hwsim, anyone esle want to? :-)
johannes
On Fri, Aug 30, 2019 at 1:02 PM Johannes Berg <[email protected]> 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.
> 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.
I just tested it with 4.15 and it didn't work. However, It works in
4.15 in other PC. At first these 2 PCs have the same packages with
apparently the same version. The only thing I can highlight about the
difference between them is that: (i) Ubuntu has been upgraded from
16.04 to 18.04 (it works fine up to 4.17) and (ii) Ubuntu 18.04 has
been installed from scratch (it doesn't work at all - tested from
4.15).
On Fri, Aug 30, 2019 at 5:22 AM Krishna Chaitanya
<[email protected]> wrote:
>
> On Fri, Aug 30, 2019 at 1:02 PM Johannes Berg <[email protected]> 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.
On Sun, Sep 29, 2019 at 10:50 PM Ramon Fontes <[email protected]> wrote:
>
> > 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.
>
> I just tested it with 4.15 and it didn't work. However, It works in
> 4.15 in other PC. At first these 2 PCs have the same packages with
> apparently the same version. The only thing I can highlight about the
> difference between them is that: (i) Ubuntu has been upgraded from
> 16.04 to 18.04 (it works fine up to 4.17) and (ii) Ubuntu 18.04 has
> been installed from scratch (it doesn't work at all - tested from
> 4.15).
Based on this info, looks like hostapd/wpa_s versions might be causing
the difference,
can you please confirm the versions on both?
> Based on this info, looks like hostapd/wpa_s versions might be causing
> the difference,
> can you please confirm the versions on both?
They have the same hostap (hostapd + wpa_s) version:
Hostapd v2.10-devel-hostap_2_9-102-g12de14907+
wpa_supplicant v2.10-devel-hostap_2_9-102-g12de14907+
I've tested with v2.8-devel-hostap_2_7-313-g3e949655c+ too.
In this short video (https://www.youtube.com/watch?v=f6rrHIGpePA -
running on VirtualBox) you can see the problem in action. Through this
video you can see that it works with 4.16 and 4.17, and doesn't work
with 4.19 (I forgot to repeat the test with 4.18, but I confirm that
it has the same behaviour as 4.19).
On Mon, 2019-09-30 at 15:28 -0300, Ramon Fontes wrote:
> > Based on this info, looks like hostapd/wpa_s versions might be causing
> > the difference,
> > can you please confirm the versions on both?
>
> They have the same hostap (hostapd + wpa_s) version:
> Hostapd v2.10-devel-hostap_2_9-102-g12de14907+
> wpa_supplicant v2.10-devel-hostap_2_9-102-g12de14907+
Do they also have the same version of wmediumd?
> I've tested with v2.8-devel-hostap_2_7-313-g3e949655c+ too.
>
> In this short video (https://www.youtube.com/watch?v=f6rrHIGpePA -
> running on VirtualBox) you can see the problem in action. Through this
> video you can see that it works with 4.16 and 4.17, and doesn't work
> with 4.19 (I forgot to repeat the test with 4.18, but I confirm that
> it has the same behaviour as 4.19).
Regardless, we should fix this stuff ...
johannes
> Do they also have the same version of wmediumd?
Yes, they have the same version. As you can also see through the
video, I only change the kernel and all the packages have the same
version. I also tried to check the latest commits of mac80211_hwsim,
but haven't found a reason for the problem yet.
On Tue, 2019-10-01 at 10:19 -0300, Ramon Fontes wrote:
> > Do they also have the same version of wmediumd?
>
> Yes, they have the same version. As you can also see through the
> video, I only change the kernel and all the packages have the same
> version. I also tried to check the latest commits of mac80211_hwsim,
> but haven't found a reason for the problem yet.
I had been looking, but didn't consider that where you say "4.18" you
probably meant "4.18.xyz" for some stable version of 4.18 ...
Now that I look at that, I think most likely the reason is commit
119f94a6fefc ("cfg80211: Address some corner cases in scan result
channel updating") which was backported to the 4.18 series.
Before this commit, we'd have used the DS element all the time, after
this commit we'd trust the RX channel on 5 GHz...
Here's a test to reproduce this:
https://p.sipsolutions.net/63b37d07fd52179c.txt
However, I think the only reasonable way to fix this is in wmediumd:
https://p.sipsolutions.net/6c52392b5e31d9d1.txt
Bob, what do you think?
johannes
> Now that I look at that, I think most likely the reason is commit
> 119f94a6fefc ("cfg80211: Address some corner cases in scan result
> channel updating") which was backported to the 4.18 series.
The problem is now fixed! :)
Thank you so much for your support Johannes.
Sorry for my ignorance but where can I follow up with these wmediumd changes?
https://p.sipsolutions.net/6c52392b5e31d9d1.txt
Btw, I've created a PR for this in the Bob's repo:
https://github.com/bcopeland/wmediumd/pull/21/files
--
Ramon Fontes
On Tue, Oct 01, 2019 at 02:01:06PM -0300, Ramon Fontes wrote:
> > Now that I look at that, I think most likely the reason is commit
> > 119f94a6fefc ("cfg80211: Address some corner cases in scan result
> > channel updating") which was backported to the 4.18 series.
>
> The problem is now fixed! :)
> Thank you so much for your support Johannes.
>
> Sorry for my ignorance but where can I follow up with these wmediumd changes?
> https://p.sipsolutions.net/6c52392b5e31d9d1.txt
>
> Btw, I've created a PR for this in the Bob's repo:
> https://github.com/bcopeland/wmediumd/pull/21/files
Thanks, I merged that.
--
Bob Copeland %% https://bobcopeland.com/