These properties are already correctly treated as bytes for the local
device, we need to do same for peers.
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
A number of fixes/improvements here:
1) Remove casting of getter/setter function types which allows
us to change the prototypes in the future and not have hard-to-find
runtime segfaults
2) Instead of having the getters create a fake reply message which
then gets its arguments copied into the real reply message, and is
then disposed, just pass message iters around and have them add
their arguments to the message itself
3) For setters, just pass in the message iter positioned at the
start of the argument list, instead of each setter having to skip
over the standard interface+property name
4) Convert error handling to use DBusError and return the error
back down through the call stacks to the function that will
actually send the error back to the caller, instead of having a
fake DBusMessage of type DBUS_MESSAGE_TYPE_ERROR that then
needs to have the error extracted from it.
But most of all, this fixes various segfaults (like rh #725517
and #678625) which were caused by some functions deep down in the
getter callpaths wanting a source DBusMessage* when the getters were
used for two things: signals (which don't have a source DBusMessage)
and methods (which will have a source DBusMessage that's being
replied to). This duality made the code fragile when handling
errors like invalid IEs over the air.
Signed-off-by: Dan Williams <dcbw@redhat.com>
The paths pointer could have been NULL when going through the shared
freeing path in error case. Avoid the NULL pointer dereference by
checking whether that is the case. In addition, remove unnecessary
gotos to make the function more readable.
In general, this patch attemps to extend commit
00468b4650 with dbus support.
This can be used by dbus client to implement subject match text
entry with preset value probed from server. This preset value, if
user accepts it, is remembered and passed to subject_match config
for any future authentication.
Signed-off-by: Michael Chang <mchang@novell.com>
This is required for cross-compilation support on certain
platforms to avoid changing the pkg-config files themselves.
Signed-off-by: David James <davidjames@chromium.org>
Signed-off-by: Paul Stewart <pstew@chromium.org>
Some P2PDevice properties were not updated in p2p->cfg structure:
reg_class, channel, op_reg_class, and op_channel. Hence, update p2p->cfg
parameters through p2p core calls in wpas_p2p_update_config().
Signed-off-by: Jean-Michel.Bachot <jean-michelx.bachot@intel.com>
Signed-off-by: Jayant Sane <jayant.sane@intel.com>
Signal is triggered if an error occurs during WPS provisioning phase.
Signed-off-by: Jean-Michel.Bachot <jean-michelx.bachot@intel.com>
Signed-off-by: Jayant Sane <jayant.sane@intel.com>
Extend commit c2762e410f to allow
applications to manage (add/remove) persistent groups and accepted
network object paths while invoking a persistent group.
This can be used to activate the keep alive mechanism enabled in
mac80211. Allows to trigger Peer Disconnected signal if signal is lost
on a P2P peer.
Signed-off-by: Jean-Michel Bachot <jean-michelx.bachot@linux.intel.com>
Signed-off-by: Jayant Sane <jayant.sane@intel.com>
Move level parameter from p2p_device to p2p_device_info in order to
expose this information and modify D-Bus P2P handler to return this new
parameter through the P2P device properties.
Signed-off-by: Fabien Marotte <fabienx.marotte@intel.com>
Signed-off-by: Jayant Sane <jayant.sane@intel.com>
Do not emit network objects during P2P group formation since such
network objects can confuse certain apps. Instead, a persistent group
object is created to allow apps to keep track of persistent groups.
Persistent group objects only represent the info needed to recreate the
group.
Also fixes a minor bug in the handling of persistent group objects
during WPS operations.
Signed-off-by: Jayant Sane <jayant.sane@intel.com>
Append "P2P" to capability information if supported by device.
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: Jayant Sane <jayant.sane@intel.com>
Some new code we're working on will require the dbus type "aay" (an
array of arrays of bytes). To add this, refactor the array code to
reduce code duplication by given a type string to the array starting
code, and also add code to create and parse such arrays from or into an
array of struct wpabuf respectively.
Since there's no unique DBus type for this, add a "fake"
WPAS_DBUS_TYPE_BINARRAY type that is separate from the regular DBus
types for parsing.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Moved wpas_dbus_new_decompose_object_path from dbus_new_handlers.c
to dbus_new_helpers.c.
Signed-off-by: Fabien Marotte <fabienx.marotte@linux.intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The "debug_strings" private array in dbus_new_handles.c has fallen out
of sync with wpa_debug.h. Add the new "excessive" level to the head of
the list, realigning everything.
Signed-off-by: Paul Stewart <pstew@google.com>
Replace compile-time BSS cache expiration age and scan count by config
parameters that can be set via wpa_cli and the new D-Bus API. The latter
is done with interface properties BSSExpireAge and BSSExpireCount.
This adds a new command to the interface to remove all configured
netblocks. Without this it's necessary to query properties on the
interface and explicitly remove each netblock.
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).
This provides feature parity with the old-style D-Bus API. Explicit
properties to control global parameters is preferred but until that
happens this allows doing things like setting pkcs11_engine_path and
pkcs11_module_path via D-Bus.
There's a bug in the getter for the 'Interfaces' property
of /fi/w1/wpa_supplicant1 (new D-Bus interface) which causes a
'Segmentation Fault' when there are multiple interfaces.
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>
When the network was provisioned, we need to get the keys to be able to
reconnect without new provisioning. To be able to publish those keys but
not normally configured ones, add a new attribute to struct wpa_ssid
indicating whether or not keys may be exported.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The array's type should be given as the proper
DBUS_TYPE_STRING_AS_STRING, but evidently it
doesn't matter since it's all packed into a
variant type.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
This unref is guaranteed to be freeing a NULL pointer.
Tested manually: use dbus-send to send an invalid debug level parameter
Before change:
$ dbus-send --system --dest=fi.w1.wpa_supplicant1 --print-reply
/fi/w1/wpa_supplicant1 org.freedesktop.DBus.Properties.Set
string:fi.w1.wpa_supplicant1 string:DebugLevel variant:string:msgdumpf
Error org.freedesktop.DBus.Error.NoReply: Message did not receive a reply
(timeout by message bus)
(and then wpa_supplicant crashes)
After change:
$ dbus-send --system --dest=fi.w1.wpa_supplicant1 --print-reply
/fi/w1/wpa_supplicant1 org.freedesktop.DBus.Properties.Set
string:fi.w1.wpa_supplicant1 string:DebugLevel variant:string:msgdumpf
Error fi.w1.wpa_supplicant1.InvalidArgs: Did not receive correct message
arguments.
Signed-off-by: Paul Stewart <pstew@google.com>
The new DBus API helper function wpas_dbus_error_unknown_error
function can be called as a result of a failure within internal
getter calls, which will call this function with a NULL message
parameter. However, dbus_message_new_error looks very unkindly
(i.e, abort()) on a NULL message, so in this case, we should not
call it.
I've observed this course of events during a call to
wpas_dbus_getter_bss_wpa with a faileld parse of the IE parameter.
We got here through a call to fill_dict_with_properties which
explicitly calls getters with a NULL message parameter. Judging
from the way it is called, this could easily occur if an AP sends
out a malformed (or mis-received) probe response. I usually run
into this problem while driving through San Francisco, so I'm
exposed to any number of base stations along this path.
This patch changes wpa_supplicant policy for handling '' in SSIDs field of
Interface.SSID DBus message. It treats '' (zero-length) SSID as a request
for a broadcast scan, instead of ignoring it.
This patch updates DBus API .Scan() logic per the test cases listed below:
1) Interface.Scan({'Type':'active', 'Channel':(2412, 20)})
Request: Active scan with only '' SSID (1 channel)
Should be: 1 broadcast ProbeRequest on specified channel
Previous: 1 broadcast ProbeRequest on specified channel
This Patch: 1 broadcast ProbeRequest on specified channel
2) Interface.Scan({'Type':'active', 'Channel':(2412, 20), 'SSIDs':['']})
Request: Active scan with only '' SSID (1 channel)
Should be: 1 broadcast ProbeRequest on specified channel
Previous: No ProbeRequests; passive scan results for specified channel
This Patch: FIXED: 1 broadcast ProbeRequest on specified channel
3) Interface.Scan({'Type':'active', 'Channel':(2412, 20), 'SSIDs':['MySSID']})
Request: Active scan with only non-'' SSIDs (1 channel)
Should be: 1 directed ProbeRequest for each SSID on specified channel,
no broadcast ProbeRequest
Previous: 1 directed ProbeRequest for each SSID on specified channel,
no broadcast ProbeRequest
This Patch: 1 directed ProbeRequest for each SSID on specified channel,
no broadcast ProbeRequest
4) Interface.Scan({'Type':'active', 'Channel':(2412, 20), 'SSIDs':['',
'MySSID']})
Request: Active scan with SSIDs, including 1 '' SSID (1 channel)
Should be: 1 broadcast ProbeRequest, 1 directed ProbeRequest for each
non-'' SSID on specified channel
Previous: 1 directed ProbeRequest for each non-'' SSID on specified
channel
This Patch: FIXED: 1 broadcast ProbeRequest, 1 directed ProbeRequest for
each non-'' SSID on specified channel
Currently the DBus Interface.Scan API is counter-intuitive. It issues
ProbeRequests when doing passive scans when channels are specified, and
does not issue ProbeRequests for broadcast active scans.
This patch updates DBus API .Scan() logic per the test cases listed below:
1) Interface.Scan({'Type':'passive'})
Request: Passive scan (all channels)
Should be: No ProbeRequests; Passive Scan results for all channels
Previous: 1 ProbeRequest on all channels for both broadcast SSID and
selected network (scan_ssid=1)
This Patch: --No change--: 1 ProbeRequest on all channels for both
broadcast SSID and selected network (scan_ssid=1)
2) Interface.Scan({'Type':'passive', 'Channel':(2412, 20)})
Request: Passive scan (1 channel)
Should be: No ProbeRequests; Passive Scan results for 1 channel
(plus overlapping channels)
Previous: 1 broadcast ProbeRequest on specified channel
This Patch: --Fixed--: No ProbeRequests; Passive Scan results for 1
channel (plus overlapping channels)
3) Interface.Scan({'Type':'active'})
Request: Active scan with no SSIDs (all channels)
Should be: 1 broadcast ProbeRequest on all channels
Previous: No ProbeRequests; passive scan results for all channels
This Patch: --Fixed--: 1 broadcast ProbeRequest on all channels
4) Interface.Scan({'Type':'active', 'Channel':(2412, 20)})
Request: Active scan with no SSIDs (1 channel)
Should be: 1 broadcast ProbeRequest on specified channel
Previous: No ProbeRequests; Passive scan results for specified
channel (plus overlapping channels)
This Patch: --Fixed--: 1 broadcast ProbeRequest on specified channel
