Since we do not currently support changing the AP settings received
from M7, there is no point in actually sending out the M8 that would
likely trigger the AP to reconfigure itself and potentially reboot.
For now, we just receive the AP settings in M7 and add a local network
configuration block based on those, but NACK the message. This makes
wps_reg work like wps_pin, but by using the AP PIN instead of a client
PIN.
When the supplicant is connected and performs a scan, it doesn't enter
WPA_SCANNING state for various reasons. However, external programs
still need to know that the supplicant is scanning since they may not
wish to perform certain operations during a scan (as those operations
will likely fail or yield incorrect results). Add a 'scanning' property
and signal to the supplicant dbus interface to allow clients to
synchronize better with the supplicant when it scans.
Signed-off-by: Dan Williams <dcbw@redhat.com>
hostapd_cli wps_pin command can now have an optional timeout
parameter that sets the PIN lifetime in seconds. This can be used
to reduce the likelihood of someone else using the PIN should an
active PIN be left in the Registrar.
I've exported the methods wpsPbc, wpsReg and wpsPin (patch attached),
so wpa_supplicant should be able to connect with WPS using the dbus
interface. I couldn't test it well because the problem seems to be in
my wireless card, a Broadcom BCM4328. At least it seems to do the same
using both interfaces. With ndiswrapper driver the "wpsie" entry
(thanks Dan!) didn't appear, and with the Broadcom wl driver it
appears but I cannot associate using WPS.
Add a new DBus method "setDebugParams" which takes the parameters
debug_level, debug_timestamp and show_keys as input and updates the
internal debug variables accordingly.
To change the debug level, enable/disable timestamps and enable/disable
show_keys the following dbus-send command can be used:
dbus-send --system --dest=fi.epitest.hostap.WPASupplicant --print-reply
/fi/epitest/hostap/WPASupplicant fi.epitest.hostap.WPASupplicant.setDebugParams
int32:0 boolean:false boolean:false
Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
When in AP mode, wpa_supplicant is now enabling WPS (only Internal
Registrar). wpa_cli wps_pbc and wps_pin commands can be used to initiate
WPS negotiation similarly to how this is done in station mode (though,
the BSSID parameter is ignored).
There is no point in trying to continue if a 4-way handshake frame is
discarded or if PTK/GTK/IGTK configuration fails. Force the client to
disconnect in such a case to avoid confusing user by claiming the
connection was successfully completed.
Use a parameter structure to pass in information that can be more easily
extended in the future. Include some of the parameters that were
previously read directly from hapd->conf in order to reduce need for
including hostapd/config.h into driver wrappers.
This merges the driver wrapper implementations to use the same
implementation both for hostapd and wpa_supplicant operations to avoid
code duplication.
This commit merges the driver_ops structures and implementations from
hostapd/driver*.[ch] into src/drivers. This is only an initial step and
there is room for number of cleanups to share code between the hostapd
and wpa_supplicant parts of the wrappers to avoid unnecessary source
code duplication.
Need to set WEP keys before requesting authentication in order to get
Shared Key authentication working. Previously, the WEP keys were not set
at all when using SME in wpa_supplicant.
IEEE 802.11r KDF uses key length in the derivation and as such, the PTK
length must be specified correctly. The previous version was deriving
using 512-bit PTK regardless of the negotiated cipher suite; this works
for TKIP, but not for CCMP. Update the code to use proper PTK length
based on the pairwise cipher.
This fixed PTK derivation for both IEEE 802.11r and IEEE 802.11w (when
using AKMP that specifies SHA-256-based key derivation). The fixed
version does not interoperate with the previous versions. [Bug 307]
Update credential to only include a single authentication and
encryption type in case the AP configuration includes more than one
option. Without this, the credential would be rejected if the AP was
configured to allow more than one authentication type.
A new network block parameter, scan_freq, can be used to specify subset
of frequencies to scan. This can speed up scanning process considerably
if it is known that only a small subset of channels is actually used in
the network. A union of configured frequencies for all enabled network
blocks is used in scan requests.
Currently, only driver_nl80211.c has support for this functionality.
For example, following parameter marks 2.4 GHz channels 1, 6, 11 to be
scanned: scan_freq=2412 2437 2462
wpa_supplicant can now initialize hostapd data structures when mode=2 is
used to set up an AP. The hostapd configuration is not yet set based on
wpa_supplicant network configuration block. In addition, the glue code
for hostapd driver_ops needs number of functions that will be needed for
AP functionality.
Move the shared IEEE 802.11w enum definition into src/common/defs.h to
avoid redefinition when both configuration structures are included into
the same file.
This version is adding the configuration option (mode=2) for this and
driver capability reporting to figure out whether AP mode can be used.
However, this does not actually implement any real functionality yet.
All these driver handlers can be implemented in associate() handler
which gets all the needed information in the parameters structure. The
old functions that provided only a single parameter will be removed
eventually to clean up the driver_ops structure, so driver wrappers
should start using the newer mechanism.
Removing just sun_family is not portable since some systems (e.g.,
FreeBSD) include an additional sun_len field. Using offsetof should be
portable. In addition, set sun_ken for FreeBSD.
This can be used, e.g., with mac80211-based Linux drivers with
nl80211. This allows over-the-air FT protocol to be used (IEEE
802.11r).
Since the nl80211 interface needed for this is very recent (added
today into wireless-testing.git), driver_nl80211.c has backwards
compatibility code that uses WEXT for association if the kernel does
not support the new commands. This compatibility code can be
disabled by defining NO_WEXT_COMPAT. That code will also be removed
at some point to clean up driver_nl80211.c.
This adds first part of FT resource request as part of Reassocition
Request frame (i.e., FT Protocol, not FT Resource Request Protocol).
wpa_supplicant can generate a test resource request when driver_test.c
is used with internal MLME code and hostapd can verify the FTIE MIC
properly with the included RIC Request.
The actual RIC Request IEs are not processed yet and hostapd does not
yet reply with RIC Response (nor would wpa_supplicant be able to
validate the FTIE MIC for a frame with RIC Response).
This is done with wired interfaces to fix IEEE 802.1X authentication
when the authenticator uses the group address (which should be happening
with wired Ethernet authentication).
This allows wpa_supplicant to complete wired authentication successfully
on Vista with a NDIS 6 driver, but the change is likely needed for
Windows XP, too.
Do not use just the driver name for this since driver_ndis.c supports
both wired and wireless NDIS drivers and needs to indicate the driver
type after initialization.
Calculate the estimated medium time using integer variables since there
is no real need to use floating point arithmetics here. In addition,
make sure there is no division by zero regardless of how invalid the
request from the station is. Reject invalid parameters and refuse
requests that would take most of the bandwidth by themselves.
Add test code into wpa_supplicant mlme.c to allow WMM-AC negotiation to
be tested with driver_test.
The new file wps_nfc.c and ndef.c implements NFC device independent
operation, wps_nfc_pn531.c implements NFC device dependent operation.
This patch is only for the following use case:
- Enrollee = wpa_supplicant
- Registrar = hostapd internal Registrar
Following NFC methods can be used:
- Enrollee PIN with NFC
- Registrar PIN with NFC
- unencrypted credential with NFC
Encrypted credentials are not supported.
Enrollee side operation:
Registrar side operation:
Example configuration.
CONFIG_WPS=y
CONFIG_WPS_NFC=y
CONFIG_WPS_NFC_PN531=y
I used NFC device "NXP PN531". The NFC device access method is
confidential, so I used outer library. Please download below files from
https://www.saice-wpsnfc.bz/index.php
[WPS NFC Library]
WpsNfcLibrary/WpsNfc.h
WpsNfcLibrary/WpsNfcType.h
WpsNfcLibrary/WpsNfcVersion.h
WpsNfcLibrary/linux/libnfc_mapping_pn53x.dll
WpsNfcLibrary/linux/wpsnfc.dll
[NFC Reader/Writer Kernel Driver]
NFCKernelDriver-1.0.3/linux/kobj/sonyrw.ko
<WiFi test>
The hostapd/wpa_supplicant with this patch passed below tests on
"Wi-Fi WPS Test Plan Version 1.6".
4.2.5 Add device using NFC Method with password token
(I used SONY STA instead of NXP STA.)
4.2.6 Add device using NFC Method with configuration token
5.1.9 Add to AP using NFC Method with password token
through internal registrar
(I used SONY AP instead of NXP AP.)
5.1.10 Add to AP using NFC Method with configuration token
through internal registrar
Many deployed APs do not handle negotiation of security parameters well
when both TKIP and CCMP (or both WPA and WPA2) are enabled. The most
common end result seems to be ending up with the least secure option..
As a workaround, check whether the AP advertises WPA2/CCMP in Beacon
frames and add those options for the credential if needed. This allows
the client to select the most secure configuration regardless of how
broken the AP's WPS implementation is as far as auth/encr type
negotiation is concerned.
The old behavior of generating new DH keys can be maintained for non-OOB
cases and only OOB (in this case, with UFD) will use the pre-configured
DH keys to allow the public key hash to be checked.
Not all embedded devices have USB interface and it is useful to be able
to remove unneeded functionality from the binary. In addition, the
current implementation has some UNIX specific calls in it which may make
it not compile cleanly on all target systems.
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.
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 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.
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).
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>
Build EAP-WSC dynamically does not make much sense and with the
dependencies to WPS code from number of places resolving this is not
trivial. It is simpler to just remove this option.
If you don't choose OpenSSL as TLS implementation and choose to enable
CONFIG_EAP_TNC you have to link against libdl. The OpenSSL libraries
implicitly link against them, so this might be a reason why it wasn't
noticed yet. I assume the same applies to hostapd.
We can now handle up to 65535 byte result buffer which is the maximum
due to WEXT using 16-bit length field. Previously, this was limited to
32768 bytes in practice even through we tried with 65536 and 131072
buffers which we just truncated into 0 in the 16-bit variable.
This more or less doubles the number of BSSes we can received from scan
results.
If wpa_supplicant is started with -u but the DBus service is already
registered wpa_supplicant will bail out. However, it will segfault
in wpa_supplicant_deinit because global->drv_priv wasn't allocated
yet.
Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
This is based on a patch from Pavel Roskin <proski@gnu.org>, but with
the WIRELESS_DEV part removed instead of moved since it does not apply
anymore. Additional note on client MLME limitations was also added.
MadWifi is unlikely to be in ../head relative to hostapd or
wpa_supplicant, as it would be inside the hostap git repository.
MadWifi sources are more likely to be in a directory called "madwifi"
and residing outside the hostap repository. Using "madwifi" also
demonstrates that the top-level madwifi directory is needed.
