P2P: speed up scans when connecting to persistent GO (UPSTREAM)

In the case of a persistent GO invoking a P2P group by invite
the P2P client starts scanning for the GO but it might still
not be up. If not found the next scan is scheduled for scan_interval
secs but this too long.
Speed up scans to find GO like it's being done in P2P provisioing.

Signed-off-by: Eyal Shapira <eyal@wizery.com>
Revert "Add P2P IEs to probe requests only when in P2P (UPSTREAM)"

This is replaced by a recent patch by Jouni in the upstream:
"P2P: Allow P2P functionality to be disabled per interface"

This reverts commit a56f6df6f8e5dcd650893e8beb4a16a633c179d1.

Conflicts:

	src/p2p/p2p.c
P2P: Allow P2P functionality to be disabled per interface

By default, P2P is enabled globally for all virtual interfaces and this
makes wpa_supplicant include WSC and P2P IEs in Probe Request frames for
all scans even if this is for a non-P2P station connection to speed up
device discovery. If an interface is dedicated for non-P2P station mode
operations, it is now possible to disable addition of WSC and P2P IEs
into Probe Request frames with a per-interface p2p_disabled parameter.
This can be set either in the configuration file (p2p_disabled=1) or at
run time ("wpa_cli -i wlan0 set p2p_disabled 1"). Unlike the previous
mechanism ("wpa_cli p2p_set disabled 1"), the new parameter changes the
behavior only for the specified interface while other interfaces
continue to follow the global P2P enabled/disabled state.

Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
Signed-off-by: Eyal Shapira <eyal@wizery.com>
Disable p2p on wlan0 (JB)

This prevents P2P IEs from being added to probes of scans on the
STA interface. These are not needed and prolong required channel
dwell time and Tx of probes.

This is somewhat of a hack but was a preferred approach on adding
framework changes to add p2p_disabled=1 to p2p_supplicant.conf and
not to wpa_supplicant.conf when both are created from the same template.

Signed-off-by: Eyal Shapira <eyal@wizery.com>
Avoid normal scans before sched scan if max_scan_ssids=1 (UPSTREAM)

In the case of max_scan_ssids=1 we may fallback to normal scan
if there's a single scan_ssid network. However the normal scan
can't add a wildcard SSID to the ssid list as it's limited to a single
entry. This delays getting broadcast scan results.
Always prefer to do a sched scan in such a case.

Signed-off-by: Eyal Shapira <eyal@wizery.com>
Allow concurrent normal scan and sched scan (UPSTREAM)

Some drivers support sched scan and normal scan. Enable this
by configuration of concurrent_sched_scan=1
This can speed up connection to scan_ssid=1 networks as
the sched scan doesn't get interrupted by a normal scan
for wildcard SSID.

Signed-off-by: Eyal Shapira <eyal@wizery.com>
android: wpa_s template: enable concurrent_sched_scan (ANDROID)

Our solution supports this and it speeds up initial connection
to hidden networks.

Signed-off-by: Eyal Shapira <eyal@wizery.com>
Trigger sched scan on wpa_s init if enabled networks (INTERNAL)

The switch to triggering a normal scan initially was done
to prevent interference between sched scan and normal scan.
This is no longer an issue. Triggering a sched scan is better
as it works better in our case than the normal scan
wrt hidden networks.

Signed-off-by: Eyal Shapira <eyal@wizery.com>
Don't disable and select new network if SETBAND didn't change (ANDROID)

Current SETBAND would trigger network selection and as part of this
a scan attempt. This is not required in case SETBAND didn't change the
existing setting.

In Android which sends SETBAND immediately after WiFi startup this
would trigger needless scan attempts which would usually fail with -EBUSY
as another framework triggers scan was already going on.
The retry mechanism would then attempt further scans every 1 sec.

Signed-off-by: Eyal Shapira <eyal@wizery.com>