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.
This command is supposed to return the PIN value that was generated
or passed in as an argument. In the AP case, the entered PIN was not
being returned.
This is needed to be able to change parameters for dynamically
created interfaces between the creation of the interface and
association/start AP commands.
Following ctrl_interface commands can now be used:
P2P_SET client_apsd disable
- disable configuration (i.e., use driver default) in client mode
P2P_SET client_apsd <BE>,<BK>,<VI>,<VO>;<max SP Length>
- enable UASPD with specific trigger configuration (0/1) per AC
(max SP Length is currently ignored)
P2P_SET go_apsd disable
- disable configuration (i.e., use driver default) in AP mode
P2P_SET go_apsd <0/1>
- disable/enable APSD in AP mode
This event indicates the Device Password ID that the peer tried
to use in GO Negotiation. For example:
P2P-GO-NEG-REQUEST 02:40:61:c2:f3:b7 dev_passwd_id=4
If enabled, cross connection allows GO to forward IPv4 packets
using masquerading NAT from the P2P clients in the group to an
uplink WLAN connection. This is disabled by default and can be
enabled with "wpa_cli p2p_set cross_connect 1" on the P2P device
interface.
For now, this applies to the test command that can be used to set
periodic NoA (p2p_set noa). The value are stored and periodic NoA
is enabled whenever there are no non-P2P STAs connected to the GO.
While this is not strictly speaking required by the P2P specification
for a not-P2P Managed Device, this can provide useful information for
the P2P manager AP and may be needed to pass certification tests.
For client-invites-device case, the pre-authorization of an invitation
to running group will need to allow Invitation Request from specified
address, too. This is for testing uses only.
"wpa_cli p2p_set peer_filter <MAC address>" can now be used to
only allow a single P2P Device (based on P2P Device Address) to be
discovered for testing. Setting the address to 00:00:00:00:00:00
disables the filter.
This is mainly designed for testing and allows p2p_connect join auth
to be used to accept a specific invitation to an active group that
may be received in the future.
The driver event for remain-on-channel may be delayed in a way that
allows management-frame-received event to be received before
wpa_supplicant knows that the driver is actually already on the
previously requested channel. We should not request a new
remain-on-channel to send a response to just a frame if we are waiting
for the driver to get to the same channel. Instead, just continue
waiting for the driver event.
When the first wpa_supplicant interface is not the correct one for
transmitting an Action frame (e.g., P2P Presence Request frame
uses a group interface), the code got stuck in an infinite busy
loop. Fix the iteration to go through the interfaces properly.
