Add an "Interface.FlushBSS" method to the new D-Bus API and a "flush"
method to the old API. Both take an age parameter that is a threshold
(in seconds) for selecting entries to evict. Setting this parameter
to zero flushes all entries from the cache.
This mechanism is useful for a connection manager to clear state at
startup and on resume (where the age parameter may be used to hold
onto recent/valid data).
Chooses between EAP and non-EAP authentication modes and
uses the appropriate method to retrieve the name.
Signed-off-by: Paul Stewart <pstew@google.com>
This avoids an invalid D-Bus call during interface initialization.
The wpa_state change can happen before the D-Bus interface is set up,
so we must be preparted to handle this early event signal. In theory,
it should be possible to reorder initialization code to make sure
D-Bus signals are ready, but that would likely require quite a bit of
code restructuring, so it looks like a safer option for now is to just
skip the early event.
Expose RSN and WPA properties for BSS objects containing information
about key management and cipher suites. Get rid of WPA/RSN/WPSIE
byte array properties and add IEs byte array property with all IE data
instead.
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.
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.
There is no need to duplicate the method/signal/property arrays that
were registered for objects. The registration was using static arrays
on methods/signals/properties in all places and we can as well use
those throughout without having to allocate memory and copy all the
entries for every object. This reduces number of allocations and
amount of unnecessary code quite a bit.
The perror() calls do not make much sense with libdbus functions and
wpa_printf() would really be used for all error printing anyway. In
addition, many of the error messages on out-of-memory cases are not
really of much use, so they were removed. This is also cleaning up
some of the error path handling to avoid duplicated code.
These cannot be NULL, so there is no point in checking for that. In
addition, the accessor function for this is just making the code harder
to understand.
This callback structure was specific to the new D-Bus API which makes
it more or less pointless. It is just simpler to call the notification
functions directly. More proper design could be to use a generic
mechanism for registering notification callbacks into notify.c, but
that is not yet available and should not be designed just based on a
single user.
In addition, remove Quality and Noise properties since the BSS table
is not the correct place for fetching per-channel information (Noise)
and Quality is not well-defined (nor available from many drivers).
We don't actually need to define separate user_data argument for
each method handler and property getter/setter. Instead, we can define
one argument for the whole object. That will make it easier to register
objects like BSS or Networks which require allocating and freeing
memory for their arguments.
This was mostly identical code that had been copied for the new D-Bus
API implementation and as such, should really have been shared from
the beginning. In addition, the copied code ended up generating
interesting stack traces since the actual D-Bus connection was being
shared even though the pointer to it was stored in two distinct
data structures. The old D-Bus code ended up dispatching some
D-Bus callbacks which ended up running the new D-Bus code.
Since the private context pointers were mostly identical, everything
seemed to more or less work, but this design was just making things
more complex and potentially very easy to break.
Do not try to unregister BSS objects twice (the latter one with invalid
path) and make sure all network objects get added and removed properly
(the ones read from configuration file were not being registered, but
were tried to be unregistered).
Replace the scan results -based implementation with the use of information
from the new BSS table maintained by wpa_supplicant to get a more stable
source of BSS data. Change the use of BSSID as the key for the BSS object
to use the BSS table unique identifier so that multi-SSID APs can be
handled properly.
The D-Bus interface does not really have anything to do with the
wpa_supplicant ctrl_iface interface and as such, this prefix in
dbus files is both confusing and unnecessarily. Make the file names
shorter by removing this prefix.
Sam Leffler