Reduce startWhen from 3 to 1 second if WPS is included in the build.
While this is done regardless of runtime WPS configuration, it is fine
to use a smaller value here in general. This cuts two seconds out from
WPS negotiation if the driver does not support addition of WPS IE into
the (Re)Association Request frame.
Need to set WLAN_STA_WPS and WLAN_STA_MAYBE_WPS flags even if WPA is not
enabled. This allows open and static WEP modes to initiate WPS
negotiation with madwifi-like drivers.
Previously, both CONFIG_IEEE80211W=y and CONFIG_IEEE80211R=y were needed
to enable SHA256-based key handshake (WPA-PSK-SHA256 and
WPA-EAP-SHA256). This can now be done with just CONFIG_IEEE80211W=y.
This uses similar, but not identical, interface to madwifi. It is easier
to keep this separate to avoid conflicts with potential changes in the
driver interfaces.
It seems that WFA WPS spec says that default key index should be 1 (not
0). I think this meas that WEP key indexes region is not from 0 to 3,
but from 1 to 4 in WPS. At least WRT610N implemented it this way.
These flags are used to mark which values (level, noise, qual) are
invalid (not available from the driver) and whether level is using dBm.
D-Bus interface will now only report the values that were available.
TX/RX bytes are now reported correctly (typo ended up leaving TX bytes
uninitialized and set RX bytes value to use correct TX bytes). TX/RX
packet counts are not yet available from kernel, so we have to clear the
values to avoid reporting bogus data.
If session resumption fails for any reason, do not try it again because
that is just likely to fail. Instead, drop back to using full
authentication which may work. This is a workaround for servers that do
not like session resumption, but do not know how to fall back to full
authentication properly.
This fixes an issue where two AKA'/Challenge messages are received when
resynchronizing SEQ#. Previously, this used to trigger an authentication
failure since the second Challenge message did not duplicate AT_KDF.
If the driver reports support for more than one SSID per scan request,
optimize scan_ssid=1 operations in ap_scan=1 mode. This speeds up
scanning whenever scan_ssid=1 is used since the broadcast SSID can be
included in every scan request and if driver supports more than two
SSIDs in the scan request, the benefits are even larger when multiple
networks have been configured with ap_scan=1.
This is also cleaning up wpa_supplicant_scan() function by moving code
around so that the SSID list is not processed unnecessarily if the
operation mode does not need this.
This does not actually send out separate scan requests for each SSID,
but the debug output can be used to test scan2() functionality with
multiple SSIDs.
This can be used to provide support for scanning multiple SSIDs at a
time to optimize scan_ssid=1 operations. In addition, Probe Request IEs
will be available to scan2() (e.g., for WPS PBC scanning).
For example, -Dnl80211,wext could be used to automatically select
between nl80211 and wext. The first driver wrapper that is able to
initialize the interface will be used.
This workaround was needed with some drivers that used WEXT, but there
is no known nl80211-enabled driver that would need this, so lets get rid
of the extra delay.
The driver wrappers can now inform wpa_supplicant how many SSIDs can
be used in a single scan request (i.e., send multiple Probe Requests
per channel). This value is not yet used, but it can eventually be used
to allow a new scan command to specify multiple SSIDs to speed up
scan_ssid=1 operations. In addition, a warning could be printed if
scan_ssid=1 is used with a driver that does not support it
(max_scan_ssids=0).
Split the auth=none option into three: open, WEP, WEP with shared key to
allow the user specify WEP with shared key authentication. In addition,
fix static WEP key edits to be enabled only when using static WEP keys
(i.e., not for IEEE 802.1X).
Some drivers (for example ipw2100) do not report signal level but only
signal quality. wpa_supplicant already uses the signal quality if no
level is reported and all other comparision parameters are equal to sort
the scan results. However, if two APs have different max rates and the
signal level does not differ much wpa_supplicant chooses the AP with the
higher max rate.
In case of ipw2100 no signal level is reported and thus wpa_supplicant
always takes the AP with higher max rate even if its signal quality is
really low. For example if AP1 (max rate 11Mb/s, 80% signal quality) and
AP2 (max rate 54 Mb/s, 20% signal quality) are found by a scan
wpa_supplicant would choose AP2.
Hence, if no signal level is reported depend on the signal quality if
max rate should be compared. A quality difference of 10% is considered
acceptable in favor of the higher max rate.
Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
Really disassociate when tearing stuff down; drivers may sometimes
(legally) keep trying to reassociate unless the BSSID is unlocked. If
the SSID is unlocked too, under WEXT drivers are able to pick an SSID to
associate, so kill that behavior by setting a bogus SSID. Unfortunately
WEXT doesn't provide an easy method to say "stop whatever doing and just
idle".
Signed-off-by: Dan Williams <dcbw@redhat.com>
On WPS init/deinit process, the hostapd clears it's own WPS IE
with 0 length WPS IE. But it fails. Because the parameter to
ioctl is too short. Then hostapd prints a below message.
ioctl[IEEE80211_IOCTL_SET_APPIEBUF]: Invalid argument
It looks like GnuTLS (at least newer versions) is using random padding
on the application data and the previously used 100 byte extra buffer
for tls_connection_encrypt() calls was not enough to handle all cases.
This resulted in semi-random authentication failures with EAP-PEAP and
EAP-TTLS during Phase 2.
Increase the extra space for encryption from 100 to 300 bytes and add an
error message into tls_gnutls.c to make it easier to notice this issue
should it ever show up again even with the larger buffer.
I tried PBC with the hostapd registrar.
I pushed the button with "hostap_cli WPS_PBC".
But hostapd registrar always sends Selected Registrar Config Methods
attribute=0x0000 in beacon/probe response.
wpa_supplicant should not send a dbus reply as response to a method call
if no reply was requested by the caller. Sending a reply even if not
requested is basically no problem but triggers dbus warnings like the
one below.
Feb 9 07:31:23 linux-gvjr dbus-daemon: Rejected send message, 2 matched
rules; type="error", sender=":1.129" (uid=0 pid=30228
comm="/usr/sbin/wpa_supplicant -c /etc/wpa_supplicant/wp")
interface="(unset)" member="(unset)" error
name="fi.epitest.hostap.WPASupplicant.InvalidInterface"
requested_reply=0 destination=":1.128" (uid=0 pid=30226
comm="/usr/sbin/NetworkManager "))
Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
