open()/read() is more common on BlueZ code. Incidentally, get rid of
this compilation error (using gcc 4.6.3):
plugins/autopair.c: In function ‘autopair_init’:
plugins/autopair.c:154:8: error: ignoring return value of ‘fread’,
declared with attribute warn_unused_result [-Werror=unused-result]
This patch makes the autopair plugin try a fixed "0000" pincode for
keyboards that reject the pincode too fast (less than 500ms). This too
short delay rejecting the pincode means that the user didn't have time
to type the random pincode in the bluetooth keyboard and was the
keyboard who actually rejected it.
The autopair plugin tries standard pincodes for different devices with
dumb pincodes. It also generates a random 6 digit pincode for keyboards
that support any pincode but fallbacks to the agent call in case the
random generated pincode didn't work.
The plugin's pin code callback doesn't know about the pairing process.
It just provides a pin code based on the information provided to this
function. Although limited state could be added through other new
callbacks, this fix achieves this by providing more information to the
callback itself. The new argument "attempt" states the pin callback
attempt of the particular plugin for the current pairing of the device.
This allows a plugin to try different pincodes for the same device in
the same pairing process.
To signal that the plugin doesn't provide any pin code for the provided
device the current implementation returns 0 (an empty pin code).
Analogously, with this fix, a plugin should return 0 when it doesn't
have any other pin code to provide for the given device.
Message might not contain State field and CPS needs to be set to
unknown before processing message from neard. This fix processing
RequestOOB called without parameters.
Devices with private addresses cannot persistently be identified by
their address. Therefore it doesn't make sense to store any information
about them as the information couldn't be looked up later once the
remote address has changed.
Once the kernel receives support for private address resolution we'll
start getting the public address of such devices to user space. However,
until then we just have to ignore such devices from a storage
perspective.
If pretty hostname is not set fallback to static hostname (if it is
set). If static or pretty hostname is not set appropriate properties
are empty strings not NULLs. This behaviour is recomended by hostnamed.
This refactor code for message processing for future feature addition.
nokia.com:bt and EIR processing is now separated from performing
actions based on received data.
Message reference was not dropped in register_agent. This fix following
memory leak reported by valgrind:
454 (184 direct, 270 indirect) bytes in 1 blocks are definitely lost in loss record 207 of 220
at 0x4C29DB4: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
by 0x513DCF2: ??? (in /lib/x86_64-linux-gnu/libdbus-1.so.3.5.8)
by 0x514222E: ??? (in /lib/x86_64-linux-gnu/libdbus-1.so.3.5.8)
by 0x5149F46: ??? (in /lib/x86_64-linux-gnu/libdbus-1.so.3.5.8)
by 0x514A070: ??? (in /lib/x86_64-linux-gnu/libdbus-1.so.3.5.8)
by 0x514AA63: ??? (in /lib/x86_64-linux-gnu/libdbus-1.so.3.5.8)
by 0x514B0A5: ??? (in /lib/x86_64-linux-gnu/libdbus-1.so.3.5.8)
by 0x5149E0C: ??? (in /lib/x86_64-linux-gnu/libdbus-1.so.3.5.8)
by 0x5134D24: ??? (in /lib/x86_64-linux-gnu/libdbus-1.so.3.5.8)
by 0x5136088: ??? (in /lib/x86_64-linux-gnu/libdbus-1.so.3.5.8)
by 0x5135643: dbus_connection_send_with_reply_and_block (in /lib/x86_64-linux-gnu/libdbus-1.so.3.5.8)
by 0x5130C93: dbus_bus_register (in /lib/x86_64-linux-gnu/libdbus-1.so.3.5.8)
102 bytes in 1 blocks are indirectly lost in loss record 154 of 220
at 0x4C2B7B2: realloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
by 0x514F02F: ??? (in /lib/x86_64-linux-gnu/libdbus-1.so.3.5.8)
by 0x514F0DD: ??? (in /lib/x86_64-linux-gnu/libdbus-1.so.3.5.8)
by 0x514F239: ??? (in /lib/x86_64-linux-gnu/libdbus-1.so.3.5.8)
by 0x514DE0A: ??? (in /lib/x86_64-linux-gnu/libdbus-1.so.3.5.8)
by 0x514E3D3: ??? (in /lib/x86_64-linux-gnu/libdbus-1.so.3.5.8)
by 0x513C138: ??? (in /lib/x86_64-linux-gnu/libdbus-1.so.3.5.8)
by 0x513FF4D: dbus_message_iter_append_basic (in /lib/x86_64-linux-gnu/libdbus-1.so.3.5.8)
by 0x5141790: dbus_message_new_error (in /lib/x86_64-linux-gnu/libdbus-1.so.3.5.8)
by 0x5135C70: dbus_connection_dispatch (in /lib/x86_64-linux-gnu/libdbus-1.so.3.5.8)
by 0x40A747: message_dispatch (mainloop.c:76)
by 0x4E7A91A: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3200.3)
168 bytes in 1 blocks are indirectly lost in loss record 185 of 220
at 0x4C2B7B2: realloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
by 0x514F02F: ??? (in /lib/x86_64-linux-gnu/libdbus-1.so.3.5.8)
by 0x514F0DD: ??? (in /lib/x86_64-linux-gnu/libdbus-1.so.3.5.8)
by 0x514F239: ??? (in /lib/x86_64-linux-gnu/libdbus-1.so.3.5.8)
by 0x513A3B3: ??? (in /lib/x86_64-linux-gnu/libdbus-1.so.3.5.8)
by 0x514228F: ??? (in /lib/x86_64-linux-gnu/libdbus-1.so.3.5.8)
by 0x5149F46: ??? (in /lib/x86_64-linux-gnu/libdbus-1.so.3.5.8)
by 0x514A070: ??? (in /lib/x86_64-linux-gnu/libdbus-1.so.3.5.8)
by 0x514AA63: ??? (in /lib/x86_64-linux-gnu/libdbus-1.so.3.5.8)
by 0x514B0A5: ??? (in /lib/x86_64-linux-gnu/libdbus-1.so.3.5.8)
by 0x5149E0C: ??? (in /lib/x86_64-linux-gnu/libdbus-1.so.3.5.8)
by 0x5134D24: ??? (in /lib/x86_64-linux-gnu/libdbus-1.so.3.5.8)
