The WSC 2.0 specification moved to use another design for the new
attributes to avoid backwards compatibility issues with some
deployed implementations.
If CONFIG_WPS_STRICT is set, validate WPS IE(s) in management frames and
reject the frames if any of the mandatory attributes is missing or if an
included attribute uses an invalid value. In addition, verify that all
mandatory attributes are included and have valid values in the WSC
messages.
If all the device information attributes use their maximum lengths,
a single WPS IE is not enough to fit in all the data and as such,
we must be able to fragment the data. In addition, the wpabuf needs
to be allocated larger to fit in maximum data.
Instead of using 0x00 as the extra character, use space (' ') to
avoid failing tests that verify that the variable length string
attributes are not null terminated. In addition, this workaround
can now be disabled by defining CONFIG_WPS_STRICT for the build.
This can be done by adding following line to .config:
CFLAGS += -DCONFIG_WPS_STRICT
However, it should be noted that such a build may not interoperate
with some deployed WPS 1.0 -based implementations and as such, is
mainly designed for testing.
Whenever wpa_supplication is using Request Type Enrollee, it is trying
to enroll into a network. Indicate this with the explicit inclusion of
Request to Enroll attribute with value TRUE.
Advertize list of authorized enrollee MAC addresses in Beacon and
Probe Response frames and use these when selecting the AP. In order
to provide the list, the enrollee MAC address should be specified
whenever adding a new PIN. In addition, add UUID-R into
SetSelectedRegistrar action to make it potentially easier for an AP
to figure out which ER sent the action should there be multiple ERs
using the same IP address.
This adds definitions and parsing of the new attributes that were added
in WPS 2.0. In addition, the version negotiation is updated to use the
new mechanism, i.e., accept everything received and use the new Version2
attribute in transmitted messages.
There is no need to process the public key and generate keys if
the AP is going to reject this M2 anyway. This limits effect of
potential CPU DoS attacks in cases where AP PIN is disabled.
A new hostapd_cli command, wps_ap_pin, can now be used to manage
AP PIN at runtime. This can be used to generate a random AP PIN and
to only enable the AP PIN for short period (e.g., based on user
action on the AP device). Use of random AP PIN that is only enabled
for short duration is highly recommended to avoid security issues
with a static AP PIN.
This can happen on the AP if the AP PIN is not configured and
the client tries to go through the protocol instead of just using
Registrar mode to receive M1 from the AP. It is cleaner to send
out the WSC_NACK instead of just stopping the protocol.
In theory, this should not really be needed, but Windows 7 uses
Registrar mode to probe AP's WPS capabilities before trying to use
Enrollee and fails if the AP does not allow that probing to happen.
This allows the AP to start as an Enrollee and send M1, but refuse
to continue beyond that (M3 will not be sent if AP PIN is not known).
It looks like 10.6.3 and 10.6.4 do not like to receive Network Key
with WPA passphrase while PSK format still works. Use peer information
from M1 to figure out whether the Enrollee is likely to be OS X and
if so, force PSK format to be used for Network Key.
The AP configuration may change after provisioning, so it is better
not to use the current security policy to prioritize results. Instead,
use WPS Selected Registrar attribute as the main sorting key and use
signal strength next without considering security policy or rate sets.
The non-WPS provisioning case remains as-is, i.e., this change applies
only when trying to find an AP for WPS provisioning.
Some deployed implementations do not include the mandatory Network
Key attribute when a WPS Credential is for an open network. Allow
this to improve interoperability since the actual key value is not
really needed for open networks.
wps_er_config can now be used to configure an AP. It is similar to
wps_er_learn, but instead of only learning the current AP settings,
it continues to send M8 with the new settings for the AP.
wps_er_start command now takes an optional parameter that can be used
to configure a filter to only allow UPnP SSDP messages from the
specified IP address. In practice, this limits the WPS ER operations
to a single AP and filters out all other devices in the network.
When starting the protocol run with an Enrollee, clone the AP Settings
and replace the AP MAC Address with the Enrollee MAC Address so that the
correct value is then used in the Credential attribute in M8.
If the associating station indicates that it is intents to use WPS
by including WPS IE in (Re)Association Request frame, include WPS IE
in (Re)Association Response frame.
There are no subdirectories in any of these directories or plans
for adding ones. As such, there is no point in running the loop
that does not do anything and can cause problems with some shells.
