This is a workaround for incorrect configuration (missing
virtual/physical identifier for config methods) for WPS 2.0 to
allow unmodified configuration from WPS 1.0 to be used while
enforcing compliant WPS 2.0 values.
The AP operation with wpa_supplicant requires an additional callback
to get the needed event information from hostapd side so that
wpa_msg() can be called for wpa_s->parent if needed.
This makes it easier to figure out what could have failed in the
WPS protocol and potentially provide more information for the
user on how to resolve the issue.
The driver wrapper can now indicate whether the driver supports
concurrent operations on multiple channels (e.g., infra STA connection
on 5 GHz channel 36 and P2P group on 2.4 GHz channel 1). If not,
P2P_CONNECT commands will be rejected if they would require
multi-channel concurrency.
The new failure codes for P2P_CONNECT:
FAIL-CHANNEL-UNAVAILABLE:
The requested/needed channel is not currently available (i.e., user has
an option of disconnecting another interface to make the channel
available).
FAIL-CHANNEL-UNSUPPORTED:
The request channel is not available for P2P.
Allow only the expected P2P Interface Address as the BSSID for
the AP to avoid selecting incorrect BSS should there be another
device that is advertising active PBC mode before the target
P2P GO does.
When the P2P state machine requests a remain- on-channel, there's a
potential race where it can then request a stop before the r-o-c has
actually started, in which case the stop will not be processed. Fix
that.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The new DBus API helper function wpas_dbus_error_unknown_error
function can be called as a result of a failure within internal
getter calls, which will call this function with a NULL message
parameter. However, dbus_message_new_error looks very unkindly
(i.e, abort()) on a NULL message, so in this case, we should not
call it.
I've observed this course of events during a call to
wpas_dbus_getter_bss_wpa with a faileld parse of the IE parameter.
We got here through a call to fill_dict_with_properties which
explicitly calls getters with a NULL message parameter. Judging
from the way it is called, this could easily occur if an AP sends
out a malformed (or mis-received) probe response. I usually run
into this problem while driving through San Francisco, so I'm
exposed to any number of base stations along this path.
This patch changes wpa_supplicant policy for handling '' in SSIDs field of
Interface.SSID DBus message. It treats '' (zero-length) SSID as a request
for a broadcast scan, instead of ignoring it.
This patch updates DBus API .Scan() logic per the test cases listed below:
1) Interface.Scan({'Type':'active', 'Channel':(2412, 20)})
Request: Active scan with only '' SSID (1 channel)
Should be: 1 broadcast ProbeRequest on specified channel
Previous: 1 broadcast ProbeRequest on specified channel
This Patch: 1 broadcast ProbeRequest on specified channel
2) Interface.Scan({'Type':'active', 'Channel':(2412, 20), 'SSIDs':['']})
Request: Active scan with only '' SSID (1 channel)
Should be: 1 broadcast ProbeRequest on specified channel
Previous: No ProbeRequests; passive scan results for specified channel
This Patch: FIXED: 1 broadcast ProbeRequest on specified channel
3) Interface.Scan({'Type':'active', 'Channel':(2412, 20), 'SSIDs':['MySSID']})
Request: Active scan with only non-'' SSIDs (1 channel)
Should be: 1 directed ProbeRequest for each SSID on specified channel,
no broadcast ProbeRequest
Previous: 1 directed ProbeRequest for each SSID on specified channel,
no broadcast ProbeRequest
This Patch: 1 directed ProbeRequest for each SSID on specified channel,
no broadcast ProbeRequest
4) Interface.Scan({'Type':'active', 'Channel':(2412, 20), 'SSIDs':['',
'MySSID']})
Request: Active scan with SSIDs, including 1 '' SSID (1 channel)
Should be: 1 broadcast ProbeRequest, 1 directed ProbeRequest for each
non-'' SSID on specified channel
Previous: 1 directed ProbeRequest for each non-'' SSID on specified
channel
This Patch: FIXED: 1 broadcast ProbeRequest, 1 directed ProbeRequest for
each non-'' SSID on specified channel
Currently the DBus Interface.Scan API is counter-intuitive. It issues
ProbeRequests when doing passive scans when channels are specified, and
does not issue ProbeRequests for broadcast active scans.
This patch updates DBus API .Scan() logic per the test cases listed below:
1) Interface.Scan({'Type':'passive'})
Request: Passive scan (all channels)
Should be: No ProbeRequests; Passive Scan results for all channels
Previous: 1 ProbeRequest on all channels for both broadcast SSID and
selected network (scan_ssid=1)
This Patch: --No change--: 1 ProbeRequest on all channels for both
broadcast SSID and selected network (scan_ssid=1)
2) Interface.Scan({'Type':'passive', 'Channel':(2412, 20)})
Request: Passive scan (1 channel)
Should be: No ProbeRequests; Passive Scan results for 1 channel
(plus overlapping channels)
Previous: 1 broadcast ProbeRequest on specified channel
This Patch: --Fixed--: No ProbeRequests; Passive Scan results for 1
channel (plus overlapping channels)
3) Interface.Scan({'Type':'active'})
Request: Active scan with no SSIDs (all channels)
Should be: 1 broadcast ProbeRequest on all channels
Previous: No ProbeRequests; passive scan results for all channels
This Patch: --Fixed--: 1 broadcast ProbeRequest on all channels
4) Interface.Scan({'Type':'active', 'Channel':(2412, 20)})
Request: Active scan with no SSIDs (1 channel)
Should be: 1 broadcast ProbeRequest on specified channel
Previous: No ProbeRequests; Passive scan results for specified
channel (plus overlapping channels)
This Patch: --Fixed--: 1 broadcast ProbeRequest on specified channel
The previous used .gitignore files were mathing some files that
were actually already in the repository (e.g.,
hostapd/logwatch/hostapd). Avoid this by listing the conflicting
entries in the root directory .gitignore with full path.
This cleans up debug log from unnecessary entries when using
wpa_cli/hostapd_cli or other ctrl_iface monitors that PING
periodically to check connectivity.
WPS 2.0 mandates the AP to include WPS IE in (Re)Association Response
if the matching (Re)Association Request included WPS IE. Provide the
needed WPS IE information to the driver_ops API for drivers that
process association frames internally.
Note: This modifies the driver_ops API by adding a new argument to
set_ap_wps_ie().
Instead of build time options (CONFIG_WPS_TESTING_EXTRA_CRED and
CONFIG_WPS_EXTENSIBILITY_TESTING), use a single build option
(CONFIG_WPS_TESTING) and runtime configuration of which testing
operations are enabled. This allows a single binary to be used
for various tests.
The runtime configuration can be done through control interface
with wpa_cli/hostapd_cli commands:
Enable extensibility tests:
set wps_version_number 0x57
Disable extensibility tests (WPS2 build):
set wps_version_number 0x20
Enable extra credential tests:
set wps_testing_dummy_cred 1
Disable extra credential tests:
set wps_testing_dummy_cred 0
Previously, wpa_supplicant remaining in scanning state without
trying to connect, but there is no particular need to do that.
Instead, cancel WPS operation completely whenever PBC session
overlap is detected.
Disconnection event may be received while in associating state.
Previously, wpa_supplicant could get stuck not trying to reconnect
in that case at least with nl80211. Allow scan request in this
state to avoid the issue. This helps especially with APs that do
load balancing by sending Deauthentication frame as a response to
Reassociation Request frame after successful Authentication frame
exchange.
ctrl_interface STA_AUTOCONNECT command can now be used to disable
automatic reconnection on receiving disconnection event. The default
behavior is for wpa_supplicant to try to reconnect automatically, i.e.,
to maintain previous behavior.
The overlap condition cannot disappear before group formation timeout
hits, so there is no point in continuing in this case and failure can
be indicated immediately.
This allows the pending group interface to be removed if we fail
to join a running group. A longer than 15 second timeout is needed
here since the GO may not have authorized our connection yet.
A new ctrl_interface command, WPS_CANCEL, can now be used to cancel
a pending or ongoing WPS operation. For now, this is only available
with wpa_supplicant (either in station or AP mode). Similar
functionality should be added for hostapd, too.
The scan operation before Provision Discovery Request may not include
the GO. However, we are likely to have the GO in our P2P peer table,
so use that information to figure out the operating channel if BSS
table entry is not available.
This is needed to make sure we do not try to accidentally enable GO
in channels that may not be allowed. In addition, this may help with
some driver that do not like channel 14 even as a passive scan
channel.
