Instead of having all driver stuff collected across wpa_supplicant
and hostapd, create a common snippet that they both include and
that handles the build configuration.
Change existing CONFIG_LIBNL20 compatibility code in
driver_nl80211.c to be used by both wpa_supplicant
and hostapd, but take care of nl_handle too now.
Propagate CONFIG_LIBNL20 out of .config file and onto
CFLAGS in the Makefile.
Use libnl-gen now too.
Signed-off-by: Jon Loeliger <jdl@bigfootnetworks.com>
---
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.
