This avoids potential use of uninitialized stack memory when printing
out peer address based on SMK error message that does not include the
MAC address.
wpa_sm_step() could theoretically free the statemachine, but it does
not do it in this particular case. Anyway, the code can be cleaned to
verify whether the state machine data is still available after the
wpa_sm_step() call.
On FreeBSD 8.0, driver_bsd.c build fails because of changes from
older versions of FreeBSD. The error messages are below:
In file included from ../src/drivers/driver_bsd.c:38:
/usr/include/net80211/ieee80211_crypto.h:94: error: 'IEEE80211_TID_SIZE'
undeclared here (not in a function)
../src/drivers/driver_bsd.c: In function 'wpa_driver_bsd_set_wpa_ie':
../src/drivers/driver_bsd.c:968: error: 'IEEE80211_IOC_OPTIE' undeclared (first
use in this function)
../src/drivers/driver_bsd.c:968: error: (Each undeclared identifier is reported
only once
../src/drivers/driver_bsd.c:968: error: for each function it appears in.)
gmake: *** [../src/drivers/driver_bsd.o] Error 1
This patch solves this issue.
wmm_ac_??_cw{min,max} parameters are in log form
When the wme_ac_??_cw{min,max} parameters aren't specified in
hostapd.conf, hostapd uses an incorrect set of default values, as the
defaults are in 2^x-1 form instead of in log form. This patch changes
them over to the expected log form.
There was an extra semicolon that broke the calculation of registered
properties and resulted in obj_desc->prop_changed_flags not being
allocated long enough for all the flags.
The path pointer used as the timeout_ctx was not constant; the path
string itself may have been the same, but the pointer certainly was not
since it was sometimes from stack and sometimes from the dynamically
allocated buffer in obj_desc. This caused some of the eloop timeout
cancellations not to find the timeout. Fix this by using the obj_desc
as the timeout context data.
Instead of sending PropertiesChanged signals for each changed
property separately, mark properties as changed and send aggregated
PropertiesChanged signals for each interface in each object.
Aggregated PropertiesChanged signal is sent
- for all object after responding on DBus call
- for specified object after manual call to
wpa_dbus_flush_object_changed_properties() function
- for each object separately after short timeout (currently 5 ms)
which starts when first property in object is marked changed
The actual supplicant state is exposed via a property on the interface
object. So having a separate signal StateChanged for notifying about
changes is a bad idea. The standard PropertiesChanged signal should be
used for this.
The advantage of StateChanged signal was that it includes the previous
state, but not even NetworkManager is making use of this. And tracking
the old state via the property and this signal is easily possible anyway.
Instead of using some magic integer values that really only mean
something to WPA internal code, just use simple strings. Possible
values are "msgdump", "debug", "info", "warning" and "error" which
map directly to WPA debugging support.
Number of Linux driver wrappers included this more or less identical
function, so lets add a new helper file to be able to share some more
code between the driver wrappers.
The three existing enums were already depending on using the same
values in couple of places and it is just simpler to standardize on
one of these to avoid need for mapping between different enums for
the exact same thing.
Most of this file was already moved into wpa_supplicant/scan.c and
we can remove the file completely by having couple of small helper
functions copied to the remaining users outside core wpa_supplicant
code.
This fits better in wpa_supplicant/scan.c. Couple of remaining
scan_helpers.c functions are currently used in driver wrappers,
but they can likely be removed in the future.
This adds new commands and events for allowing off-channel Action
frame exchanges to be requested. This functionality is not yet used
and is only fully supported by driver_test.c at this point.
driver_nl80211.c has support for the remain-on-channel commands, but
the Action frame TX/RX part is still pending review for the kernel
code and as such, is not yet included here.
