- "Remove Keys" renamed to "Unpair Device" and moved to a more
appropriate location (after the other pairing commands)
- "Device Unpaired" event added
- Address_Type parameters added the relevant commands and events
- Address_Type vs Key_Type distinction made clearer
- Bogus '0' removed from opcodes
For restoring the device from storage we need to have the Address type
of the device, the LTK is a good place for this.
In some cases, we may be notified of keys that were generated in the
Host, that key key would be used when the Host is the slave role in
a later connection, we should be able to differentiate this type of
key because it doesn't mean that we have a bonding with the Remote
Device.
- Remove the remote_name event and add the name to the device_connected
event (since we always refresh the name at that point anyway).
- Add Class of Device to device_connected since that's the only point
where we get it when a previously unknown device connects to us for the
first time.
- Add a Flags field to device_found to accommodate for legacy pairing
information (which we get from the remote host features HCI event) and
merge the only other existing boolean parameter (confirm_name) into this
Flags field.
Some changes were missing from the previous patch. This moves the fast
connectable command to the right place, adds a Class_Of_Device parameter
to Set UUID Caching (renamed from Set Service Cache) and adds a Class Of
Device Changed event.
This patch updates the mgmt API to match the current plans. This is
hopefully the last major change and because of that the command and
event codes are also reshuffled to match some kind of a logical
ordering.
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.
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).
