Commit b06899eace introduced a new API for
device_get_address but apparently missed fixing the call in
plugins/wiimote.c. This patch converts the plugin to use the new API.
GATT servers should register their attributes on each adapter when it is
plugged instead of doing that when the plugins is loaded. This patch
registers a new adapter driver to manage plug and unplug events in order
to register attributes in each GATT served managed in each adapter.
Due to the way legacy name resolving is handled for the mgmt interface
the entire logic that was previously part of the core daemon needs to be
moved into hciops. Essentially hciops now contains what the mgmt code
in the kernel will do when mgmtops is used.
This is important especially in the future when dual-mode devices can be
connected to over LE. It's also important if/when we decide to move the
advertisement cache into user-space.
Sometimes after e.g, suspend we miss some initialization commands from
the kernel, even though we had a workaround for this it doesn't really
work as expected since the adapter must be up in order to resend.
To fix this problem the resend logic is moved after DEVUP.
Inform the adapter that the system has been unlocked when the MCE
sends the tklock_mode_ind signal. This signal will trigger the
automatic re-connections for the devices selected by the profiles.
Profiles register ATTIO callbacks to indicate that ATT connection
is required.
We need support for attaching a client connection to the attribute
server because the server that we are connected may want to do
something similar to a reverse service discovery, and we need to be
able to receive indications and notifications.
If we pass an invalid xml to sdp_xml_parse_record(), then it returns
NULL. Further we are passing the this NULL pointer to the
sdp_record_free(), which leads to invalid memory access.
This patch fixes wrong adapter state when using Management interface.
When bluetoothd starts, the adapter should be switched to the state
informed by Maemo6 MCE. In the current implementation, Maemo6 plugin
sends set powered command when the adapter is still powering up, the
last command sent fails(kernel returns EALREADY).
When management interface is enabled, name changed event comes when the
adapter is initialized as consequence of the Read Local Name. Use the
same function to set and handle event causes looping when bluetoothd
starts if the name stored in the controller is different from the name
provided by the adapter name plugin.
Splitting the adapter_update_local_name also fix the PropertyChanged
(for Name) signal being sent before AdapterAdded.
Add support for mgmt interface events for device blocking/unblocking.
Kernel sends a mgmt event when a device has been blocked by another
management socket or with ioctl command (e.g. by hciconfig).
Parameter update_only is added to device_block/unblock functions in
device.c to avoid code copying. When update_only is true, blocking
command is not sent to kernel, but only device status is updated and
dbus signal is sent.
Indexing of chassis_map array has to be done like that:
chassis_map[chassis_type * 2 - 1]
because if not, everything is shifted by one. When (e.g.) chassis_type
is 0x04 result should be "Low Profile Desktop" => "desktop" (not a
"Pizza Box" => "server"). Lets see the 2.6.1 document on:
http://www.dmtf.org/standards/smbios
Local extended features bitmask may change when Write LE Host Supported
Command is sent by the kernel. This patch adds reading of the local
extended features in the initialization sending a HCI command, extend
the ioctl HCIGETDEVINFO is not suitable due possible inconsistency
between kernel and userspace.
Deprecated configure option after adding "enable_le" parameter in the
bluetooth module. Write LE Host Supported Command is now sent by the
kernel if "enable_le" is enabled and the controller supports LE.
This sometimes cause bluetoothd to burn cpu when an adapter is removed
from the system.
Since the watch is not really bond to any adapter, in fact it is added on
plugin .init, its removal is now moved to plugin .exit.
The Nintendo Wii Remote requires binary bluetooth addresses as PINs.
This is not possible via dbus agent API. So this adds a plugin that
registers a pin-callback and forces the right pin for every
authentication request of wiimotes.
Replacing the name setting code in src/adapter.c.
Moving the adapter naming allows us to use the /etc/machine-info [1]
pretty hostname, as implemented by hostnamed [2] in systemd.
If /etc/machine-info is not present, the adapter name stored
on disk in /var/lib/bluetooth will be used. If no adapter name
has been set yet, the default from the main.conf will be used.
We don't currently number the name of hci0 if a pretty name is
available, but we should instead number it if it happens not
to be the default adapter. As we cannot be told when the default
adapter changes, we'll behave this way for now.
Note that when an adapter name is set automatically from
the pretty hostname, changing it through the D-Bus interface
will fail.
[1]: http://0pointer.de/public/systemd-man/machine-info.html
[2]: http://www.freedesktop.org/wiki/Software/systemd/hostnamed
Use secure pin code parameter received from the kernel in
MGMT_EV_PIN_CODE_REQUEST event and propagate this to agent
code.
Secure flag is specific for the pin code request only.
The functions eir_parse() and adapter_update_found_devices() now
assume that the EIR buffer has always 240 octets. For advertising
reports, the advertising data is stored on a buffer with 240 bytes,
padded with zeroes.
The discovery procedure is implemented in discovery callbacks
(start_discovery and stop_discovery). We don't need inquiry and
scanning specifics callbacks in btd_adapter_ops anymore.
This patch implements a new state machine for struct btd_adapter.
The adapter_set_state() function was completely rewritten since its
logic does not apply anymore. The whole logic of interleaved discovery
procedure before implemented in adapter_set_state() should be
implemented at hciops and mgmtops layers.
At the adapter layer, it is not important to track what is the current
state (inquiring or scanning) during the discovery session. All the
adapter layer cares about is if it is performing the discovery or not.
Therefore, the adapter states STATE_STDINQ, STATE_PINQ and
STATE_LE_SCAN were replaced by a new state called STATE_DISCOV.
Additionally, because there is no point in implementing states
as a bitmask, all adapter states were implemented using integers
instead of a bitmask.
This patch adds a timeout parameter to start_scanning callback in
btd_adapter. The parameter should be used to stop scanning after
'timeout' milliseconds.
Periodic Inquiry is no longer supported in hciops since the discovery
procedure will use Standard Inquiry only.
External tools which request Periodic Inquiry will not change the
adapter's state.
We need to track the current discovering state (HALTED, INQUIRY or SCAN)
of the adapter in hciops layer during the discovery procedure. This will
help us to properly update the state of btd_adapter and emit the property
"Discovering" correctly.
This patch adds start_discovery and stop_discovery callbacks to
struct btd_adapter_ops. These callbacks are responsible for starting
and stoping the discovery procedure. It also creates dummy functions
in hciops and mgmtops which implements those callbacks.
Instead of having static handles, use attrib_db_find_avail() to find
available handle ranges.
Also split the big register_attributes() into one function per service.
This patch changes type of the "pending" variable to uint32_t. A pointer
to this variable is passed to the hci_clear_bit function as void * and
then cast to uint32_t * again.
Previously the unsigned long type could cause some unexpected behavior
due to violating strict aliasing rules. This patch fixes this problem by
making sure that the same integer type is used in all places.
This solution is simpler than the other option of changing the types of
all other places (from uint32_t to unsigned long, including changing
type for casting in hci_*_bit function family). Also, not all places can
be changed, like the hci_dev_info struct, since it would violate
compatibility rules between the kernel and user space.
With some kernels and the right timing it is possible to get into the
state where we get the local name but haven't yet gotten a DEVUP event.
In such a case it is *not* ok to call init_adapter.
This patch adds a new set_local_name command as well as a
local_name_changed event to the management interface. Instead of 248
bytes (like in the HCI spec) 249 bytes are always reserved for the name
in the messages so that there's a guarantee of it being nul-terminated
(this is not guaranteed on the HCI level).
The maemo6 MCE plugin should be used with the flag InitiallyPowered
in main.conf set to 'true' so that BlueZ powers on the adapter
and leaves it in that state when the daemon is started. The plugin
will read the radio state from the MCE and set the state
accordingly. The maemo6 plugin is a btd_adapter_driver and those
drivers are loaded after BlueZ has read the BD address etc from the
adapter.
This patch adds a boolean flag in the callback to ignore the initial
powering on of the adapter by BlueZ, since it shouldn't be
propagated to the MCE. With InitiallyPowered set to 'false' the
adapter_powered callback is not called when the adapter is turned
on at BlueZ startup, which is why this wasn't implemented before.
In the current implementation of le_advertising_report(), the variable
'info' has an invalid memory address after the 'for' loop. If 'info'
is dereferenced it will access invalid memory.
This patch fixes this potential bug and improves the code's readability.
In some (rare) circumstances it is possible for the mgmt_pair_device
command to complete without there being any other indication of
completion of the procedure. Therefore, the bonding_complete event needs
to be notified to the core daemon also in this situation.
There's no need to expose the auto-accept case to the core daemon so
move it to hciops. For the management interface this will all be handled
on the kernel side.
There is no need for HCIDEVUP/fork in such cases it will just consume
more resources for no reason.
To fix this HCI_DEV_REG is no longer generate for adapter already up
instead init_device is called directly which simplify the code path.
The kernel seems to have some state tracking issues if we close the
bonding socket before it gets into connected state. This needs to be
investigated on the kernel side but a simple fix is to let the socket be
closed in its BtIO callback instead of through some HCI event (for the
successful case).
This patch refactors the pairing code in hciops and the core daemon to
better match the management interface. Particularly all logic regarding
IO capabilities and authentication requirements are moved into hciops.c.
The patch is quite big because there are a lot of cross-dependencies
which makes it difficult to split the changes up into smaller chunks.
The important adapter_ops preparations for the management interface in
this patch are the create_bonding and cancel_bonding callbacks. Those
will be directly mapped to corresponding management commands.
Remove sending of the scan disable command when the device is being
powered off. This was originally a safe-guard for the non-connectable
GAP test case in case the HCI driver leaves the controller powered after
the DEV_DOWN ioctl, but now-days it can be expected that drivers behave
properly.
When handling HCI_DEV_REG event it should not be necessary to generate a
HCI_DEV_UP since init_known_adapters already does it in case the adapter
is already up.
There's no point to export connection handle details to the core daemon
since it will not be available in the management interface. Instead
track the handles inside hciops (managment interface will do this inside
the kernel).
The value 0 is not allowed by the HCI spec so it can be used to denote
"not applicable" or "unknown". Also, the management interface will use
an unsigned integer for the PIN length so mirroring that in the core
daemon code makes sense. This patch also takes care of handling
previously stored -1 values and converts them to 0 whenever they are
detected.
This patch updates the class of device handling code to match the latest
management interface. A notable feature is that UUID to service class
mapping policy remains in user space with the help of the svc_hint
parameter of the add_uuid command. This is to make it easy to update the
mapping table when new profiles come along.
One 1.2 Broadcom adapter doesn't respond to the event mask HCI command
at all unless the second byte of the mask is 0xff. Strictly speaking
this is an invalid value because bits 0x02 and 0x04 are reserved.
However, no other adapters seem to mind and using 0xff instead of 0xf9
makes this particular adapter work properly.
Controllers based on the core spec 1.1 support the event mask HCI
command but need a very stripped down default value for the mask. This
patch makes sure the command gets issued for 1.1 controllers with the
appropriate value.
This patch adds support for the add_uuid and remove_uuid management
commands. The kernel uses them to track the list of UUIDs and
automatically set the service class bits as well as the EIR value
accordingly.
This patch implements support for the set_pairable managment command.
Due to the async nature of it a new btd_adapter_pairable_changed
function is added to the core daemon.
The management interface will have simple add_uuid and remove_uuid
methods so it makes sense to have the adapter_ops interface reflect
that. This patch removes the services_updated callback and replaces it
with add_uuid and remove_uuid callbacks.
The events, commands and responses to these modes are represented by
identical management messages. By having a unified struct for all of
them quite a lot of code can simplified and reused.
The current idea is to have a single set_powered management command
which for the switching on case would leave the controller in a
non-connectable, non-pairable and non-discoverable state.
Because we need to know the device type (LE, Basic Rate or Dual Mode)
to be able to fully restore the device from storage, we have to store
and load this information to permanent storage.
Note: due to "device_type_t" usage in storage.h, some header includes
needed to be reordered in files which include storage.h.
There's no need for the core daemon to have special handling for debug
keys anymore as long as it tells adapter_ops if they are enabled or not
(new parameter added to adapter_ops->load_keys).
In most cases it's more convenient to use the adapter index when looking
up the adapter object since the index is always available in the
adapter_ops callbacks.
The management interface will enable storing link keys in runtime memory
in the kernel. This patch makes the adapter interface match this model
and adds storing of link keys into hciops.
This (rather big) patch refactors the way that adapters are initialized
and powered on/off. The purpose is to align the adapter_ops <-> core
daemon interface with how the management interface will behave.
The global link policy should remain unchanged even if an adapter
doesn't happen to support some features. These features should only be
disabled for that specific adapter.
By default all features are enabled (RSWITCH, HOLD, PARK, SNIFF).
When "read local supported features" complete event occurs, not supported
features are disabled and then "Write default link policy" command with
supported features is sent.
On behalf of ST-Ericsson SA
The management interface will move class of device and extended inquiry
response handling to the kernel side so the same functionality needs to
be moved into hciops. These features are quite tightly coupled in
bluetoothd so splitting this into multiple patches would have been hard
(if not impossible). Thus this quite large single commit.
The read_mode and read_info commands are issued only once in the
beginning for each adapter so it doesn't make sense to have the
information fetching split across two different commands. Instead all
necessary info can be fetched through the read_info command.
DBus error handling in BlueZ is a mess. This is the first patch to unify
all DBus error handling like in ConnMan and oFono. This unifies all
.InvalidArguments errors.
In addition to blocking the mainloop hci_send_req changes the socket
filters which makes it unusable for the per-adapter HCI socket in
hciops.c. Using hci_send_cmd makes much more sense here.
Due to a possible kernel bug, sometimes the very first HCI commands that
the kernel sends might go unnoticed. Therefore check for this when one
of the last commands (read_local_name) that the kernel sends completes.
hciops_encrypt_link() was not working because it interfered with the
event filters of the hciops internal socket. Instead a separate socket
opened with hci_open_dev() needs to be used.
Implement adapter_update_adv() function to parse advertising data
received by btd_event_adv() function. Add some fields for advertising
data in remote_device_info struct.
Since the only thing the code does upon a write_ssp_mode_complete event
is issue a read_ssp_mode command it makes sense to have this internal to
hciops.
Several adapter initialization features will be handled by the new
management interface in the future, so move these from adapter.c into
hciops. This also gets rid of a couple of unnecessary adapter_ops
callbacks.
The kernel sends several HCI commands when initializing an adapter and
several of them are important for the current adapter_start function. So
far only the local address was waited for, but it also makes sense to
wait for local version and features. This patch adds a bitmask to track
the completed commands and only informs adapter.c about readyness when
all commands have been completed.
Command complete event for LE commands are not being handled properly
due blocking calls of LE Set Scan Parameters and LE Set Scan Enable
Commands. Fix wrong Discovering signal emission in the interleaved
discovery mode.
Adapters which are already up when bluetoothd starts will already have
their bdaddr's known and bluetoothd should therefore not wait for a
read_bd_addr_complete event before assuming that they're ready for use.
We might not have the adapter address when we get HCI_DEV_UP so it's not
safe to cache it and let the core daemon know about the adapter being
ready for use. This patch adds tracking of the read_bd_addr command and
only informs the core daemon about the adapter when the command has been
completed. Additional tracking of the UP/DOWN state is also added since
in theory HCI events can come before DEV_UP (since HCI data and stack
internal events are handled using separate kernel threads).
If the state variable is not updated until mce_signal_callback and
SetProperty(Powered) is called two times quickly, then the second
call will not generate a request to change the radio state of the
MCE if its corresponding call to adapter_powered occurs before the
first triggering of mce_signal_callback.
With this patch two calls to the MCE are executed, although there
might still be an unnecessary power cycle in that
mce_signal_callback is also triggered twice.
In the future when the mgmtops code needs to behave in different ways
depending on the kernel side management API version it's convenient to
have the exact version/revision number in easily accessible global
variables inside mgmtops.c.
