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.
Some ER implementation (e.g., some versions of Intel PROSet) seem to
use incorrect format for WLANEventMAC variable in PutWLANResponse.
Work around this by allowing various MAC address formats to be used
in this variable (debug message will be shown if the colon-deliminated
format specified in WFA WLANConfig 1.0 is not used).
This avoids conflict with both Label and Display being included at
the same time (which would make it difficult to figure out which
PIN was actually used).
This attribute is supposed to indicate which methods the AP supports as
an Enrollee for adding external Registrars. It was left to 0 when the
AP code did not yet support external Registrars and was forgotten when
the ER support was added.
This patch allows wpa_supplicant to compile on Debian's kfreebsd
architectures.
Patch by Stefan Lippers-Hollmann based on work done by Petr Salinger
and Emmanuel Bouthenot for 0.6.X (http://bugs.debian.org/480572).
WPS IE parsing for PBC mode did not check whether the UUID-E attribute
was included before dereferencing the pointer. This could result in the
AP crashing when processing and invalid Probe Request frame.
Skip WPS IE building for Beacon and Probe Response frames is set_ie_cb()
is not set. This fixes a memory leak and optimizes operations by not
allocating memory and building the WPS IEs unnecessarily.
set_ap_wps_ie() is not used to set WPS IE for both Beacon and Probe
Response frames with a single call. In addition, struct wpabuf is used
instead of separate u8* and length fields. This avoids duplicated
allocation of the IEs and simplifies code in general.
This adds config_methods configuration option for wpa_supplicant
following the design used in hostapd. In addition, the string is
now parsed in common code from src/wps/wps_common.c and the list
of configurable methods include all the defined methods from
WPS 1.0h spec.
Since an Enrollee that does not advertise display as one of the
Config Methods is unlikely to be able to show the ASCII passphrase
to the user, prefer PSK format with such an Enrollee to reduce key
derivation time. This can help with some low-powered devices that
would take long time to derive the PSK from the passphrase.
The use_psk_key parameter can now be used to force the Registrar to
use PSK format instead of ASCII passphrase when building a Credential
for the Enrollee. For now, this is not enabled, but it could be enabled
either based on external (to WPS) configuration or automatically set
based on some WPS attribute values from the Enrollee.
Instead of forcefully deinitializing ER immediately, give it some
time to complete unsubscription and call eloop_terminate() only once
ER code has completed its work.
Instead of using the latest selected registrar change, collect selected
registrar information separately from all registrars and use the union
of this information when building the WPS IE for Beacon and Probe
Response frames.
Note: SetSelectedRegistrar UPnP action does not include a unique
identifier, so the ER matching routine is based only on the IP address
of the ER. In theory, there could be multiple ERs using the same IP
address (but different port or URL), so there may be some corner cases
that would not always match the correct ER entry at the AP. Anyway, this
is not really expected to occur in normal use cases and even if it did
happen, the selected registrar information is not any worse than it was
before when only the last change from any registrar for being
advertized.
This is more logical location for checking the URL and potentially
handling a call to another URL handler. In addition, return 404 error,
not invalid UPnP action, if the URL does not match.
