Bug 110831

what firmware are you using?

Try to disable scheduled scan and see if it helps.

Yes, after disable scheduled scan, it works well.

please record tracing.

Look at https://wireless.wiki.kernel.org/en/users/drivers/iwlwifi/debugging

I need 2 captures: one with scheduled scan and one without.

Ping?

Our policy is to close that are pending for input within 2 weeks.

sorry, I am busy for the other issue. I will provide it in next week.

Created attachment 201361 [details]
sched_scan log

Add the sched scan log.

In the log, the log is got by the following steps.

After I disable normal scan, then enable sched scan and disable wifi.

Created attachment 201371 [details]
normal scan log

What do you mean, disable wifi?

If you disable wifi, nothing will work...

Your logs are useless. I asked for tracing, can't you get that?

I dmesg > XXX.log to get log.

For tracing, how can I catch it?

Kernel-4.1.15 is used in our system.

(In reply to wzhen12 from comment #9)
> I dmesg > XXX.log to get log.
> 
> For tracing, how can I catch it?

Look at comment #3:
https://wireless.wiki.kernel.org/en/users/drivers/iwlwifi/debugging#tracing

Please also tell me what AP you want to connect to (what profile you added to the scheduled scan).

FWIW: I consider disabling scheduled in upstream kernels and backport this to stable kernels.

1. In https://wireless.wiki.kernel.org/en/users/drivers/iwlwifi/debugging#tracing,

>To enable tracing, CONFIG_IWLWIFI_TRACING must be set.

CONFIG_IWLWIFI_TRACING has been removed in Kernel-4.1.15.

Can I need to set the other items?

2. >what profile you added to the scheduled scan?
I have no add any profiles to scheduled scan.
I use the standard wpa_supplicant to start scheduled scan.

>FWIW: I consider disabling scheduled in upstream kernels and backport this to
>stable kernels.
In short time, agree.

You need to enable CONFIG_IWLWIFI_TRACING

You must have profiles configured to have the wpa_supplicant use scheduled scan...

Created attachment 201381 [details]
wpa_supplicant's defconfig

Maybe, I misunderstand what you mean.

The attachment is the defconfig of wpa_supplicant.

Scheduled scan may be enabled in the config file but as long as you don't have configured profiles, the supplicant will not use scheduled scan since it is useless.

Thanks to check.

To my knowledge, to wpa_supplicant, if wpa_supplicant get the info of scheduled scan enabled from kernel, wpa_supplicant will use scheduled scan to replace normal scan at some interval.

Hi Emmanuel Grumbach,

Some security reasons, trace-cmd can't run in our system.
I am fixing it and will provide the related log as soon as possible.

Created attachment 202541 [details]
sched_scan wpa log

Created attachment 202551 [details]
sched_scan tracing log

I took a quick look at the logs and it doesn't make much sense.  

wpa_supplicant is starting a sched_scan with no profiles, which should be okay if it wants to find any network.  This is a very unusual case, because it's the same as a normal scan, all the results will be returned every time it runs (unless you're in the middle of nowhere with no APs beaconing).

In this case, the driver should enable "any_beacon_notify", as can be seen in the code here:

	SCAN_CLIENT_SCHED_SCAN		= BIT(0),
[...]
	profile_cfg->num_profiles = req->n_match_sets;
[...]
	if (!req->n_match_sets || !req->match_sets[0].ssid.ssid_len)
		profile_cfg->any_beacon_notify = SCAN_CLIENT_SCHED_SCAN;

But this is the profile configuration command I can see in the logs:

837.190378: iwlwifi_dev_hcmd:     SCAN_OFFLOAD_UPDATE_PROFILES_CMD (0x00.0x6e)
                                      * blacklist_len = 0x0
                                      * num_profiles = 0x0
                                      * match_notify = 0x0
                                      * pass_match = 0x0
                                      * active_clients = 0x0
                                      * any_beacon_notify = 0x0
                                      * reserved = 00:00
837.190556: iwlwifi_dev_rx:       SCAN_OFFLOAD_UPDATE_PROFILES_CMD (0x6e)

This would most likely cause the firmware to return no result.

I'll check the exact code in the kernel version you mentioned (4.1.15) to see if there is something wrong there.

You don't seem to have -e iwlwifi_msg enabled in your traces, could you rerun with that enabled as well? Please run it as described in the wiki:

sudo trace-cmd record -e iwlwifi -e mac80211 -e cfg80211 -e iwlwifi_msg

Sorry, that problem with all zeros in the SCAN_OFFLOAD_UPDATE_PROFILES_CMD I pointed out above is actually a bug in our trace-cmd parser code.

Regardless, I now suspect that this can be an issue with the TLVs of our firmware (which are flags that tell us about the firmware APIs).  It's possible that we're using the wrong size for this command.

Okay, after further investigation, I found out that the TLV is not the problem.

The actual problem is that our firmware will not send a notification to our driver when results are found but don't match any "match" entry (in this case, since there are no profiles, there are no match entries).

This use case (i.e. running a scheduled scan without any matches) is a bit useless, so I'm inclined to just reject this in the driver (as Emmanuel suggested).

Still, before I do that, I'll check if there are any other ways this problem could be fixed.

Renaming the bug to better describe the case.

Created attachment 202711 [details]
sched_scan tracing with mac80211 cfg80211 iwlwifi_msg log

sched_scan tracing with mac80211 cfg80211 iwlwifi_msg log.
Done.

Created attachment 202761 [details]
proposal patch, reject sched scans with no profiles

Thanks!

As I said above, the problem appears to be that our firmware doesn't report that there were any matches, because there is nothing to match.  It passes all beacon/probe_resp up to the driver, and those results can be retrieved with scan dump, but there is no notifications to the userspace.

Can you try this patch? We haven't decided whether to solve it this way (i.e. rejecting "match all" scans), but it would be great if you could give it a spin to see if the system behaves better.

I have tested the patches.

It can fix the current issue.

After schedule scan, normal scan of wpa_supplicant still can work well.

And after connect AP, it looks like that schedule scan work too.

Excellent! Thanks for testing!

So we now know that this works (at least with your version of wpa_s).  Maybe we go with this solution for stable kernels and look for a better way to fix it for future releases.

The fix will be merged shortly. I'll close the bug then.

This has been fixed and merged in our internal tree.  We will publish it soon (with CC stable).

Can you share the link of the patch in upstream? Thanks.

https://git.kernel.org/cgit/linux/kernel/git/iwlwifi/iwlwifi-fixes.git/commit/?id=5e56276e7555b34550d51459a801ff75eca8b907