* Re: [PATCH v3 3/4] bluetooth: hci_uart: add LL protocol serdev driver support
From: Rob Herring @ 2017-04-19 20:47 UTC (permalink / raw)
To: Adam Ford
Cc: Marcel Holtmann, open list:BLUETOOTH DRIVERS, Mark Rutland,
devicetree@vger.kernel.org, Johan Hedberg, Gustavo Padovan,
Satish Patel, Wei Xu, Eyal Reizer, netdev,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <CAHCN7xLNcD1rmifEOyPhG2rpB_C81hsyzV9W2q6kCQkKa69sZg@mail.gmail.com>
On Mon, Apr 17, 2017 at 3:11 PM, Adam Ford <aford173@gmail.com> wrote:
> On Thu, Apr 13, 2017 at 10:03 AM, Rob Herring <robh@kernel.org> wrote:
>> Turns out that the LL protocol and the TI-ST are the same thing AFAICT.
>> The TI-ST adds firmware loading, GPIO control, and shared access for
>> NFC, FM radio, etc. For now, we're only implementing what is needed for
>> BT. This mirrors other drivers like BCM and Intel, but uses the new
>> serdev bus.
>>
>> The firmware loading is greatly simplified by using existing
>> infrastructure to send commands. It may be a bit slower than the
>> original code using synchronous functions, but the real bottleneck is
>> likely doing firmware load at 115.2kbps.
>
> I am using pdata-quirks to drive my wl1283 Bluetooth on a DM3730. I
> have the Bluetooth set to 3000000 baud in pdata quirks. Looking at
> the binding, I don't see an option to set the baudrate. Is there (or
> will there) be a way to set the baud rate of the Bluetooth?
If you read hci_ti_probe, you will see it is already there. The
default is 3Mbps and the DT can override that with "max-speed". The
intent is that 3Mbps is the max the device can do and max-speed is
only for board or host limitations. Though I just checked the
datasheet on the 1835 and it can go up to 4364kbps. No datasheets for
wl1283, so I have no idea what the max is.
>> +static int hci_ti_probe(struct serdev_device *serdev)
>> +{
>> + struct hci_uart *hu;
>> + struct ll_device *lldev;
>> + u32 max_speed = 3000000;
[...]
>> + of_property_read_u32(serdev->dev.of_node, "max-speed", &max_speed);
>> + hci_uart_set_speeds(hu, 115200, max_speed);
^ permalink raw reply
* Re: [PATCH v3 1/4] dt-bindings: net: Add TI WiLink shared transport binding
From: Rob Herring @ 2017-04-19 20:49 UTC (permalink / raw)
To: Adam Ford
Cc: Mark Rutland, Johan Hedberg, Wei Xu, Eyal Reizer,
devicetree@vger.kernel.org, open list:BLUETOOTH DRIVERS,
Gustavo Padovan, Marcel Holtmann, Satish Patel,
linux-arm-kernel@lists.infradead.org, netdev
In-Reply-To: <CAHCN7x+G_jbQTDfyPBZ4Er8vz46tEojrWf29Eztq56c9zBnMeA@mail.gmail.com>
On Sun, Apr 16, 2017 at 9:09 AM, Adam Ford <aford173@gmail.com> wrote:
>
>
> On Apr 13, 2017 10:04 AM, "Rob Herring" <robh@kernel.org> wrote:
>
> Add serial slave device binding for the TI WiLink series of Bluetooth/FM/GPS
> devices.
>
> Signed-off-by: Rob Herring <robh@kernel.org>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: netdev@vger.kernel.org
> Cc: devicetree@vger.kernel.org
> ---
> v3:
> - rebase on bluetooth-next
>
> .../devicetree/bindings/net/ti,wilink-st.txt | 35
> ++++++++++++++++++++++
> 1 file changed, 35 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/net/ti,wilink-st.txt
>
> diff --git a/Documentation/devicetree/bindings/net/ti,wilink-st.txt
> b/Documentation/devicetree/bindings/net/ti,wilink-st.txt
> new file mode 100644
> index 000000000000..cbad73a84ac4
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/ti,wilink-st.txt
> @@ -0,0 +1,35 @@
> +TI WiLink 7/8 (wl12xx/wl18xx) Shared Transport BT/FM/GPS devices
> +
> +TI WiLink devices have a UART interface for providing Bluetooth, FM radio,
> +and GPS over what's called "shared transport". The shared transport is
> +standard BT HCI protocol with additional channels for the other functions.
> +
> +These devices also have a separate WiFi interface as described in
> +wireless/ti,wlcore.txt.
> +
> +This bindings follows the UART slave device binding in
> +../serial/slave-device.txt.
> +
> +Required properties:
> + - compatible: should be one of the following:
> + "ti,wl1271-st"
> + "ti,wl1273-st"
> + "ti,wl1831-st"
> + "ti,wl1835-st"
> + "ti,wl1837-st"
> +
>
>
> Would you expect the wl1283 chipset too?
Probably, but I left it out as there's no public information.
> I can help test this if you like after the holiday weekend. I have a board
> with WL1283 and currently using pdata-quirks to support it.
^ permalink raw reply
* Re: GATT Server: DBus GATT Services not advertised/exported
From: Olivier MARTIN @ 2017-04-19 23:20 UTC (permalink / raw)
To: Barry Byford; +Cc: Bluez mailing list
In-Reply-To: <CAAu3APaxi82L56NNEnpZP4o+Z99qE_aGcAzGRJFOe+j0N_8irA@mail.gmail.com>
I am back on the thread.
What I noticed last week when I tried on Android phone with both "BLE
Scanner" and "Nordic Connect", discovering GATT services is really
really slow (it takes 2 min to discover all `example-gatt-server` GATT
services) on Nexus 4 with Android 5.1.1 and Ubuntu 16.04 with Bluez
v5.44 for the GATT server. I am using the Asus USB-BT400 (Broadcom
chipset).
I did more investigation this evening but I have not done any progress.
I tried with `example-gatt-server` started by the user and root and no
change in the poor performance.
I do not know what is taking so long but for instance it takes many
seconds to execute this part:
bluetoothd[12913]: src/device.c:gatt_debug() Read By Type - start:
0x005e end: 0x0061
bluetoothd[12913]: src/device.c:gatt_debug() Read By Type - start:
0x0060 end: 0x0061
bluetoothd[12913]: src/device.c:gatt_debug() Find Info - start: 0x0061
end: 0x0061
bluetoothd[12913]: src/device.c:gatt_debug() Read By Type - start:
0x0062 end: 0x0071
bluetoothd[12913]: src/device.c:gatt_debug() Read By Type - start:
0x0062 end: 0x0071
bluetoothd[12913]: src/device.c:gatt_debug() Read By Type - start:
0x006e end: 0x0071
bluetoothd[12913]: src/device.c:gatt_debug() Find Info - start: 0x0065
end: 0x0067
bluetoothd[12913]: src/device.c:gatt_debug() Find Info - start: 0x0066
end: 0x0067
bluetoothd[12913]: src/device.c:gatt_debug() Find Info - start: 0x0067
end: 0x0067
bluetoothd[12913]: src/device.c:gatt_debug() Find Info - start: 0x006a
end: 0x006c
bluetoothd[12913]: src/device.c:gatt_debug() Find Info - start: 0x006b
end: 0x006c
bluetoothd[12913]: src/device.c:gatt_debug() Find Info - start: 0x006c
end: 0x006c
bluetoothd[12913]: src/device.c:gatt_debug() Find Info - start: 0x006f
end: 0x0071
bluetoothd[12913]: src/device.c:gatt_debug() Find Info - start: 0x0070
end: 0x0071
bluetoothd[12913]: src/device.c:gatt_debug() Find Info - start: 0x0071
end: 0x0071
bluetoothd[12913]: src/device.c:gatt_debug() Read By Type - start:
0x0072 end: 0x0079
bluetoothd[12913]: src/device.c:gatt_debug() Read By Type - start:
0x0072 end: 0x0079
bluetoothd[12913]: src/device.c:gatt_debug() Read By Type - start:
0x0079 end: 0x0079
bluetoothd[12913]: src/device.c:gatt_debug() Find Info - start: 0x0077
end: 0x0077
On 14.04.2017 20:31, Barry Byford wrote:
> Hello Olivier,
>
> On 14 April 2017 at 19:14, Olivier MARTIN <olivier@labapart.com> wrote:
>> Thanks Barry, setting 'ControllerMode = le' in
>> /etc/bluetooth/main.conf
>> fixed my issue. I can now see the GATT services.
>
> Good news!
>
>> But I guess my adapter now only works as BLE adapter and will ignore
>> the
>> non-LE devices.
>> In the comment of /etc/bluetooth/main.conf it is written the adapter
>> should
>> be by default set as 'dual'.
>>
>> Is it a bug in Bluez? Why GATT services are not exposed while using
>> the
>> default value for 'ControllerMode'?
>
> This issue has come up before and was discuss here:
> http://marc.info/?l=linux-bluetooth&m=146071596012263&w=2
>
>
>
>
>> On 14.04.2017 14:30, Barry Byford wrote:
>>>
>>> Hello Olivier,
>>>
>>>
>>> On 14 April 2017 at 12:01, Olivier MARTIN <olivier@labapart.com>
>>> wrote:
>>>>
>>>> You are right Barry, `example-advertisement` seems to work well (I
>>>> installed
>>>> and tried Nordic nRF Connect and I can see the expected advertisemet
>>>> data).
>>>
>>>
>>> Excellent!
>>>
>>>
>>>> But I cannot still manage to get `example-gatt-server` :-(
>>>> I am sure I got it working last year with an older version of Bluez.
>>>> But
>>>> I
>>>> cannot make it work with Bluez v5.44.
>>>
>>>
>>> OK, I've taken a look at "example-gatt-server" and have it working...
>>>
>>>>
>>>> My testing procedure:
>>>>
>>>> 1. [Laptop] First terminal: Start `sudo ./src/bluetoothd -E -n -d`
>>>> 2. [Laptop] Second terminal: Start unmodified Bluez
>>>> ./test/example-gatt-server
>>>> 3. [Laptop] Third terminal: Ensure the adapter is "Powered: yes" and
>>>> "Discoverable: yes"
>>>
>>>
>>> OK, I've done this slightly different (details below). However, the
>>> first thing I did was edit "/etc/bluetooth/main.conf"
>>> I added the following line to the end of the file:
>>>
>>> ControllerMode = le
>>>
>>> Then I did the following:
>>> 1. [SBC1:T1] sudo ./src/bluetoothd -E -n -d
>>> 2. [SBC1:T2] ./example-gatt-server
>>> 3. [SBC1:T3] ./example-advertisement
>>>
>>>
>>>>
>>>> 4. [Android] Connect using Nordic nRF Connect (I also tried with
>>>> "BLE
>>>> Scanner") and check I see the exposed GATT services by
>>>> `example-gatt-server`
>>>> Unfortunately, I can only see:
>>>> - Generic Access Service (0x1800)
>>>> - Generic Attribute Service (0x1801)
>>>>
>>>
>>> I've used bluetoothctl on SBC2 to connect and read the battery values
>>> that the GATT server is counting down.
>>>
>>> $ bluetoothctl
>>> [NEW] Controller 00:00:00:00:5A:AD linaro-alip [default]
>>> [bluetooth]# scan on
>>> Discovery started
>>> [CHG] Controller 00:00:00:00:5A:AD Discovering: yes
>>> [NEW] Device B8:27:EB:22:57:E0 BluezeroLight
>>> [bluetooth]# scan off
>>> Discovery stopped
>>> [CHG] Controller 00:00:00:00:5A:AD Discovering: no
>>> [bluetooth]# connect B8:27:EB:22:57:E0
>>> Attempting to connect to B8:27:EB:22:57:E0
>>> [CHG] Device B8:27:EB:22:57:E0 Connected: yes
>>> Connection successful
>>> [...snip...]
>>> [NEW] Primary Service
>>> /org/bluez/hci0/dev_B8_27_EB_22_57_E0/service000a
>>> 0000180f-0000-1000-8000-00805f9b34fb
>>> Battery Service
>>> [NEW] Characteristic
>>> /org/bluez/hci0/dev_B8_27_EB_22_57_E0/service000a/char000b
>>> 00002a19-0000-1000-8000-00805f9b34fb
>>> Battery Level
>>> [...snip...]
>>> [CHG] Device B8:27:EB:22:57:E0 ServicesResolved: yes
>>> [BluezeroLight]# select-attribute
>>> /org/bluez/hci0/dev_B8_27_EB_22_57_E0/service000a/char000b
>>> [BluezeroLight:/service000a/char000b]# read
>>> Attempting to read
>>> /org/bluez/hci0/dev_B8_27_EB_22_57_E0/service000a/char000b
>>> [CHG] Attribute
>>> /org/bluez/hci0/dev_B8_27_EB_22_57_E0/service000a/char000b Value:
>>> 0x46
>>> 46 F
>>> [BluezeroLight:/service000a/char000b]# notify on
>>> [CHG] Attribute
>>> /org/bluez/hci0/dev_B8_27_EB_22_57_E0/service000a/char000b Notifying:
>>> yes
>>> Notify started
>>> [CHG] Attribute
>>> /org/bluez/hci0/dev_B8_27_EB_22_57_E0/service000a/char000b Value:
>>> 0x46
>>> [CHG] Attribute
>>> /org/bluez/hci0/dev_B8_27_EB_22_57_E0/service000a/char000b Value:
>>> 0x44
>>> [CHG] Attribute
>>> /org/bluez/hci0/dev_B8_27_EB_22_57_E0/service000a/char000b Value:
>>> 0x42
>>> [CHG] Attribute
>>> /org/bluez/hci0/dev_B8_27_EB_22_57_E0/service000a/char000b Value:
>>> 0x40
>>> [CHG] Attribute
>>> /org/bluez/hci0/dev_B8_27_EB_22_57_E0/service000a/char000b Value:
>>> 0x3e
>>> [BluezeroLight:/service000a/char000b]# notify off
>>> [CHG] Attribute
>>> /org/bluez/hci0/dev_B8_27_EB_22_57_E0/service000a/char000b Notifying:
>>> no
>>> Notify stopped
>>>
>>>
>>> That seems to be working then. When I didn't have "ControllerMode =
>>> le" set then I did see it be unpredictable if it successfully
>>> connected or not.
>>> This also worked connecting with the nRF app.
>>>
>>>
>>> Does that work for you?
>>>
>>>
>>>
>>>
>>>> If I had to suspect Bluez code, I will guess there is something
>>>> missing
>>>> around here:
>>>>
>>>> bluetoothd[20429]: src/device.c:gatt_server_init() #
>>>> gatt_server_init
>>>> bluetoothd[20429]: src/device.c:gatt_debug() Primary services found:
>>>> 2
>>>> bluetoothd[20429]: src/device.c:gatt_debug() start: 0x0001, end:
>>>> 0x0005,
>>>> uuid: 00001801-0000-1000-8000-00805f9b34fb
>>>> bluetoothd[20429]: src/device.c:gatt_debug() start: 0x0014, end:
>>>> 0xffff,
>>>> uuid: 00001800-0000-1000-8000-00805f9b34fb
>>>> bluetoothd[20429]: src/device.c:gatt_debug() Registered handler for
>>>> "Service
>>>> Changed": 0
>>>> bluetoothd[20429]: src/device.c:gatt_client_ready_cb() status:
>>>> success,
>>>> error: 0
>>>>
>>>> As Bluez daemon does not get the GATT services from Buez GATT
>>>> Database.
>>>> But
>>>> it might be me who miss a step...
>>>>
>>>>
>>>> On 14.04.2017 12:37, Barry Byford wrote:
>>>>>
>>>>>
>>>>> example-advertisementHello Oliver,
>>>>>
>>>>>
>>>>> On 14 April 2017 at 11:03, Olivier MARTIN <olivier@labapart.com>
>>>>> wrote:
>>>>>>
>>>>>>
>>>>>> Thanks for replying my message Barry,
>>>>>>
>>>>>> Sorry, I forgot to mention but I start Bluez daemon with `sudo
>>>>>> ./src/bluetoothd -E -n -d` (after stopping the bluetooth service).
>>>>>> So I
>>>>>> already run it with sudo and experimental option.
>>>>>>
>>>>>> I am not sure to understand what you mean by "this kind of error
>>>>>> message".
>>>>>> Because I do not see any error message in the log I provided.
>>>>>
>>>>>
>>>>>
>>>>> OK, that was bad on my part. I read it as complaining that there
>>>>> were
>>>>> too many advertisements. Looking again that wasn't what it was say.
>>>>> Apologies.
>>>>>
>>>>>>
>>>>>> Any other idea?
>>>>>
>>>>>
>>>>>
>>>>> I am by Linux Single Board Computers (SBC) today so I'm able to run
>>>>> what you are running and can show you what I'm seeing. I'll focus
>>>>> on
>>>>> example-advertisement first as example-gatt-server doesn't change
>>>>> the
>>>>> advertisements.
>>>>>
>>>>> I've started the BlueZ daemon with "./src/bluetoothd -E -n -d"
>>>>>
>>>>> In another shell when I start "./example-advertisement" I see the
>>>>> following in the output:
>>>>>
>>>>> bluetoothd[2325]: src/adapter.c:property_set_mode() sending Set
>>>>> Powered command for index 0
>>>>> bluetoothd[2325]: src/adapter.c:property_set_mode_complete()
>>>>> Success
>>>>> (0x00)
>>>>> bluetoothd[2325]: src/adapter.c:new_settings_callback() Settings:
>>>>> 0x00000ad1
>>>>> bluetoothd[2325]: src/adapter.c:settings_changed() Changed
>>>>> settings:
>>>>> 0x00000001
>>>>> bluetoothd[2325]: src/adapter.c:adapter_start() adapter
>>>>> /org/bluez/hci0 has been enabled
>>>>> bluetoothd[2325]: src/adapter.c:trigger_passive_scanning()
>>>>> bluetoothd[2325]: src/advertising.c:register_advertisement()
>>>>> RegisterAdvertisement
>>>>> bluetoothd[2325]: src/advertising.c:client_create() Adding proxy
>>>>> for
>>>>> /org/bluez/example/advertisement0
>>>>> bluetoothd[2325]: src/advertising.c:register_advertisement()
>>>>> Registered advertisement at path /org/bluez/example/advertisement0
>>>>> bluetoothd[2325]: src/advertising.c:parse_service_uuids() Adding
>>>>> ServiceUUID: 180D
>>>>> bluetoothd[2325]: src/advertising.c:parse_service_uuids() Adding
>>>>> ServiceUUID: 180F
>>>>> bluetoothd[2325]: src/advertising.c:parse_manufacturer_data()
>>>>> Adding
>>>>> ManufacturerData for ffff
>>>>> bluetoothd[2325]: src/advertising.c:parse_service_data() Adding
>>>>> ServiceData for 9999
>>>>> bluetoothd[2325]: src/advertising.c:refresh_advertisement()
>>>>> Refreshing
>>>>> advertisement: /org/bluez/example/advertisement0
>>>>> bluetoothd[2325]: src/advertising.c:add_adv_callback()
>>>>> Advertisement
>>>>> registered: /org/bluez/example/advertisement0
>>>>>
>>>>>
>>>>> On a second SBC, at the command line I run "bluetoothctl" and do
>>>>> "scan
>>>>> on". Once my first SBC is found I do "scan off". I then do "info
>>>>> B8:27:EB:22:57:E0" (this is the address of the first SBC) which
>>>>> gives
>>>>> the following output:
>>>>>
>>>>> [bluetooth]# info B8:27:EB:22:57:E0
>>>>> Device B8:27:EB:22:57:E0
>>>>> Alias: B8-27-EB-22-57-E0
>>>>> Paired: no
>>>>> Trusted: no
>>>>> Blocked: no
>>>>> Connected: no
>>>>> LegacyPairing: no
>>>>> UUID: Heart Rate
>>>>> (0000180d-0000-1000-8000-00805f9b34fb)
>>>>> UUID: Battery Service
>>>>> (0000180f-0000-1000-8000-00805f9b34fb)
>>>>> ManufacturerData Key: 0xffff
>>>>> ManufacturerData Value: 0x00
>>>>> ManufacturerData Value: 0x01
>>>>> ManufacturerData Value: 0x02
>>>>> ManufacturerData Value: 0x03
>>>>> ManufacturerData Value: 0x04
>>>>> ServiceData Key: 00009999-0000-1000-8000-00805f9b34fb
>>>>> ServiceData Value: 0x00
>>>>> ServiceData Value: 0x01
>>>>> ServiceData Value: 0x02
>>>>> ServiceData Value: 0x03
>>>>> ServiceData Value: 0x04
>>>>>
>>>>>
>>>>> I've also done a scan from my Android phone (using the Nordic nRF
>>>>> Connect app) and can see the advertisements also (just hard to
>>>>> share
>>>>> that information on here).
>>>>>
>>>>> Does that help?
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>> On 13.04.2017 19:59, Barry Byford wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Hello Olivier,
>>>>>>>
>>>>>>>
>>>>>>> On 13 April 2017 at 12:14, Olivier MARTIN <olivier@labapart.com>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Hi all,
>>>>>>>> I am having issue to advertise/export GATT services exposed
>>>>>>>> through
>>>>>>>> DBus
>>>>>>>> API. I tried `./test/example-gatt-server`. And I also tried to
>>>>>>>> merge
>>>>>>>> `./test/example-advertisement` into
>>>>>>>> `./test/example-gatt-server`. But
>>>>>>>> in
>>>>>>>> both cases I only see the two compulsory GATT services:
>>>>>>>> - Generic Access Service (0x1800)
>>>>>>>> - Generic Attribute Service (0x1801)
>>>>>>>>
>>>>>>>> I am using Bluez v5.44. And I also tried Bluez v5.37.
>>>>>>>>
>>>>>>>> GATT Services seem to be discovered by Bluez (note: I added
>>>>>>>> additional
>>>>>>>> debug
>>>>>>>> statement all prefixed with '#'):
>>>>>>>>
>>>>>>>> bluetoothd[16877]: src/gatt-database.c:manager_register_app() #
>>>>>>>> manager_register_app
>>>>>>>> bluetoothd[16877]: src/gatt-database.c:create_app() # create_app
>>>>>>>> bluetoothd[16877]: src/gatt-database.c:manager_register_app()
>>>>>>>> Registering
>>>>>>>> application: :1.404:/
>>>>>>>> bluetoothd[16877]: src/advertising.c:register_advertisement()
>>>>>>>> RegisterAdvertisement
>>>>>>>> bluetoothd[16877]: src/advertising.c:client_create() Adding
>>>>>>>> proxy for
>>>>>>>> /org/bluez/example/advertisement0
>>>>>>>> bluetoothd[16877]: src/advertising.c:register_advertisement()
>>>>>>>> Registered
>>>>>>>> advertisement at path /org/bluez/example/advertisement0
>>>>>>>> bluetoothd[16877]: src/gatt-database.c:proxy_added_cb() Object
>>>>>>>> received:
>>>>>>>> /org/bluez/example/service0/char2, iface:
>>>>>>>> org.bluez.GattCharacteristic1
>>>>>>>> bluetoothd[16877]: src/gatt-database.c:proxy_added_cb() Object
>>>>>>>> received:
>>>>>>>> /org/bluez/example/service2/char0/desc0, iface:
>>>>>>>> org.bluez.GattDescriptor1
>>>>>>>> bluetoothd[16877]: src/gatt-database.c:proxy_added_cb() Object
>>>>>>>> received:
>>>>>>>> /org/bluez/example/service2/char2/desc3, iface:
>>>>>>>> org.bluez.GattDescriptor1
>>>>>>>> bluetoothd[16877]: src/gatt-database.c:proxy_added_cb() Object
>>>>>>>> received:
>>>>>>>> /org/bluez/example/service2/char2, iface:
>>>>>>>> org.bluez.GattCharacteristic1
>>>>>>>> bluetoothd[16877]: src/gatt-database.c:proxy_added_cb() Object
>>>>>>>> received:
>>>>>>>> /org/bluez/example/service1/char0, iface:
>>>>>>>> org.bluez.GattCharacteristic1
>>>>>>>> bluetoothd[16877]: src/gatt-database.c:proxy_added_cb() Object
>>>>>>>> received:
>>>>>>>> /org/bluez/example/service2/char1, iface:
>>>>>>>> org.bluez.GattCharacteristic1
>>>>>>>> bluetoothd[16877]: src/gatt-database.c:proxy_added_cb() Object
>>>>>>>> received:
>>>>>>>> /org/bluez/example/service0/char1, iface:
>>>>>>>> org.bluez.GattCharacteristic1
>>>>>>>> bluetoothd[16877]: src/gatt-database.c:proxy_added_cb() Object
>>>>>>>> received:
>>>>>>>> /org/bluez/example/service2/char1/desc3, iface:
>>>>>>>> org.bluez.GattDescriptor1
>>>>>>>> bluetoothd[16877]: src/gatt-database.c:proxy_added_cb() Object
>>>>>>>> received:
>>>>>>>> /org/bluez/example/service2/char1/desc2, iface:
>>>>>>>> org.bluez.GattDescriptor1
>>>>>>>> bluetoothd[16877]: src/gatt-database.c:proxy_added_cb() Object
>>>>>>>> received:
>>>>>>>> /org/bluez/example/service0/char0, iface:
>>>>>>>> org.bluez.GattCharacteristic1
>>>>>>>> bluetoothd[16877]: src/gatt-database.c:proxy_added_cb() Object
>>>>>>>> received:
>>>>>>>> /org/bluez/example/service2, iface: org.bluez.GattService1
>>>>>>>> bluetoothd[16877]: src/gatt-database.c:proxy_added_cb() Object
>>>>>>>> received:
>>>>>>>> /org/bluez/example/service1, iface: org.bluez.GattService1
>>>>>>>> bluetoothd[16877]: src/gatt-database.c:proxy_added_cb() Object
>>>>>>>> received:
>>>>>>>> /org/bluez/example/service0, iface: org.bluez.GattService1
>>>>>>>> bluetoothd[16877]: src/gatt-database.c:proxy_added_cb() Object
>>>>>>>> received:
>>>>>>>> /org/bluez/example/service2/char0/desc1, iface:
>>>>>>>> org.bluez.GattDescriptor1
>>>>>>>> bluetoothd[16877]: src/gatt-database.c:proxy_added_cb() Object
>>>>>>>> received:
>>>>>>>> /org/bluez/example/service2/char2/desc2, iface:
>>>>>>>> org.bluez.GattDescriptor1
>>>>>>>> bluetoothd[16877]: src/gatt-database.c:proxy_added_cb() Object
>>>>>>>> received:
>>>>>>>> /org/bluez/example/service2/char0, iface:
>>>>>>>> org.bluez.GattCharacteristic1
>>>>>>>> bluetoothd[16877]: src/gatt-database.c:client_ready_cb() #
>>>>>>>> client_ready_cb
>>>>>>>> bluetoothd[16877]: src/gatt-database.c:create_service() #
>>>>>>>> create_service
>>>>>>>> from /org/bluez/example/service2
>>>>>>>> bluetoothd[16877]: src/gatt-database.c:create_service() #
>>>>>>>> create_service
>>>>>>>> from /org/bluez/example/service1
>>>>>>>> bluetoothd[16877]: src/gatt-database.c:create_service() #
>>>>>>>> create_service
>>>>>>>> from /org/bluez/example/service0
>>>>>>>> bluetoothd[16877]: src/gatt-database.c:database_add_app() #
>>>>>>>> database_add_app
>>>>>>>> bluetoothd[16877]: src/gatt-database.c:database_add_service() #
>>>>>>>> database_add_service
>>>>>>>> bluetoothd[16877]: src/gatt-database.c:cep_write_cb() Stored CEP
>>>>>>>> value
>>>>>>>> in
>>>>>>>> the database
>>>>>>>> bluetoothd[16877]: src/gatt-database.c:database_add_cep()
>>>>>>>> Created CEP
>>>>>>>> entry
>>>>>>>> for characteristic
>>>>>>>> bluetoothd[16877]: src/gatt-database.c:cep_write_cb() Stored CEP
>>>>>>>> value
>>>>>>>> in
>>>>>>>> the database
>>>>>>>> bluetoothd[16877]: src/gatt-database.c:database_add_cep()
>>>>>>>> Created CEP
>>>>>>>> entry
>>>>>>>> for characteristic
>>>>>>>> bluetoothd[16877]: src/gatt-database.c:cep_write_cb() Stored CEP
>>>>>>>> value
>>>>>>>> in
>>>>>>>> the database
>>>>>>>> bluetoothd[16877]: src/gatt-database.c:database_add_cep()
>>>>>>>> Created CEP
>>>>>>>> entry
>>>>>>>> for characteristic
>>>>>>>> bluetoothd[16877]: src/gatt-database.c:gatt_db_service_added() #
>>>>>>>> gatt_db_service_added: GATT Service added to local database
>>>>>>>> bluetoothd[16877]: src/gatt-database.c:database_add_service() #
>>>>>>>> database_add_service
>>>>>>>> bluetoothd[16877]: src/gatt-database.c:database_add_ccc()
>>>>>>>> Created CCC
>>>>>>>> entry
>>>>>>>> for characteristic
>>>>>>>> bluetoothd[16877]: src/gatt-database.c:gatt_db_service_added() #
>>>>>>>> gatt_db_service_added: GATT Service added to local database
>>>>>>>> bluetoothd[16877]: src/gatt-database.c:database_add_service() #
>>>>>>>> database_add_service
>>>>>>>> bluetoothd[16877]: src/gatt-database.c:database_add_ccc()
>>>>>>>> Created CCC
>>>>>>>> entry
>>>>>>>> for characteristic
>>>>>>>> bluetoothd[16877]: src/gatt-database.c:gatt_db_service_added() #
>>>>>>>> gatt_db_service_added: GATT Service added to local database
>>>>>>>> bluetoothd[16877]: src/gatt-database.c:client_ready_cb() GATT
>>>>>>>> application
>>>>>>>> registered: :1.404:/
>>>>>>>> bluetoothd[16877]: src/advertising.c:parse_service_uuids()
>>>>>>>> Adding
>>>>>>>> ServiceUUID: 180D
>>>>>>>> bluetoothd[16877]: src/advertising.c:parse_service_uuids()
>>>>>>>> Adding
>>>>>>>> ServiceUUID: 180F
>>>>>>>> bluetoothd[16877]: src/advertising.c:parse_manufacturer_data()
>>>>>>>> Adding
>>>>>>>> ManufacturerData for ffff
>>>>>>>> bluetoothd[16877]: src/advertising.c:parse_service_data() Adding
>>>>>>>> ServiceData
>>>>>>>> for 9999
>>>>>>>> bluetoothd[16877]: src/advertising.c:refresh_advertisement()
>>>>>>>> Refreshing
>>>>>>>> advertisement: /org/bluez/example/advertisement0
>>>>>>>> bluetoothd[16877]: src/advertising.c:add_adv_callback()
>>>>>>>> Advertisement
>>>>>>>> registered: /org/bluez/example/advertisement0
>>>>>>>>
>>>>>>>> I start `./test/example-gatt-server` as a normal user. But Bluez
>>>>>>>> does
>>>>>>>> not
>>>>>>>> seem to have any permission issue with it.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Building from source I've seen something similar if I've used
>>>>>>> sudo for
>>>>>>> the
>>>>>>> make.
>>>>>>>
>>>>>>> To compile and install I use sudo for the install only:
>>>>>>>
>>>>>>> make -j 4 && sudo make install
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> I am using 'BLE scanner' on Android to discover the GATT
>>>>>>>> services.
>>>>>>>> But
>>>>>>>> I
>>>>>>>> think the problem is coming from Bluez. When I connect the
>>>>>>>> Android
>>>>>>>> device
>>>>>>>> to
>>>>>>>> Bluez, I can see this log:
>>>>>>>>
>>>>>>>> bluetoothd[16877]: src/adapter.c:connected_callback() hci0
>>>>>>>> device
>>>>>>>> 98:D6:F7:31:7B:0D connected eir_len 14
>>>>>>>> bluetoothd[16877]: src/gatt-database.c:connect_cb() New incoming
>>>>>>>> BR/EDR
>>>>>>>> ATT
>>>>>>>> connection
>>>>>>>> bluetoothd[16877]: attrib/gattrib.c:g_attrib_ref() 0x98cd908:
>>>>>>>> g_attrib_ref=1
>>>>>>>> bluetoothd[16877]: src/device.c:load_gatt_db() # load_gatt_db:
>>>>>>>> Restoring
>>>>>>>> 98:D6:F7:31:7B:0D gatt database from file
>>>>>>>> '/var/lib/bluetooth/5C:F3:70:6A:D9:3C/cache/98:D6:F7:31:7B:0D'
>>>>>>>> bluetoothd[16877]: src/device.c:load_gatt_db_impl() #
>>>>>>>> load_gatt_db_impl
>>>>>>>> bluetoothd[16877]: src/device.c:load_service() # load_service:
>>>>>>>> loading
>>>>>>>> service: 0x0001, end: 0x0005, uuid:
>>>>>>>> 00001801-0000-1000-8000-00805f9b34fb
>>>>>>>> bluetoothd[16877]: src/device.c:load_service() # load_service:
>>>>>>>> loading
>>>>>>>> service: 0x0014, end: 0xffff, uuid:
>>>>>>>> 00001800-0000-1000-8000-00805f9b34fb
>>>>>>>> bluetoothd[16877]: src/device.c:load_chrc() loading
>>>>>>>> characteristic
>>>>>>>> handle:
>>>>>>>> 0x0002, value handle: 0x0003, properties 0x0020 uuid:
>>>>>>>> 00002a05-0000-1000-8000-00805f9b34fb
>>>>>>>> bluetoothd[16877]: src/device.c:load_chrc() loading
>>>>>>>> characteristic
>>>>>>>> handle:
>>>>>>>> 0x0015, value handle: 0x0016, properties 0x0002 uuid:
>>>>>>>> 00002a00-0000-1000-8000-00805f9b34fb
>>>>>>>> bluetoothd[16877]: src/device.c:load_chrc() loading
>>>>>>>> characteristic
>>>>>>>> handle:
>>>>>>>> 0x0017, value handle: 0x0018, properties 0x0002 uuid:
>>>>>>>> 00002a01-0000-1000-8000-00805f9b34fb
>>>>>>>> bluetoothd[16877]: src/device.c:load_gatt_db() List GATT
>>>>>>>> Primaries
>>>>>>>> before
>>>>>>>> being free:
>>>>>>>> bluetoothd[16877]: src/device.c:print_primary() - Primary UUID:
>>>>>>>> 00001801-0000-1000-8000-00805f9b34fb
>>>>>>>> bluetoothd[16877]: src/device.c:print_primary() - Primary UUID:
>>>>>>>> 00001800-0000-1000-8000-00805f9b34fb
>>>>>>>> bluetoothd[16877]: src/device.c:add_primary() # add_primary
>>>>>>>> bluetoothd[16877]: src/device.c:add_primary() # add_primary
>>>>>>>> bluetoothd[16877]: profiles/gap/gas.c:gap_accept() GAP profile
>>>>>>>> accept
>>>>>>>> (98:D6:F7:31:7B:0D)
>>>>>>>> bluetoothd[16877]: src/service.c:change_state() 0x98c98e0:
>>>>>>>> device
>>>>>>>> 98:D6:F7:31:7B:0D profile gap-profile state changed:
>>>>>>>> disconnected ->
>>>>>>>> connected (0)
>>>>>>>> bluetoothd[16877]: src/gatt-client.c:btd_gatt_client_connected()
>>>>>>>> Device
>>>>>>>> connected.
>>>>>>>> bluetoothd[16877]: src/device.c:gatt_server_init() #
>>>>>>>> gatt_server_init
>>>>>>>> bluetoothd[16877]: src/device.c:gatt_debug() Primary services
>>>>>>>> found:
>>>>>>>> 2
>>>>>>>> bluetoothd[16877]: src/device.c:gatt_debug() start: 0x0001, end:
>>>>>>>> 0x0005,
>>>>>>>> uuid: 00001801-0000-1000-8000-00805f9b34fb
>>>>>>>> bluetoothd[16877]: src/device.c:gatt_debug() start: 0x0014, end:
>>>>>>>> 0xffff,
>>>>>>>> uuid: 00001800-0000-1000-8000-00805f9b34fb
>>>>>>>> bluetoothd[16877]: src/device.c:gatt_debug() Registered handler
>>>>>>>> for
>>>>>>>> "Service
>>>>>>>> Changed": 0
>>>>>>>> bluetoothd[16877]: src/device.c:gatt_client_ready_cb() status:
>>>>>>>> success,
>>>>>>>> error: 0
>>>>>>>> bluetoothd[16877]: src/device.c:register_gatt_services() #
>>>>>>>> register_gatt_services
>>>>>>>> bluetoothd[16877]: src/device.c:add_primary() # add_primary
>>>>>>>> bluetoothd[16877]: src/device.c:add_primary() # add_primary
>>>>>>>> bluetoothd[16877]: src/device.c:add_gatt_service() #
>>>>>>>> add_gatt_service:
>>>>>>>> UUID:00001801-0000-1000-8000-00805f9b34fb
>>>>>>>> bluetoothd[16877]: src/gatt-client.c:btd_gatt_client_ready()
>>>>>>>> GATT
>>>>>>>> client
>>>>>>>> ready
>>>>>>>> bluetoothd[16877]: src/gatt-client.c:create_services() Exporting
>>>>>>>> objects
>>>>>>>> for
>>>>>>>> GATT services: 98:D6:F7:31:7B:0D
>>>>>>>> bluetoothd[16877]: src/gatt-client.c:service_create() Exported
>>>>>>>> GATT
>>>>>>>> service:
>>>>>>>> /org/bluez/hci0/dev_98_D6_F7_31_7B_0D/service0001
>>>>>>>> bluetoothd[16877]: src/gatt-client.c:characteristic_create()
>>>>>>>> Exported
>>>>>>>> GATT
>>>>>>>> characteristic:
>>>>>>>> /org/bluez/hci0/dev_98_D6_F7_31_7B_0D/service0001/char0002
>>>>>>>> bluetoothd[16877]: src/device.c:device_svc_resolved()
>>>>>>>> /org/bluez/hci0/dev_98_D6_F7_31_7B_0D err 0
>>>>>>>> bluetoothd[16877]: src/device.c:store_gatt_db() # store_gatt_db
>>>>>>>> bluetoothd[16877]: src/device.c:store_service() # store_service
>>>>>>>> bluetoothd[16877]: src/device.c:store_service() # store_service
>>>>>>>> bluetoothd[16877]: profiles/gap/gas.c:read_device_name_cb() GAP
>>>>>>>> Device
>>>>>>>> Name:
>>>>>>>> Nexus 4
>>>>>>>> bluetoothd[16877]: profiles/gap/gas.c:read_appearance_cb() GAP
>>>>>>>> Appearance:
>>>>>>>> 0x0000
>>>>>>>>
>>>>>>>> I also reduced DBus 'TestAdvertisement' interface to only expose
>>>>>>>> one
>>>>>>>> GATT
>>>>>>>> Service as many BLE adapter got a limitation in the size of the
>>>>>>>> advertisement packet:
>>>>>>>> class TestAdvertisement(Advertisement):
>>>>>>>>
>>>>>>>> def __init__(self, bus, index):
>>>>>>>> Advertisement.__init__(self, bus, index, 'peripheral')
>>>>>>>> #self.add_service_uuid('180D') # HeartRate
>>>>>>>> self.add_service_uuid('180F') # Battery
>>>>>>>> #self.add_manufacturer_data(0xffff, [0x00, 0x01, 0x02,
>>>>>>>> 0x03,
>>>>>>>> 0x04])
>>>>>>>> #self.add_service_data('9999', [0x00, 0x01, 0x02, 0x03,
>>>>>>>> 0x04])
>>>>>>>> self.include_tx_power = True
>>>>>>>>
>>>>>>>> My concern is mainly these lines:
>>>>>>>>
>>>>>>>> bluetoothd[16877]: src/device.c:gatt_debug() Primary services
>>>>>>>> found:
>>>>>>>> 2
>>>>>>>> bluetoothd[16877]: src/device.c:gatt_debug() start: 0x0001, end:
>>>>>>>> 0x0005,
>>>>>>>> uuid: 00001801-0000-1000-8000-00805f9b34fb
>>>>>>>> bluetoothd[16877]: src/device.c:gatt_debug() start: 0x0014, end:
>>>>>>>> 0xffff,
>>>>>>>> uuid: 00001800-0000-1000-8000-00805f9b34fb
>>>>>>>>
>>>>>>>
>>>>>>> I've seen this kind of error message when I've had a failure of a
>>>>>>> previous script and the Bluetooth daemon is in some unknown
>>>>>>> state. At
>>>>>>> this point it is worth restarting the bluetooth service with:
>>>>>>> sudo service bluetooth restart
>>>>>>>
>>>>>>> You will see in the advertising DBus API documentation that it is
>>>>>>> still in experimental mode in 5.44.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/doc/advertising-api.txt#n78
>>>>>>>
>>>>>>> This means that you need to make sure bluetoothd is started in
>>>>>>> experimental mode. Have you done this?
>>>>>>> You can check with "sudo service bluetooth status"
>>>>>>>
>>>>>>> Experimental can be switched on by default in the
>>>>>>> bluetooth.service
>>>>>>> file
>>>>>>>
>>>>>>> Edit /lib/systemd/system/bluetooth.service file to add
>>>>>>> --experimental
>>>>>>> flag
>>>>>>> e.g:
>>>>>>>
>>>>>>> sudo sed -i '/^ExecStart.*bluetoothd\s*$/ s/$/ --experimental/'
>>>>>>> /lib/systemd/system/bluetooth.service
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> I have not found the code that export GATT Services from GATT
>>>>>>>> Database
>>>>>>>> to
>>>>>>>> the BLE central.
>>>>>>>>
>>>>>>>> From my search on Internet, it looks I am not the only one who
>>>>>>>> is
>>>>>>>> having
>>>>>>>> this issue
>>>>>>>> I am happy to share/test anything that could help to make some
>>>>>>>> progress.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Olivier
>>>>>>>> --
>>>>>>>> To unsubscribe from this list: send the line "unsubscribe
>>>>>>>> linux-bluetooth"
>>>>>>>> in
>>>>>>>> the body of a message to majordomo@vger.kernel.org
>>>>>>>> More majordomo info at
>>>>>>>> http://vger.kernel.org/majordomo-info.html
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>
>>
^ permalink raw reply
* Re: [PATCH] blutooth: try to improve CONFIG_SERIAL_DEV_BUS dependency
From: Sebastian Reichel @ 2017-04-20 0:15 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Marcel Holtmann, Gustavo Padovan, Johan Hedberg, Rob Herring,
Bjorn Andersson, David S. Miller, Kalle Valo, linux-bluetooth,
linux-kernel
In-Reply-To: <20170419175051.4177480-1-arnd@arndb.de>
[-- Attachment #1: Type: text/plain, Size: 2808 bytes --]
Hi,
On Wed, Apr 19, 2017 at 07:50:18PM +0200, Arnd Bergmann wrote:
> With CONFIG_SERIAL_DEV_BUS=m, the hci_serdev.o file does not actually
> get built into hci_uart.o as the Makefile doesn't pick it up, leading
> to a link error with anything referring to it:
>
> ERROR: "hci_uart_register_device" [drivers/bluetooth/hci_nokia.ko] undefined!
> scripts/Makefile.modpost:91: recipe for target '__modpost' failed
>
> Changing this in the Makefile would cause another problem when
> hci_uart itself is built-in and cannot reference symbols from the
> serdev module.
>
> This tries to address both problems by introducing a new hidden
> Kconfig symbol that controls both the compilation of hci_serdev.o
> and whether the Nokia driver can be selected. This seems to address
> the problem for me, though there might be a better way to do it.
>
> Fixes: 7bb318680e86 ("Bluetooth: add nokia driver")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> drivers/bluetooth/Kconfig | 8 +++++++-
> drivers/bluetooth/Makefile | 2 +-
> 2 files changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/bluetooth/Kconfig b/drivers/bluetooth/Kconfig
> index 8aafbed9e160..737d93ef27c5 100644
> --- a/drivers/bluetooth/Kconfig
> +++ b/drivers/bluetooth/Kconfig
> @@ -76,6 +76,12 @@ config BT_HCIUART
> Say Y here to compile support for Bluetooth UART devices into the
> kernel or say M to compile it as module (hci_uart).
>
> +config BT_HCIUART_SERDEV
> + bool
> + depends on SERIAL_DEV_BUS && BT_HCIUART
> + depends on SERIAL_DEV_BUS=y || SERIAL_DEV_BUS=BT_HCIUART
> + default y
> +
> config BT_HCIUART_H4
> bool "UART (H4) protocol support"
> depends on BT_HCIUART
> @@ -89,7 +95,7 @@ config BT_HCIUART_H4
> config BT_HCIUART_NOKIA
> tristate "UART Nokia H4+ protocol support"
> depends on BT_HCIUART
I guess BT_HCIUART dependency is no longer needed
when we have BT_HCIUART_SERDEV dependency?
Otherwise:
Reviewed-by: Sebastian Reichel <sre@kernel.org>
> - depends on SERIAL_DEV_BUS
> + depends on BT_HCIUART_SERDEV
> depends on PM
> help
> Nokia H4+ is serial protocol for communication between Bluetooth
> diff --git a/drivers/bluetooth/Makefile b/drivers/bluetooth/Makefile
> index a7f237320f4b..e693ca6eeed9 100644
> --- a/drivers/bluetooth/Makefile
> +++ b/drivers/bluetooth/Makefile
> @@ -31,7 +31,7 @@ btmrvl-y := btmrvl_main.o
> btmrvl-$(CONFIG_DEBUG_FS) += btmrvl_debugfs.o
>
> hci_uart-y := hci_ldisc.o
> -hci_uart-$(CONFIG_SERIAL_DEV_BUS) += hci_serdev.o
> +hci_uart-$(CONFIG_BT_HCIUART_SERDEV) += hci_serdev.o
> hci_uart-$(CONFIG_BT_HCIUART_H4) += hci_h4.o
> hci_uart-$(CONFIG_BT_HCIUART_BCSP) += hci_bcsp.o
> hci_uart-$(CONFIG_BT_HCIUART_LL) += hci_ll.o
> --
> 2.9.0
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH] blutooth: try to improve CONFIG_SERIAL_DEV_BUS dependency
From: Marcel Holtmann @ 2017-04-20 6:55 UTC (permalink / raw)
To: Sebastian Reichel
Cc: Arnd Bergmann, Gustavo F. Padovan, Johan Hedberg, Rob Herring,
Bjorn Andersson, David S. Miller, Kalle Valo, linux-bluetooth,
linux-kernel
In-Reply-To: <20170420001534.ecnkaqlk652thya7@earth>
Hi Sebastian,
>> With CONFIG_SERIAL_DEV_BUS=m, the hci_serdev.o file does not actually
>> get built into hci_uart.o as the Makefile doesn't pick it up, leading
>> to a link error with anything referring to it:
>>
>> ERROR: "hci_uart_register_device" [drivers/bluetooth/hci_nokia.ko] undefined!
>> scripts/Makefile.modpost:91: recipe for target '__modpost' failed
>>
>> Changing this in the Makefile would cause another problem when
>> hci_uart itself is built-in and cannot reference symbols from the
>> serdev module.
>>
>> This tries to address both problems by introducing a new hidden
>> Kconfig symbol that controls both the compilation of hci_serdev.o
>> and whether the Nokia driver can be selected. This seems to address
>> the problem for me, though there might be a better way to do it.
>>
>> Fixes: 7bb318680e86 ("Bluetooth: add nokia driver")
>> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>> ---
>> drivers/bluetooth/Kconfig | 8 +++++++-
>> drivers/bluetooth/Makefile | 2 +-
>> 2 files changed, 8 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/bluetooth/Kconfig b/drivers/bluetooth/Kconfig
>> index 8aafbed9e160..737d93ef27c5 100644
>> --- a/drivers/bluetooth/Kconfig
>> +++ b/drivers/bluetooth/Kconfig
>> @@ -76,6 +76,12 @@ config BT_HCIUART
>> Say Y here to compile support for Bluetooth UART devices into the
>> kernel or say M to compile it as module (hci_uart).
>>
>> +config BT_HCIUART_SERDEV
>> + bool
>> + depends on SERIAL_DEV_BUS && BT_HCIUART
>> + depends on SERIAL_DEV_BUS=y || SERIAL_DEV_BUS=BT_HCIUART
>> + default y
>> +
>> config BT_HCIUART_H4
>> bool "UART (H4) protocol support"
>> depends on BT_HCIUART
>> @@ -89,7 +95,7 @@ config BT_HCIUART_H4
>> config BT_HCIUART_NOKIA
>> tristate "UART Nokia H4+ protocol support"
>> depends on BT_HCIUART
>
> I guess BT_HCIUART dependency is no longer needed
> when we have BT_HCIUART_SERDEV dependency?
if so then we need another patch since I already applied the one from Arnd.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH] blutooth: try to improve CONFIG_SERIAL_DEV_BUS dependency
From: Arnd Bergmann @ 2017-04-20 7:02 UTC (permalink / raw)
To: Marcel Holtmann
Cc: Sebastian Reichel, Gustavo F. Padovan, Johan Hedberg, Rob Herring,
Bjorn Andersson, David S. Miller, Kalle Valo, linux-bluetooth,
Linux Kernel Mailing List
In-Reply-To: <C283C351-9806-44B8-A2E5-0B0B377156F9@holtmann.org>
On Thu, Apr 20, 2017 at 8:55 AM, Marcel Holtmann <marcel@holtmann.org> wrote:
> Hi Sebastian,
>
>>> With CONFIG_SERIAL_DEV_BUS=m, the hci_serdev.o file does not actually
>>> get built into hci_uart.o as the Makefile doesn't pick it up, leading
>>> to a link error with anything referring to it:
>>>
>>> ERROR: "hci_uart_register_device" [drivers/bluetooth/hci_nokia.ko] undefined!
>>> scripts/Makefile.modpost:91: recipe for target '__modpost' failed
>>>
>>> Changing this in the Makefile would cause another problem when
>>> hci_uart itself is built-in and cannot reference symbols from the
>>> serdev module.
>>>
>>> This tries to address both problems by introducing a new hidden
>>> Kconfig symbol that controls both the compilation of hci_serdev.o
>>> and whether the Nokia driver can be selected. This seems to address
>>> the problem for me, though there might be a better way to do it.
>>>
>>> Fixes: 7bb318680e86 ("Bluetooth: add nokia driver")
>>> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>>> ---
>>> drivers/bluetooth/Kconfig | 8 +++++++-
>>> drivers/bluetooth/Makefile | 2 +-
>>> 2 files changed, 8 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/bluetooth/Kconfig b/drivers/bluetooth/Kconfig
>>> index 8aafbed9e160..737d93ef27c5 100644
>>> --- a/drivers/bluetooth/Kconfig
>>> +++ b/drivers/bluetooth/Kconfig
>>> @@ -76,6 +76,12 @@ config BT_HCIUART
>>> Say Y here to compile support for Bluetooth UART devices into the
>>> kernel or say M to compile it as module (hci_uart).
>>>
>>> +config BT_HCIUART_SERDEV
>>> + bool
>>> + depends on SERIAL_DEV_BUS && BT_HCIUART
>>> + depends on SERIAL_DEV_BUS=y || SERIAL_DEV_BUS=BT_HCIUART
>>> + default y
>>> +
>>> config BT_HCIUART_H4
>>> bool "UART (H4) protocol support"
>>> depends on BT_HCIUART
>>> @@ -89,7 +95,7 @@ config BT_HCIUART_H4
>>> config BT_HCIUART_NOKIA
>>> tristate "UART Nokia H4+ protocol support"
>>> depends on BT_HCIUART
>>
>> I guess BT_HCIUART dependency is no longer needed
>> when we have BT_HCIUART_SERDEV dependency?
>
> if so then we need another patch since I already applied the one from Arnd.
We need both dependencies: BT_HCIUART_SERDEV is a 'bool'
symbol controlling whether subdrivers are able to use symbols
exported by the serdev code, while BT_HCIUART is a tristate
symbol and we need to depend on that to ensure that
BT_HCIUART_NOKIA cannot be set to '=y' when
BT_HCIUART=m.
No further patch should be needed.
Arnd
^ permalink raw reply
* Re: GATT Server: DBus GATT Services not advertised/exported
From: Luiz Augusto von Dentz @ 2017-04-20 11:31 UTC (permalink / raw)
To: Olivier MARTIN; +Cc: Barry Byford, Bluez mailing list
In-Reply-To: <122bd75a159578eee407a7ff2497fe68@labapart.com>
Hi Oliver,
On Thu, Apr 20, 2017 at 2:20 AM, Olivier MARTIN <olivier@labapart.com> wrote:
> I am back on the thread.
> What I noticed last week when I tried on Android phone with both "BLE
> Scanner" and "Nordic Connect", discovering GATT services is really really
> slow (it takes 2 min to discover all `example-gatt-server` GATT services) on
> Nexus 4 with Android 5.1.1 and Ubuntu 16.04 with Bluez v5.44 for the GATT
> server. I am using the Asus USB-BT400 (Broadcom chipset).
>
> I did more investigation this evening but I have not done any progress.
> I tried with `example-gatt-server` started by the user and root and no
> change in the poor performance.
>
> I do not know what is taking so long but for instance it takes many seconds
> to execute this part:
>
> bluetoothd[12913]: src/device.c:gatt_debug() Read By Type - start: 0x005e
> end: 0x0061
> bluetoothd[12913]: src/device.c:gatt_debug() Read By Type - start: 0x0060
> end: 0x0061
> bluetoothd[12913]: src/device.c:gatt_debug() Find Info - start: 0x0061 end:
> 0x0061
> bluetoothd[12913]: src/device.c:gatt_debug() Read By Type - start: 0x0062
> end: 0x0071
> bluetoothd[12913]: src/device.c:gatt_debug() Read By Type - start: 0x0062
> end: 0x0071
> bluetoothd[12913]: src/device.c:gatt_debug() Read By Type - start: 0x006e
> end: 0x0071
> bluetoothd[12913]: src/device.c:gatt_debug() Find Info - start: 0x0065 end:
> 0x0067
> bluetoothd[12913]: src/device.c:gatt_debug() Find Info - start: 0x0066 end:
> 0x0067
> bluetoothd[12913]: src/device.c:gatt_debug() Find Info - start: 0x0067 end:
> 0x0067
> bluetoothd[12913]: src/device.c:gatt_debug() Find Info - start: 0x006a end:
> 0x006c
> bluetoothd[12913]: src/device.c:gatt_debug() Find Info - start: 0x006b end:
> 0x006c
> bluetoothd[12913]: src/device.c:gatt_debug() Find Info - start: 0x006c end:
> 0x006c
> bluetoothd[12913]: src/device.c:gatt_debug() Find Info - start: 0x006f end:
> 0x0071
> bluetoothd[12913]: src/device.c:gatt_debug() Find Info - start: 0x0070 end:
> 0x0071
> bluetoothd[12913]: src/device.c:gatt_debug() Find Info - start: 0x0071 end:
> 0x0071
> bluetoothd[12913]: src/device.c:gatt_debug() Read By Type - start: 0x0072
> end: 0x0079
> bluetoothd[12913]: src/device.c:gatt_debug() Read By Type - start: 0x0072
> end: 0x0079
> bluetoothd[12913]: src/device.c:gatt_debug() Read By Type - start: 0x0079
> end: 0x0079
> bluetoothd[12913]: src/device.c:gatt_debug() Find Info - start: 0x0077 end:
> 0x0077
You should be able to see their timings in HCI with btmon, or just use
journalctl if are thinking there is a delay in processing the packets
but I think that is not the case. These many Find Info does indeed
looks odd, and there are even repeated range.
>
>
>
> On 14.04.2017 20:31, Barry Byford wrote:
>>
>> Hello Olivier,
>>
>> On 14 April 2017 at 19:14, Olivier MARTIN <olivier@labapart.com> wrote:
>>>
>>> Thanks Barry, setting 'ControllerMode = le' in /etc/bluetooth/main.conf
>>> fixed my issue. I can now see the GATT services.
>>
>>
>> Good news!
>>
>>> But I guess my adapter now only works as BLE adapter and will ignore the
>>> non-LE devices.
>>> In the comment of /etc/bluetooth/main.conf it is written the adapter
>>> should
>>> be by default set as 'dual'.
>>>
>>> Is it a bug in Bluez? Why GATT services are not exposed while using the
>>> default value for 'ControllerMode'?
>>
>>
>> This issue has come up before and was discuss here:
>> http://marc.info/?l=linux-bluetooth&m=146071596012263&w=2
>>
>>
>>
>>
>>> On 14.04.2017 14:30, Barry Byford wrote:
>>>>
>>>>
>>>> Hello Olivier,
>>>>
>>>>
>>>> On 14 April 2017 at 12:01, Olivier MARTIN <olivier@labapart.com> wrote:
>>>>>
>>>>>
>>>>> You are right Barry, `example-advertisement` seems to work well (I
>>>>> installed
>>>>> and tried Nordic nRF Connect and I can see the expected advertisemet
>>>>> data).
>>>>
>>>>
>>>>
>>>> Excellent!
>>>>
>>>>
>>>>> But I cannot still manage to get `example-gatt-server` :-(
>>>>> I am sure I got it working last year with an older version of Bluez.
>>>>> But
>>>>> I
>>>>> cannot make it work with Bluez v5.44.
>>>>
>>>>
>>>>
>>>> OK, I've taken a look at "example-gatt-server" and have it working...
>>>>
>>>>>
>>>>> My testing procedure:
>>>>>
>>>>> 1. [Laptop] First terminal: Start `sudo ./src/bluetoothd -E -n -d`
>>>>> 2. [Laptop] Second terminal: Start unmodified Bluez
>>>>> ./test/example-gatt-server
>>>>> 3. [Laptop] Third terminal: Ensure the adapter is "Powered: yes" and
>>>>> "Discoverable: yes"
>>>>
>>>>
>>>>
>>>> OK, I've done this slightly different (details below). However, the
>>>> first thing I did was edit "/etc/bluetooth/main.conf"
>>>> I added the following line to the end of the file:
>>>>
>>>> ControllerMode = le
>>>>
>>>> Then I did the following:
>>>> 1. [SBC1:T1] sudo ./src/bluetoothd -E -n -d
>>>> 2. [SBC1:T2] ./example-gatt-server
>>>> 3. [SBC1:T3] ./example-advertisement
>>>>
>>>>
>>>>>
>>>>> 4. [Android] Connect using Nordic nRF Connect (I also tried with "BLE
>>>>> Scanner") and check I see the exposed GATT services by
>>>>> `example-gatt-server`
>>>>> Unfortunately, I can only see:
>>>>> - Generic Access Service (0x1800)
>>>>> - Generic Attribute Service (0x1801)
>>>>>
>>>>
>>>> I've used bluetoothctl on SBC2 to connect and read the battery values
>>>> that the GATT server is counting down.
>>>>
>>>> $ bluetoothctl
>>>> [NEW] Controller 00:00:00:00:5A:AD linaro-alip [default]
>>>> [bluetooth]# scan on
>>>> Discovery started
>>>> [CHG] Controller 00:00:00:00:5A:AD Discovering: yes
>>>> [NEW] Device B8:27:EB:22:57:E0 BluezeroLight
>>>> [bluetooth]# scan off
>>>> Discovery stopped
>>>> [CHG] Controller 00:00:00:00:5A:AD Discovering: no
>>>> [bluetooth]# connect B8:27:EB:22:57:E0
>>>> Attempting to connect to B8:27:EB:22:57:E0
>>>> [CHG] Device B8:27:EB:22:57:E0 Connected: yes
>>>> Connection successful
>>>> [...snip...]
>>>> [NEW] Primary Service
>>>> /org/bluez/hci0/dev_B8_27_EB_22_57_E0/service000a
>>>> 0000180f-0000-1000-8000-00805f9b34fb
>>>> Battery Service
>>>> [NEW] Characteristic
>>>> /org/bluez/hci0/dev_B8_27_EB_22_57_E0/service000a/char000b
>>>> 00002a19-0000-1000-8000-00805f9b34fb
>>>> Battery Level
>>>> [...snip...]
>>>> [CHG] Device B8:27:EB:22:57:E0 ServicesResolved: yes
>>>> [BluezeroLight]# select-attribute
>>>> /org/bluez/hci0/dev_B8_27_EB_22_57_E0/service000a/char000b
>>>> [BluezeroLight:/service000a/char000b]# read
>>>> Attempting to read
>>>> /org/bluez/hci0/dev_B8_27_EB_22_57_E0/service000a/char000b
>>>> [CHG] Attribute
>>>> /org/bluez/hci0/dev_B8_27_EB_22_57_E0/service000a/char000b Value: 0x46
>>>> 46 F
>>>> [BluezeroLight:/service000a/char000b]# notify on
>>>> [CHG] Attribute
>>>> /org/bluez/hci0/dev_B8_27_EB_22_57_E0/service000a/char000b Notifying:
>>>> yes
>>>> Notify started
>>>> [CHG] Attribute
>>>> /org/bluez/hci0/dev_B8_27_EB_22_57_E0/service000a/char000b Value: 0x46
>>>> [CHG] Attribute
>>>> /org/bluez/hci0/dev_B8_27_EB_22_57_E0/service000a/char000b Value: 0x44
>>>> [CHG] Attribute
>>>> /org/bluez/hci0/dev_B8_27_EB_22_57_E0/service000a/char000b Value: 0x42
>>>> [CHG] Attribute
>>>> /org/bluez/hci0/dev_B8_27_EB_22_57_E0/service000a/char000b Value: 0x40
>>>> [CHG] Attribute
>>>> /org/bluez/hci0/dev_B8_27_EB_22_57_E0/service000a/char000b Value: 0x3e
>>>> [BluezeroLight:/service000a/char000b]# notify off
>>>> [CHG] Attribute
>>>> /org/bluez/hci0/dev_B8_27_EB_22_57_E0/service000a/char000b Notifying:
>>>> no
>>>> Notify stopped
>>>>
>>>>
>>>> That seems to be working then. When I didn't have "ControllerMode =
>>>> le" set then I did see it be unpredictable if it successfully
>>>> connected or not.
>>>> This also worked connecting with the nRF app.
>>>>
>>>>
>>>> Does that work for you?
>>>>
>>>>
>>>>
>>>>
>>>>> If I had to suspect Bluez code, I will guess there is something missing
>>>>> around here:
>>>>>
>>>>> bluetoothd[20429]: src/device.c:gatt_server_init() # gatt_server_init
>>>>> bluetoothd[20429]: src/device.c:gatt_debug() Primary services found: 2
>>>>> bluetoothd[20429]: src/device.c:gatt_debug() start: 0x0001, end:
>>>>> 0x0005,
>>>>> uuid: 00001801-0000-1000-8000-00805f9b34fb
>>>>> bluetoothd[20429]: src/device.c:gatt_debug() start: 0x0014, end:
>>>>> 0xffff,
>>>>> uuid: 00001800-0000-1000-8000-00805f9b34fb
>>>>> bluetoothd[20429]: src/device.c:gatt_debug() Registered handler for
>>>>> "Service
>>>>> Changed": 0
>>>>> bluetoothd[20429]: src/device.c:gatt_client_ready_cb() status: success,
>>>>> error: 0
>>>>>
>>>>> As Bluez daemon does not get the GATT services from Buez GATT Database.
>>>>> But
>>>>> it might be me who miss a step...
>>>>>
>>>>>
>>>>> On 14.04.2017 12:37, Barry Byford wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> example-advertisementHello Oliver,
>>>>>>
>>>>>>
>>>>>> On 14 April 2017 at 11:03, Olivier MARTIN <olivier@labapart.com>
>>>>>> wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Thanks for replying my message Barry,
>>>>>>>
>>>>>>> Sorry, I forgot to mention but I start Bluez daemon with `sudo
>>>>>>> ./src/bluetoothd -E -n -d` (after stopping the bluetooth service). So
>>>>>>> I
>>>>>>> already run it with sudo and experimental option.
>>>>>>>
>>>>>>> I am not sure to understand what you mean by "this kind of error
>>>>>>> message".
>>>>>>> Because I do not see any error message in the log I provided.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> OK, that was bad on my part. I read it as complaining that there were
>>>>>> too many advertisements. Looking again that wasn't what it was say.
>>>>>> Apologies.
>>>>>>
>>>>>>>
>>>>>>> Any other idea?
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> I am by Linux Single Board Computers (SBC) today so I'm able to run
>>>>>> what you are running and can show you what I'm seeing. I'll focus on
>>>>>> example-advertisement first as example-gatt-server doesn't change the
>>>>>> advertisements.
>>>>>>
>>>>>> I've started the BlueZ daemon with "./src/bluetoothd -E -n -d"
>>>>>>
>>>>>> In another shell when I start "./example-advertisement" I see the
>>>>>> following in the output:
>>>>>>
>>>>>> bluetoothd[2325]: src/adapter.c:property_set_mode() sending Set
>>>>>> Powered command for index 0
>>>>>> bluetoothd[2325]: src/adapter.c:property_set_mode_complete() Success
>>>>>> (0x00)
>>>>>> bluetoothd[2325]: src/adapter.c:new_settings_callback() Settings:
>>>>>> 0x00000ad1
>>>>>> bluetoothd[2325]: src/adapter.c:settings_changed() Changed settings:
>>>>>> 0x00000001
>>>>>> bluetoothd[2325]: src/adapter.c:adapter_start() adapter
>>>>>> /org/bluez/hci0 has been enabled
>>>>>> bluetoothd[2325]: src/adapter.c:trigger_passive_scanning()
>>>>>> bluetoothd[2325]: src/advertising.c:register_advertisement()
>>>>>> RegisterAdvertisement
>>>>>> bluetoothd[2325]: src/advertising.c:client_create() Adding proxy for
>>>>>> /org/bluez/example/advertisement0
>>>>>> bluetoothd[2325]: src/advertising.c:register_advertisement()
>>>>>> Registered advertisement at path /org/bluez/example/advertisement0
>>>>>> bluetoothd[2325]: src/advertising.c:parse_service_uuids() Adding
>>>>>> ServiceUUID: 180D
>>>>>> bluetoothd[2325]: src/advertising.c:parse_service_uuids() Adding
>>>>>> ServiceUUID: 180F
>>>>>> bluetoothd[2325]: src/advertising.c:parse_manufacturer_data() Adding
>>>>>> ManufacturerData for ffff
>>>>>> bluetoothd[2325]: src/advertising.c:parse_service_data() Adding
>>>>>> ServiceData for 9999
>>>>>> bluetoothd[2325]: src/advertising.c:refresh_advertisement() Refreshing
>>>>>> advertisement: /org/bluez/example/advertisement0
>>>>>> bluetoothd[2325]: src/advertising.c:add_adv_callback() Advertisement
>>>>>> registered: /org/bluez/example/advertisement0
>>>>>>
>>>>>>
>>>>>> On a second SBC, at the command line I run "bluetoothctl" and do "scan
>>>>>> on". Once my first SBC is found I do "scan off". I then do "info
>>>>>> B8:27:EB:22:57:E0" (this is the address of the first SBC) which gives
>>>>>> the following output:
>>>>>>
>>>>>> [bluetooth]# info B8:27:EB:22:57:E0
>>>>>> Device B8:27:EB:22:57:E0
>>>>>> Alias: B8-27-EB-22-57-E0
>>>>>> Paired: no
>>>>>> Trusted: no
>>>>>> Blocked: no
>>>>>> Connected: no
>>>>>> LegacyPairing: no
>>>>>> UUID: Heart Rate (0000180d-0000-1000-8000-00805f9b34fb)
>>>>>> UUID: Battery Service (0000180f-0000-1000-8000-00805f9b34fb)
>>>>>> ManufacturerData Key: 0xffff
>>>>>> ManufacturerData Value: 0x00
>>>>>> ManufacturerData Value: 0x01
>>>>>> ManufacturerData Value: 0x02
>>>>>> ManufacturerData Value: 0x03
>>>>>> ManufacturerData Value: 0x04
>>>>>> ServiceData Key: 00009999-0000-1000-8000-00805f9b34fb
>>>>>> ServiceData Value: 0x00
>>>>>> ServiceData Value: 0x01
>>>>>> ServiceData Value: 0x02
>>>>>> ServiceData Value: 0x03
>>>>>> ServiceData Value: 0x04
>>>>>>
>>>>>>
>>>>>> I've also done a scan from my Android phone (using the Nordic nRF
>>>>>> Connect app) and can see the advertisements also (just hard to share
>>>>>> that information on here).
>>>>>>
>>>>>> Does that help?
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 13.04.2017 19:59, Barry Byford wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Hello Olivier,
>>>>>>>>
>>>>>>>>
>>>>>>>> On 13 April 2017 at 12:14, Olivier MARTIN <olivier@labapart.com>
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Hi all,
>>>>>>>>> I am having issue to advertise/export GATT services exposed through
>>>>>>>>> DBus
>>>>>>>>> API. I tried `./test/example-gatt-server`. And I also tried to
>>>>>>>>> merge
>>>>>>>>> `./test/example-advertisement` into `./test/example-gatt-server`.
>>>>>>>>> But
>>>>>>>>> in
>>>>>>>>> both cases I only see the two compulsory GATT services:
>>>>>>>>> - Generic Access Service (0x1800)
>>>>>>>>> - Generic Attribute Service (0x1801)
>>>>>>>>>
>>>>>>>>> I am using Bluez v5.44. And I also tried Bluez v5.37.
>>>>>>>>>
>>>>>>>>> GATT Services seem to be discovered by Bluez (note: I added
>>>>>>>>> additional
>>>>>>>>> debug
>>>>>>>>> statement all prefixed with '#'):
>>>>>>>>>
>>>>>>>>> bluetoothd[16877]: src/gatt-database.c:manager_register_app() #
>>>>>>>>> manager_register_app
>>>>>>>>> bluetoothd[16877]: src/gatt-database.c:create_app() # create_app
>>>>>>>>> bluetoothd[16877]: src/gatt-database.c:manager_register_app()
>>>>>>>>> Registering
>>>>>>>>> application: :1.404:/
>>>>>>>>> bluetoothd[16877]: src/advertising.c:register_advertisement()
>>>>>>>>> RegisterAdvertisement
>>>>>>>>> bluetoothd[16877]: src/advertising.c:client_create() Adding proxy
>>>>>>>>> for
>>>>>>>>> /org/bluez/example/advertisement0
>>>>>>>>> bluetoothd[16877]: src/advertising.c:register_advertisement()
>>>>>>>>> Registered
>>>>>>>>> advertisement at path /org/bluez/example/advertisement0
>>>>>>>>> bluetoothd[16877]: src/gatt-database.c:proxy_added_cb() Object
>>>>>>>>> received:
>>>>>>>>> /org/bluez/example/service0/char2, iface:
>>>>>>>>> org.bluez.GattCharacteristic1
>>>>>>>>> bluetoothd[16877]: src/gatt-database.c:proxy_added_cb() Object
>>>>>>>>> received:
>>>>>>>>> /org/bluez/example/service2/char0/desc0, iface:
>>>>>>>>> org.bluez.GattDescriptor1
>>>>>>>>> bluetoothd[16877]: src/gatt-database.c:proxy_added_cb() Object
>>>>>>>>> received:
>>>>>>>>> /org/bluez/example/service2/char2/desc3, iface:
>>>>>>>>> org.bluez.GattDescriptor1
>>>>>>>>> bluetoothd[16877]: src/gatt-database.c:proxy_added_cb() Object
>>>>>>>>> received:
>>>>>>>>> /org/bluez/example/service2/char2, iface:
>>>>>>>>> org.bluez.GattCharacteristic1
>>>>>>>>> bluetoothd[16877]: src/gatt-database.c:proxy_added_cb() Object
>>>>>>>>> received:
>>>>>>>>> /org/bluez/example/service1/char0, iface:
>>>>>>>>> org.bluez.GattCharacteristic1
>>>>>>>>> bluetoothd[16877]: src/gatt-database.c:proxy_added_cb() Object
>>>>>>>>> received:
>>>>>>>>> /org/bluez/example/service2/char1, iface:
>>>>>>>>> org.bluez.GattCharacteristic1
>>>>>>>>> bluetoothd[16877]: src/gatt-database.c:proxy_added_cb() Object
>>>>>>>>> received:
>>>>>>>>> /org/bluez/example/service0/char1, iface:
>>>>>>>>> org.bluez.GattCharacteristic1
>>>>>>>>> bluetoothd[16877]: src/gatt-database.c:proxy_added_cb() Object
>>>>>>>>> received:
>>>>>>>>> /org/bluez/example/service2/char1/desc3, iface:
>>>>>>>>> org.bluez.GattDescriptor1
>>>>>>>>> bluetoothd[16877]: src/gatt-database.c:proxy_added_cb() Object
>>>>>>>>> received:
>>>>>>>>> /org/bluez/example/service2/char1/desc2, iface:
>>>>>>>>> org.bluez.GattDescriptor1
>>>>>>>>> bluetoothd[16877]: src/gatt-database.c:proxy_added_cb() Object
>>>>>>>>> received:
>>>>>>>>> /org/bluez/example/service0/char0, iface:
>>>>>>>>> org.bluez.GattCharacteristic1
>>>>>>>>> bluetoothd[16877]: src/gatt-database.c:proxy_added_cb() Object
>>>>>>>>> received:
>>>>>>>>> /org/bluez/example/service2, iface: org.bluez.GattService1
>>>>>>>>> bluetoothd[16877]: src/gatt-database.c:proxy_added_cb() Object
>>>>>>>>> received:
>>>>>>>>> /org/bluez/example/service1, iface: org.bluez.GattService1
>>>>>>>>> bluetoothd[16877]: src/gatt-database.c:proxy_added_cb() Object
>>>>>>>>> received:
>>>>>>>>> /org/bluez/example/service0, iface: org.bluez.GattService1
>>>>>>>>> bluetoothd[16877]: src/gatt-database.c:proxy_added_cb() Object
>>>>>>>>> received:
>>>>>>>>> /org/bluez/example/service2/char0/desc1, iface:
>>>>>>>>> org.bluez.GattDescriptor1
>>>>>>>>> bluetoothd[16877]: src/gatt-database.c:proxy_added_cb() Object
>>>>>>>>> received:
>>>>>>>>> /org/bluez/example/service2/char2/desc2, iface:
>>>>>>>>> org.bluez.GattDescriptor1
>>>>>>>>> bluetoothd[16877]: src/gatt-database.c:proxy_added_cb() Object
>>>>>>>>> received:
>>>>>>>>> /org/bluez/example/service2/char0, iface:
>>>>>>>>> org.bluez.GattCharacteristic1
>>>>>>>>> bluetoothd[16877]: src/gatt-database.c:client_ready_cb() #
>>>>>>>>> client_ready_cb
>>>>>>>>> bluetoothd[16877]: src/gatt-database.c:create_service() #
>>>>>>>>> create_service
>>>>>>>>> from /org/bluez/example/service2
>>>>>>>>> bluetoothd[16877]: src/gatt-database.c:create_service() #
>>>>>>>>> create_service
>>>>>>>>> from /org/bluez/example/service1
>>>>>>>>> bluetoothd[16877]: src/gatt-database.c:create_service() #
>>>>>>>>> create_service
>>>>>>>>> from /org/bluez/example/service0
>>>>>>>>> bluetoothd[16877]: src/gatt-database.c:database_add_app() #
>>>>>>>>> database_add_app
>>>>>>>>> bluetoothd[16877]: src/gatt-database.c:database_add_service() #
>>>>>>>>> database_add_service
>>>>>>>>> bluetoothd[16877]: src/gatt-database.c:cep_write_cb() Stored CEP
>>>>>>>>> value
>>>>>>>>> in
>>>>>>>>> the database
>>>>>>>>> bluetoothd[16877]: src/gatt-database.c:database_add_cep() Created
>>>>>>>>> CEP
>>>>>>>>> entry
>>>>>>>>> for characteristic
>>>>>>>>> bluetoothd[16877]: src/gatt-database.c:cep_write_cb() Stored CEP
>>>>>>>>> value
>>>>>>>>> in
>>>>>>>>> the database
>>>>>>>>> bluetoothd[16877]: src/gatt-database.c:database_add_cep() Created
>>>>>>>>> CEP
>>>>>>>>> entry
>>>>>>>>> for characteristic
>>>>>>>>> bluetoothd[16877]: src/gatt-database.c:cep_write_cb() Stored CEP
>>>>>>>>> value
>>>>>>>>> in
>>>>>>>>> the database
>>>>>>>>> bluetoothd[16877]: src/gatt-database.c:database_add_cep() Created
>>>>>>>>> CEP
>>>>>>>>> entry
>>>>>>>>> for characteristic
>>>>>>>>> bluetoothd[16877]: src/gatt-database.c:gatt_db_service_added() #
>>>>>>>>> gatt_db_service_added: GATT Service added to local database
>>>>>>>>> bluetoothd[16877]: src/gatt-database.c:database_add_service() #
>>>>>>>>> database_add_service
>>>>>>>>> bluetoothd[16877]: src/gatt-database.c:database_add_ccc() Created
>>>>>>>>> CCC
>>>>>>>>> entry
>>>>>>>>> for characteristic
>>>>>>>>> bluetoothd[16877]: src/gatt-database.c:gatt_db_service_added() #
>>>>>>>>> gatt_db_service_added: GATT Service added to local database
>>>>>>>>> bluetoothd[16877]: src/gatt-database.c:database_add_service() #
>>>>>>>>> database_add_service
>>>>>>>>> bluetoothd[16877]: src/gatt-database.c:database_add_ccc() Created
>>>>>>>>> CCC
>>>>>>>>> entry
>>>>>>>>> for characteristic
>>>>>>>>> bluetoothd[16877]: src/gatt-database.c:gatt_db_service_added() #
>>>>>>>>> gatt_db_service_added: GATT Service added to local database
>>>>>>>>> bluetoothd[16877]: src/gatt-database.c:client_ready_cb() GATT
>>>>>>>>> application
>>>>>>>>> registered: :1.404:/
>>>>>>>>> bluetoothd[16877]: src/advertising.c:parse_service_uuids() Adding
>>>>>>>>> ServiceUUID: 180D
>>>>>>>>> bluetoothd[16877]: src/advertising.c:parse_service_uuids() Adding
>>>>>>>>> ServiceUUID: 180F
>>>>>>>>> bluetoothd[16877]: src/advertising.c:parse_manufacturer_data()
>>>>>>>>> Adding
>>>>>>>>> ManufacturerData for ffff
>>>>>>>>> bluetoothd[16877]: src/advertising.c:parse_service_data() Adding
>>>>>>>>> ServiceData
>>>>>>>>> for 9999
>>>>>>>>> bluetoothd[16877]: src/advertising.c:refresh_advertisement()
>>>>>>>>> Refreshing
>>>>>>>>> advertisement: /org/bluez/example/advertisement0
>>>>>>>>> bluetoothd[16877]: src/advertising.c:add_adv_callback()
>>>>>>>>> Advertisement
>>>>>>>>> registered: /org/bluez/example/advertisement0
>>>>>>>>>
>>>>>>>>> I start `./test/example-gatt-server` as a normal user. But Bluez
>>>>>>>>> does
>>>>>>>>> not
>>>>>>>>> seem to have any permission issue with it.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Building from source I've seen something similar if I've used sudo
>>>>>>>> for
>>>>>>>> the
>>>>>>>> make.
>>>>>>>>
>>>>>>>> To compile and install I use sudo for the install only:
>>>>>>>>
>>>>>>>> make -j 4 && sudo make install
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> I am using 'BLE scanner' on Android to discover the GATT services.
>>>>>>>>> But
>>>>>>>>> I
>>>>>>>>> think the problem is coming from Bluez. When I connect the Android
>>>>>>>>> device
>>>>>>>>> to
>>>>>>>>> Bluez, I can see this log:
>>>>>>>>>
>>>>>>>>> bluetoothd[16877]: src/adapter.c:connected_callback() hci0 device
>>>>>>>>> 98:D6:F7:31:7B:0D connected eir_len 14
>>>>>>>>> bluetoothd[16877]: src/gatt-database.c:connect_cb() New incoming
>>>>>>>>> BR/EDR
>>>>>>>>> ATT
>>>>>>>>> connection
>>>>>>>>> bluetoothd[16877]: attrib/gattrib.c:g_attrib_ref() 0x98cd908:
>>>>>>>>> g_attrib_ref=1
>>>>>>>>> bluetoothd[16877]: src/device.c:load_gatt_db() # load_gatt_db:
>>>>>>>>> Restoring
>>>>>>>>> 98:D6:F7:31:7B:0D gatt database from file
>>>>>>>>> '/var/lib/bluetooth/5C:F3:70:6A:D9:3C/cache/98:D6:F7:31:7B:0D'
>>>>>>>>> bluetoothd[16877]: src/device.c:load_gatt_db_impl() #
>>>>>>>>> load_gatt_db_impl
>>>>>>>>> bluetoothd[16877]: src/device.c:load_service() # load_service:
>>>>>>>>> loading
>>>>>>>>> service: 0x0001, end: 0x0005, uuid:
>>>>>>>>> 00001801-0000-1000-8000-00805f9b34fb
>>>>>>>>> bluetoothd[16877]: src/device.c:load_service() # load_service:
>>>>>>>>> loading
>>>>>>>>> service: 0x0014, end: 0xffff, uuid:
>>>>>>>>> 00001800-0000-1000-8000-00805f9b34fb
>>>>>>>>> bluetoothd[16877]: src/device.c:load_chrc() loading characteristic
>>>>>>>>> handle:
>>>>>>>>> 0x0002, value handle: 0x0003, properties 0x0020 uuid:
>>>>>>>>> 00002a05-0000-1000-8000-00805f9b34fb
>>>>>>>>> bluetoothd[16877]: src/device.c:load_chrc() loading characteristic
>>>>>>>>> handle:
>>>>>>>>> 0x0015, value handle: 0x0016, properties 0x0002 uuid:
>>>>>>>>> 00002a00-0000-1000-8000-00805f9b34fb
>>>>>>>>> bluetoothd[16877]: src/device.c:load_chrc() loading characteristic
>>>>>>>>> handle:
>>>>>>>>> 0x0017, value handle: 0x0018, properties 0x0002 uuid:
>>>>>>>>> 00002a01-0000-1000-8000-00805f9b34fb
>>>>>>>>> bluetoothd[16877]: src/device.c:load_gatt_db() List GATT Primaries
>>>>>>>>> before
>>>>>>>>> being free:
>>>>>>>>> bluetoothd[16877]: src/device.c:print_primary() - Primary UUID:
>>>>>>>>> 00001801-0000-1000-8000-00805f9b34fb
>>>>>>>>> bluetoothd[16877]: src/device.c:print_primary() - Primary UUID:
>>>>>>>>> 00001800-0000-1000-8000-00805f9b34fb
>>>>>>>>> bluetoothd[16877]: src/device.c:add_primary() # add_primary
>>>>>>>>> bluetoothd[16877]: src/device.c:add_primary() # add_primary
>>>>>>>>> bluetoothd[16877]: profiles/gap/gas.c:gap_accept() GAP profile
>>>>>>>>> accept
>>>>>>>>> (98:D6:F7:31:7B:0D)
>>>>>>>>> bluetoothd[16877]: src/service.c:change_state() 0x98c98e0: device
>>>>>>>>> 98:D6:F7:31:7B:0D profile gap-profile state changed: disconnected
>>>>>>>>> ->
>>>>>>>>> connected (0)
>>>>>>>>> bluetoothd[16877]: src/gatt-client.c:btd_gatt_client_connected()
>>>>>>>>> Device
>>>>>>>>> connected.
>>>>>>>>> bluetoothd[16877]: src/device.c:gatt_server_init() #
>>>>>>>>> gatt_server_init
>>>>>>>>> bluetoothd[16877]: src/device.c:gatt_debug() Primary services
>>>>>>>>> found:
>>>>>>>>> 2
>>>>>>>>> bluetoothd[16877]: src/device.c:gatt_debug() start: 0x0001, end:
>>>>>>>>> 0x0005,
>>>>>>>>> uuid: 00001801-0000-1000-8000-00805f9b34fb
>>>>>>>>> bluetoothd[16877]: src/device.c:gatt_debug() start: 0x0014, end:
>>>>>>>>> 0xffff,
>>>>>>>>> uuid: 00001800-0000-1000-8000-00805f9b34fb
>>>>>>>>> bluetoothd[16877]: src/device.c:gatt_debug() Registered handler for
>>>>>>>>> "Service
>>>>>>>>> Changed": 0
>>>>>>>>> bluetoothd[16877]: src/device.c:gatt_client_ready_cb() status:
>>>>>>>>> success,
>>>>>>>>> error: 0
>>>>>>>>> bluetoothd[16877]: src/device.c:register_gatt_services() #
>>>>>>>>> register_gatt_services
>>>>>>>>> bluetoothd[16877]: src/device.c:add_primary() # add_primary
>>>>>>>>> bluetoothd[16877]: src/device.c:add_primary() # add_primary
>>>>>>>>> bluetoothd[16877]: src/device.c:add_gatt_service() #
>>>>>>>>> add_gatt_service:
>>>>>>>>> UUID:00001801-0000-1000-8000-00805f9b34fb
>>>>>>>>> bluetoothd[16877]: src/gatt-client.c:btd_gatt_client_ready() GATT
>>>>>>>>> client
>>>>>>>>> ready
>>>>>>>>> bluetoothd[16877]: src/gatt-client.c:create_services() Exporting
>>>>>>>>> objects
>>>>>>>>> for
>>>>>>>>> GATT services: 98:D6:F7:31:7B:0D
>>>>>>>>> bluetoothd[16877]: src/gatt-client.c:service_create() Exported GATT
>>>>>>>>> service:
>>>>>>>>> /org/bluez/hci0/dev_98_D6_F7_31_7B_0D/service0001
>>>>>>>>> bluetoothd[16877]: src/gatt-client.c:characteristic_create()
>>>>>>>>> Exported
>>>>>>>>> GATT
>>>>>>>>> characteristic:
>>>>>>>>> /org/bluez/hci0/dev_98_D6_F7_31_7B_0D/service0001/char0002
>>>>>>>>> bluetoothd[16877]: src/device.c:device_svc_resolved()
>>>>>>>>> /org/bluez/hci0/dev_98_D6_F7_31_7B_0D err 0
>>>>>>>>> bluetoothd[16877]: src/device.c:store_gatt_db() # store_gatt_db
>>>>>>>>> bluetoothd[16877]: src/device.c:store_service() # store_service
>>>>>>>>> bluetoothd[16877]: src/device.c:store_service() # store_service
>>>>>>>>> bluetoothd[16877]: profiles/gap/gas.c:read_device_name_cb() GAP
>>>>>>>>> Device
>>>>>>>>> Name:
>>>>>>>>> Nexus 4
>>>>>>>>> bluetoothd[16877]: profiles/gap/gas.c:read_appearance_cb() GAP
>>>>>>>>> Appearance:
>>>>>>>>> 0x0000
>>>>>>>>>
>>>>>>>>> I also reduced DBus 'TestAdvertisement' interface to only expose
>>>>>>>>> one
>>>>>>>>> GATT
>>>>>>>>> Service as many BLE adapter got a limitation in the size of the
>>>>>>>>> advertisement packet:
>>>>>>>>> class TestAdvertisement(Advertisement):
>>>>>>>>>
>>>>>>>>> def __init__(self, bus, index):
>>>>>>>>> Advertisement.__init__(self, bus, index, 'peripheral')
>>>>>>>>> #self.add_service_uuid('180D') # HeartRate
>>>>>>>>> self.add_service_uuid('180F') # Battery
>>>>>>>>> #self.add_manufacturer_data(0xffff, [0x00, 0x01, 0x02,
>>>>>>>>> 0x03,
>>>>>>>>> 0x04])
>>>>>>>>> #self.add_service_data('9999', [0x00, 0x01, 0x02, 0x03,
>>>>>>>>> 0x04])
>>>>>>>>> self.include_tx_power = True
>>>>>>>>>
>>>>>>>>> My concern is mainly these lines:
>>>>>>>>>
>>>>>>>>> bluetoothd[16877]: src/device.c:gatt_debug() Primary services
>>>>>>>>> found:
>>>>>>>>> 2
>>>>>>>>> bluetoothd[16877]: src/device.c:gatt_debug() start: 0x0001, end:
>>>>>>>>> 0x0005,
>>>>>>>>> uuid: 00001801-0000-1000-8000-00805f9b34fb
>>>>>>>>> bluetoothd[16877]: src/device.c:gatt_debug() start: 0x0014, end:
>>>>>>>>> 0xffff,
>>>>>>>>> uuid: 00001800-0000-1000-8000-00805f9b34fb
>>>>>>>>>
>>>>>>>>
>>>>>>>> I've seen this kind of error message when I've had a failure of a
>>>>>>>> previous script and the Bluetooth daemon is in some unknown state.
>>>>>>>> At
>>>>>>>> this point it is worth restarting the bluetooth service with:
>>>>>>>> sudo service bluetooth restart
>>>>>>>>
>>>>>>>> You will see in the advertising DBus API documentation that it is
>>>>>>>> still in experimental mode in 5.44.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/doc/advertising-api.txt#n78
>>>>>>>>
>>>>>>>> This means that you need to make sure bluetoothd is started in
>>>>>>>> experimental mode. Have you done this?
>>>>>>>> You can check with "sudo service bluetooth status"
>>>>>>>>
>>>>>>>> Experimental can be switched on by default in the bluetooth.service
>>>>>>>> file
>>>>>>>>
>>>>>>>> Edit /lib/systemd/system/bluetooth.service file to add
>>>>>>>> --experimental
>>>>>>>> flag
>>>>>>>> e.g:
>>>>>>>>
>>>>>>>> sudo sed -i '/^ExecStart.*bluetoothd\s*$/ s/$/ --experimental/'
>>>>>>>> /lib/systemd/system/bluetooth.service
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> I have not found the code that export GATT Services from GATT
>>>>>>>>> Database
>>>>>>>>> to
>>>>>>>>> the BLE central.
>>>>>>>>>
>>>>>>>>> From my search on Internet, it looks I am not the only one who is
>>>>>>>>> having
>>>>>>>>> this issue
>>>>>>>>> I am happy to share/test anything that could help to make some
>>>>>>>>> progress.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Olivier
>>>>>>>>> --
>>>>>>>>> To unsubscribe from this list: send the line "unsubscribe
>>>>>>>>> linux-bluetooth"
>>>>>>>>> in
>>>>>>>>> the body of a message to majordomo@vger.kernel.org
>>>>>>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth"
> in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Luiz Augusto von Dentz
^ permalink raw reply
* [PATCH BlueZ 1/3] monitor: Add frame number support
From: Luiz Augusto von Dentz @ 2017-04-20 12:32 UTC (permalink / raw)
To: linux-bluetooth
From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
This adds -f/--frames options which can be used to show the frame
number:
> HCI Event: Command Complete (0x0e) plen 4 #86 [hci1] 13:00:02.639412
LE Set Scan Parameters (0x08|0x000b) ncmd 1
Status: Success (0x00)
< HCI Command: LE Set Scan Enable (0x08|0x000c) plen 2 #87 [hci1] 13:00:02.639663
Scanning: Enabled (0x01)
Filter duplicates: Enabled (0x01)
> HCI Event: Command Complete (0x0e) plen 4 #88 [hci1] 13:00:02.640420
LE Set Scan Enable (0x08|0x000c) ncmd 2
Status: Success (0x00)
---
monitor/main.c | 7 ++++++-
monitor/packet.c | 37 +++++++++++++++++++++++++++----------
monitor/packet.h | 1 +
3 files changed, 34 insertions(+), 11 deletions(-)
diff --git a/monitor/main.c b/monitor/main.c
index f9bca22..e1a2375 100644
--- a/monitor/main.c
+++ b/monitor/main.c
@@ -70,6 +70,7 @@ static void usage(void)
"\t-T, --date Show time and date information\n"
"\t-S, --sco Dump SCO traffic\n"
"\t-E, --ellisys [ip] Send Ellisys HCI Injection\n"
+ "\t-f, --frames Show frame counter\n"
"\t-h, --help Show help options\n");
}
@@ -86,6 +87,7 @@ static const struct option main_options[] = {
{ "date", no_argument, NULL, 'T' },
{ "sco", no_argument, NULL, 'S' },
{ "ellisys", required_argument, NULL, 'E' },
+ { "frames", no_argument, NULL, 'f' },
{ "todo", no_argument, NULL, '#' },
{ "version", no_argument, NULL, 'v' },
{ "help", no_argument, NULL, 'h' },
@@ -113,7 +115,7 @@ int main(int argc, char *argv[])
for (;;) {
int opt;
- opt = getopt_long(argc, argv, "d:r:w:a:s:p:i:tTSE:vh",
+ opt = getopt_long(argc, argv, "d:r:w:a:s:p:i:tfTSE:vh",
main_options, NULL);
if (opt < 0)
break;
@@ -171,6 +173,9 @@ int main(int argc, char *argv[])
ellisys_server = optarg;
ellisys_port = 24352;
break;
+ case 'f':
+ filter_mask |= PACKET_FILTER_SHOW_FRAME;
+ break;
case '#':
packet_todo();
lmp_todo();
diff --git a/monitor/packet.c b/monitor/packet.c
index 3c43356..e5f2a32 100644
--- a/monitor/packet.c
+++ b/monitor/packet.c
@@ -58,6 +58,7 @@
#include "packet.h"
#define COLOR_CHANNEL_LABEL COLOR_WHITE
+#define COLOR_FRAME_LABEL COLOR_WHITE
#define COLOR_INDEX_LABEL COLOR_WHITE
#define COLOR_TIMESTAMP COLOR_YELLOW
@@ -259,6 +260,18 @@ void packet_select_index(uint16_t index)
#define print_space(x) printf("%*c", (x), ' ');
+#define MAX_INDEX 16
+
+struct index_data {
+ uint8_t type;
+ uint8_t bdaddr[6];
+ uint16_t manufacturer;
+ size_t frame;
+};
+
+static struct index_data index_list[MAX_INDEX];
+
+
static void print_packet(struct timeval *tv, struct ucred *cred, char ident,
uint16_t index, const char *channel,
const char *color, const char *label,
@@ -280,6 +293,20 @@ static void print_packet(struct timeval *tv, struct ucred *cred, char ident,
ts_pos += n;
ts_len += n;
}
+ } else if (filter_mask & PACKET_FILTER_SHOW_FRAME &&
+ (ident == '<' || ident == '>')) {
+ if (use_color()) {
+ n = sprintf(ts_str + ts_pos, "%s", COLOR_FRAME_LABEL);
+ if (n > 0)
+ ts_pos += n;
+ }
+
+ n = sprintf(ts_str + ts_pos, " #%zu",
+ ++index_list[index].frame);
+ if (n > 0) {
+ ts_pos += n;
+ ts_len += n;
+ }
}
if ((filter_mask & PACKET_FILTER_SHOW_INDEX) &&
@@ -3828,16 +3855,6 @@ static int addr2str(const uint8_t *addr, char *str)
addr[5], addr[4], addr[3], addr[2], addr[1], addr[0]);
}
-#define MAX_INDEX 16
-
-struct index_data {
- uint8_t type;
- uint8_t bdaddr[6];
- uint16_t manufacturer;
-};
-
-static struct index_data index_list[MAX_INDEX];
-
void packet_monitor(struct timeval *tv, struct ucred *cred,
uint16_t index, uint16_t opcode,
const void *data, uint16_t size)
diff --git a/monitor/packet.h b/monitor/packet.h
index 354f4fe..2516ec1 100644
--- a/monitor/packet.h
+++ b/monitor/packet.h
@@ -33,6 +33,7 @@
#define PACKET_FILTER_SHOW_TIME_OFFSET (1 << 3)
#define PACKET_FILTER_SHOW_ACL_DATA (1 << 4)
#define PACKET_FILTER_SHOW_SCO_DATA (1 << 5)
+#define PACKET_FILTER_SHOW_FRAME (1 << 6)
void packet_set_filter(unsigned long filter);
void packet_add_filter(unsigned long filter);
--
2.9.3
^ permalink raw reply related
* [PATCH BlueZ 2/3] monitor: Fix not decoding control frames
From: Luiz Augusto von Dentz @ 2017-04-20 12:32 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <20170420123233.8747-1-luiz.dentz@gmail.com>
From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
In order to enable decoding control frames packet_monitor needs to check
if the index is set to HCI_DEV_NONE since that will call packet_ctrl_open
which setups the ctrl and assign it a cookie.
---
monitor/packet.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/monitor/packet.c b/monitor/packet.c
index e5f2a32..b14a82d 100644
--- a/monitor/packet.c
+++ b/monitor/packet.c
@@ -3866,10 +3866,11 @@ void packet_monitor(struct timeval *tv, struct ucred *cred,
uint16_t manufacturer;
const char *ident;
- if (index_filter && index_number != index)
- return;
-
- index_current = index;
+ if (index != HCI_DEV_NONE) {
+ if (index_filter && index_number != index)
+ return;
+ index_current = index;
+ }
if (tv && time_offset == ((time_t) -1))
time_offset = tv->tv_sec;
--
2.9.3
^ permalink raw reply related
* [PATCH BlueZ 3/3] client: Always start an agent
From: Luiz Augusto von Dentz @ 2017-04-20 12:32 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <20170420123233.8747-1-luiz.dentz@gmail.com>
From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Always register agent with 'KeyboardDisplay' capability.
---
client/main.c | 18 ++++--------------
1 file changed, 4 insertions(+), 14 deletions(-)
diff --git a/client/main.c b/client/main.c
index 8c9d5c3..7043081 100644
--- a/client/main.c
+++ b/client/main.c
@@ -54,6 +54,8 @@
#define PROMPT_ON COLOR_BLUE "[bluetooth]" COLOR_OFF "# "
#define PROMPT_OFF "Waiting to connect to bluetoothd..."
+#define AGENT_CAP "KeyboardDisplay"
+
static GMainLoop *main_loop;
static DBusConnection *dbus_conn;
@@ -2352,23 +2354,9 @@ static guint setup_signalfd(void)
static gboolean option_version = FALSE;
-static gboolean parse_agent(const char *key, const char *value,
- gpointer user_data, GError **error)
-{
- if (value)
- auto_register_agent = g_strdup(value);
- else
- auto_register_agent = g_strdup("");
-
- return TRUE;
-}
-
static GOptionEntry options[] = {
{ "version", 'v', 0, G_OPTION_ARG_NONE, &option_version,
"Show version information and exit" },
- { "agent", 'a', G_OPTION_FLAG_OPTIONAL_ARG,
- G_OPTION_ARG_CALLBACK, parse_agent,
- "Register agent handler", "CAPABILITY" },
{ NULL },
};
@@ -2399,6 +2387,8 @@ int main(int argc, char *argv[])
g_option_context_free(context);
+ auto_register_agent = g_strdup(AGENT_CAP);
+
if (option_version == TRUE) {
printf("%s\n", VERSION);
exit(0);
--
2.9.3
^ permalink raw reply related
* Re: [PATCH BlueZ 3/3] client: Always start an agent
From: Marcel Holtmann @ 2017-04-20 12:52 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: linux-bluetooth
In-Reply-To: <20170420123233.8747-3-luiz.dentz@gmail.com>
Hi Luiz,
> Always register agent with 'KeyboardDisplay' capability.
> ---
> client/main.c | 18 ++++--------------
> 1 file changed, 4 insertions(+), 14 deletions(-)
>
> diff --git a/client/main.c b/client/main.c
> index 8c9d5c3..7043081 100644
> --- a/client/main.c
> +++ b/client/main.c
> @@ -54,6 +54,8 @@
> #define PROMPT_ON COLOR_BLUE "[bluetooth]" COLOR_OFF "# "
> #define PROMPT_OFF "Waiting to connect to bluetoothd..."
>
> +#define AGENT_CAP "KeyboardDisplay"
> +
> static GMainLoop *main_loop;
> static DBusConnection *dbus_conn;
>
> @@ -2352,23 +2354,9 @@ static guint setup_signalfd(void)
>
> static gboolean option_version = FALSE;
>
> -static gboolean parse_agent(const char *key, const char *value,
> - gpointer user_data, GError **error)
> -{
> - if (value)
> - auto_register_agent = g_strdup(value);
> - else
> - auto_register_agent = g_strdup("");
> -
> - return TRUE;
> -}
> -
> static GOptionEntry options[] = {
> { "version", 'v', 0, G_OPTION_ARG_NONE, &option_version,
> "Show version information and exit" },
> - { "agent", 'a', G_OPTION_FLAG_OPTIONAL_ARG,
> - G_OPTION_ARG_CALLBACK, parse_agent,
> - "Register agent handler", "CAPABILITY" },
> { NULL },
> };
actually leave the agent option and make the argument mandatory. We should be registering with “” as agent string by default. That ensures that we use the defaults from bluetoothd and mgmt. However the command line option can overwrite the IO capability.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH BlueZ 1/3] monitor: Add frame number support
From: Marcel Holtmann @ 2017-04-20 12:57 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: linux-bluetooth
In-Reply-To: <20170420123233.8747-1-luiz.dentz@gmail.com>
Hi Luiz,
> This adds -f/--frames options which can be used to show the frame
> number:
>
>> HCI Event: Command Complete (0x0e) plen 4 #86 [hci1] 13:00:02.639412
> LE Set Scan Parameters (0x08|0x000b) ncmd 1
> Status: Success (0x00)
> < HCI Command: LE Set Scan Enable (0x08|0x000c) plen 2 #87 [hci1] 13:00:02.639663
> Scanning: Enabled (0x01)
> Filter duplicates: Enabled (0x01)
>> HCI Event: Command Complete (0x0e) plen 4 #88 [hci1] 13:00:02.640420
> LE Set Scan Enable (0x08|0x000c) ncmd 2
> Status: Success (0x00)
> ---
> monitor/main.c | 7 ++++++-
> monitor/packet.c | 37 +++++++++++++++++++++++++++----------
> monitor/packet.h | 1 +
> 3 files changed, 34 insertions(+), 11 deletions(-)
>
> diff --git a/monitor/main.c b/monitor/main.c
> index f9bca22..e1a2375 100644
> --- a/monitor/main.c
> +++ b/monitor/main.c
> @@ -70,6 +70,7 @@ static void usage(void)
> "\t-T, --date Show time and date information\n"
> "\t-S, --sco Dump SCO traffic\n"
> "\t-E, --ellisys [ip] Send Ellisys HCI Injection\n"
> + "\t-f, --frames Show frame counter\n"
> "\t-h, --help Show help options\n");
> }
I would rather use -C / --counter as frame counter.
> @@ -86,6 +87,7 @@ static const struct option main_options[] = {
> { "date", no_argument, NULL, 'T' },
> { "sco", no_argument, NULL, 'S' },
> { "ellisys", required_argument, NULL, 'E' },
> + { "frames", no_argument, NULL, 'f' },
> { "todo", no_argument, NULL, '#' },
> { "version", no_argument, NULL, 'v' },
> { "help", no_argument, NULL, 'h' },
> @@ -113,7 +115,7 @@ int main(int argc, char *argv[])
> for (;;) {
> int opt;
>
> - opt = getopt_long(argc, argv, "d:r:w:a:s:p:i:tTSE:vh",
> + opt = getopt_long(argc, argv, "d:r:w:a:s:p:i:tfTSE:vh",
> main_options, NULL);
> if (opt < 0)
> break;
> @@ -171,6 +173,9 @@ int main(int argc, char *argv[])
> ellisys_server = optarg;
> ellisys_port = 24352;
> break;
> + case 'f':
> + filter_mask |= PACKET_FILTER_SHOW_FRAME;
> + break;
> case '#':
> packet_todo();
> lmp_todo();
> diff --git a/monitor/packet.c b/monitor/packet.c
> index 3c43356..e5f2a32 100644
> --- a/monitor/packet.c
> +++ b/monitor/packet.c
> @@ -58,6 +58,7 @@
> #include "packet.h"
>
> #define COLOR_CHANNEL_LABEL COLOR_WHITE
> +#define COLOR_FRAME_LABEL COLOR_WHITE
> #define COLOR_INDEX_LABEL COLOR_WHITE
> #define COLOR_TIMESTAMP COLOR_YELLOW
>
> @@ -259,6 +260,18 @@ void packet_select_index(uint16_t index)
>
> #define print_space(x) printf("%*c", (x), ' ');
>
> +#define MAX_INDEX 16
> +
> +struct index_data {
> + uint8_t type;
> + uint8_t bdaddr[6];
> + uint16_t manufacturer;
> + size_t frame;
> +};
> +
> +static struct index_data index_list[MAX_INDEX];
> +
> +
Too many empty lines here.
> static void print_packet(struct timeval *tv, struct ucred *cred, char ident,
> uint16_t index, const char *channel,
> const char *color, const char *label,
> @@ -280,6 +293,20 @@ static void print_packet(struct timeval *tv, struct ucred *cred, char ident,
> ts_pos += n;
> ts_len += n;
> }
> + } else if (filter_mask & PACKET_FILTER_SHOW_FRAME &&
> + (ident == '<' || ident == '>')) {
Lets not use the ident to choose here.
> + if (use_color()) {
> + n = sprintf(ts_str + ts_pos, "%s", COLOR_FRAME_LABEL);
> + if (n > 0)
> + ts_pos += n;
> + }
> +
> + n = sprintf(ts_str + ts_pos, " #%zu",
> + ++index_list[index].frame);
I would prefer if we add the frame number during input and not during display of the packet. That should be kept separate. Otherwise we create a mess like in hcidump.
> + if (n > 0) {
> + ts_pos += n;
> + ts_len += n;
> + }
> }
>
> if ((filter_mask & PACKET_FILTER_SHOW_INDEX) &&
> @@ -3828,16 +3855,6 @@ static int addr2str(const uint8_t *addr, char *str)
> addr[5], addr[4], addr[3], addr[2], addr[1], addr[0]);
> }
>
> -#define MAX_INDEX 16
> -
> -struct index_data {
> - uint8_t type;
> - uint8_t bdaddr[6];
> - uint16_t manufacturer;
> -};
> -
> -static struct index_data index_list[MAX_INDEX];
> -
> void packet_monitor(struct timeval *tv, struct ucred *cred,
> uint16_t index, uint16_t opcode,
> const void *data, uint16_t size)
> diff --git a/monitor/packet.h b/monitor/packet.h
> index 354f4fe..2516ec1 100644
> --- a/monitor/packet.h
> +++ b/monitor/packet.h
> @@ -33,6 +33,7 @@
> #define PACKET_FILTER_SHOW_TIME_OFFSET (1 << 3)
> #define PACKET_FILTER_SHOW_ACL_DATA (1 << 4)
> #define PACKET_FILTER_SHOW_SCO_DATA (1 << 5)
> +#define PACKET_FILTER_SHOW_FRAME (1 << 6)
Call it FRAME_COUNTER or something similar. Just FRAME is misleading. Or we might just always show the frame counter anyway. It is not really in the way.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH BlueZ 3/3] client: Always start an agent
From: Luiz Augusto von Dentz @ 2017-04-20 13:13 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: linux-bluetooth@vger.kernel.org
In-Reply-To: <5CEB8780-F5F3-40EC-BC52-1FACB3378FB9@holtmann.org>
Hi Marcel,
On Thu, Apr 20, 2017 at 3:52 PM, Marcel Holtmann <marcel@holtmann.org> wrot=
e:
> Hi Luiz,
>
>> Always register agent with 'KeyboardDisplay' capability.
>> ---
>> client/main.c | 18 ++++--------------
>> 1 file changed, 4 insertions(+), 14 deletions(-)
>>
>> diff --git a/client/main.c b/client/main.c
>> index 8c9d5c3..7043081 100644
>> --- a/client/main.c
>> +++ b/client/main.c
>> @@ -54,6 +54,8 @@
>> #define PROMPT_ON COLOR_BLUE "[bluetooth]" COLOR_OFF "# "
>> #define PROMPT_OFF "Waiting to connect to bluetoothd..."
>>
>> +#define AGENT_CAP "KeyboardDisplay"
>> +
>> static GMainLoop *main_loop;
>> static DBusConnection *dbus_conn;
>>
>> @@ -2352,23 +2354,9 @@ static guint setup_signalfd(void)
>>
>> static gboolean option_version =3D FALSE;
>>
>> -static gboolean parse_agent(const char *key, const char *value,
>> - gpointer user_data, GError **error=
)
>> -{
>> - if (value)
>> - auto_register_agent =3D g_strdup(value);
>> - else
>> - auto_register_agent =3D g_strdup("");
>> -
>> - return TRUE;
>> -}
>> -
>> static GOptionEntry options[] =3D {
>> { "version", 'v', 0, G_OPTION_ARG_NONE, &option_version,
>> "Show version information and exit" },
>> - { "agent", 'a', G_OPTION_FLAG_OPTIONAL_ARG,
>> - G_OPTION_ARG_CALLBACK, parse_agent,
>> - "Register agent handler", "CAPABILITY" },
>> { NULL },
>> };
>
> actually leave the agent option and make the argument mandatory. We shoul=
d be registering with =E2=80=9C=E2=80=9D as agent string by default. That e=
nsures that we use the defaults from bluetoothd and mgmt. However the comma=
nd line option can overwrite the IO capability.
Alright, will send a v2 in a moment.
> Regards
>
> Marcel
>
--=20
Luiz Augusto von Dentz
^ permalink raw reply
* Re: [PATCH BlueZ 1/3] monitor: Add frame number support
From: Luiz Augusto von Dentz @ 2017-04-20 13:20 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: linux-bluetooth@vger.kernel.org
In-Reply-To: <2CA3B728-9A43-4033-AC20-D03FC2154D56@holtmann.org>
Hi Marcel,
On Thu, Apr 20, 2017 at 3:57 PM, Marcel Holtmann <marcel@holtmann.org> wrote:
> Hi Luiz,
>
>> This adds -f/--frames options which can be used to show the frame
>> number:
>>
>>> HCI Event: Command Complete (0x0e) plen 4 #86 [hci1] 13:00:02.639412
>> LE Set Scan Parameters (0x08|0x000b) ncmd 1
>> Status: Success (0x00)
>> < HCI Command: LE Set Scan Enable (0x08|0x000c) plen 2 #87 [hci1] 13:00:02.639663
>> Scanning: Enabled (0x01)
>> Filter duplicates: Enabled (0x01)
>>> HCI Event: Command Complete (0x0e) plen 4 #88 [hci1] 13:00:02.640420
>> LE Set Scan Enable (0x08|0x000c) ncmd 2
>> Status: Success (0x00)
>> ---
>> monitor/main.c | 7 ++++++-
>> monitor/packet.c | 37 +++++++++++++++++++++++++++----------
>> monitor/packet.h | 1 +
>> 3 files changed, 34 insertions(+), 11 deletions(-)
>>
>> diff --git a/monitor/main.c b/monitor/main.c
>> index f9bca22..e1a2375 100644
>> --- a/monitor/main.c
>> +++ b/monitor/main.c
>> @@ -70,6 +70,7 @@ static void usage(void)
>> "\t-T, --date Show time and date information\n"
>> "\t-S, --sco Dump SCO traffic\n"
>> "\t-E, --ellisys [ip] Send Ellisys HCI Injection\n"
>> + "\t-f, --frames Show frame counter\n"
>> "\t-h, --help Show help options\n");
>> }
>
> I would rather use -C / --counter as frame counter.
>
>> @@ -86,6 +87,7 @@ static const struct option main_options[] = {
>> { "date", no_argument, NULL, 'T' },
>> { "sco", no_argument, NULL, 'S' },
>> { "ellisys", required_argument, NULL, 'E' },
>> + { "frames", no_argument, NULL, 'f' },
>> { "todo", no_argument, NULL, '#' },
>> { "version", no_argument, NULL, 'v' },
>> { "help", no_argument, NULL, 'h' },
>> @@ -113,7 +115,7 @@ int main(int argc, char *argv[])
>> for (;;) {
>> int opt;
>>
>> - opt = getopt_long(argc, argv, "d:r:w:a:s:p:i:tTSE:vh",
>> + opt = getopt_long(argc, argv, "d:r:w:a:s:p:i:tfTSE:vh",
>> main_options, NULL);
>> if (opt < 0)
>> break;
>> @@ -171,6 +173,9 @@ int main(int argc, char *argv[])
>> ellisys_server = optarg;
>> ellisys_port = 24352;
>> break;
>> + case 'f':
>> + filter_mask |= PACKET_FILTER_SHOW_FRAME;
>> + break;
>> case '#':
>> packet_todo();
>> lmp_todo();
>> diff --git a/monitor/packet.c b/monitor/packet.c
>> index 3c43356..e5f2a32 100644
>> --- a/monitor/packet.c
>> +++ b/monitor/packet.c
>> @@ -58,6 +58,7 @@
>> #include "packet.h"
>>
>> #define COLOR_CHANNEL_LABEL COLOR_WHITE
>> +#define COLOR_FRAME_LABEL COLOR_WHITE
>> #define COLOR_INDEX_LABEL COLOR_WHITE
>> #define COLOR_TIMESTAMP COLOR_YELLOW
>>
>> @@ -259,6 +260,18 @@ void packet_select_index(uint16_t index)
>>
>> #define print_space(x) printf("%*c", (x), ' ');
>>
>> +#define MAX_INDEX 16
>> +
>> +struct index_data {
>> + uint8_t type;
>> + uint8_t bdaddr[6];
>> + uint16_t manufacturer;
>> + size_t frame;
>> +};
>> +
>> +static struct index_data index_list[MAX_INDEX];
>> +
>> +
>
> Too many empty lines here.
Will fix it.
>> static void print_packet(struct timeval *tv, struct ucred *cred, char ident,
>> uint16_t index, const char *channel,
>> const char *color, const char *label,
>> @@ -280,6 +293,20 @@ static void print_packet(struct timeval *tv, struct ucred *cred, char ident,
>> ts_pos += n;
>> ts_len += n;
>> }
>> + } else if (filter_mask & PACKET_FILTER_SHOW_FRAME &&
>> + (ident == '<' || ident == '>')) {
>
> Lets not use the ident to choose here.
>
>> + if (use_color()) {
>> + n = sprintf(ts_str + ts_pos, "%s", COLOR_FRAME_LABEL);
>> + if (n > 0)
>> + ts_pos += n;
>> + }
>> +
>> + n = sprintf(ts_str + ts_pos, " #%zu",
>> + ++index_list[index].frame);
>
> I would prefer if we add the frame number during input and not during display of the packet. That should be kept separate. Otherwise we create a mess like in hcidump.
I don't quite follow the during input vs display, or do you mean we
should increment directly in the io callback?
>> + if (n > 0) {
>> + ts_pos += n;
>> + ts_len += n;
>> + }
>> }
>>
>> if ((filter_mask & PACKET_FILTER_SHOW_INDEX) &&
>> @@ -3828,16 +3855,6 @@ static int addr2str(const uint8_t *addr, char *str)
>> addr[5], addr[4], addr[3], addr[2], addr[1], addr[0]);
>> }
>>
>> -#define MAX_INDEX 16
>> -
>> -struct index_data {
>> - uint8_t type;
>> - uint8_t bdaddr[6];
>> - uint16_t manufacturer;
>> -};
>> -
>> -static struct index_data index_list[MAX_INDEX];
>> -
>> void packet_monitor(struct timeval *tv, struct ucred *cred,
>> uint16_t index, uint16_t opcode,
>> const void *data, uint16_t size)
>> diff --git a/monitor/packet.h b/monitor/packet.h
>> index 354f4fe..2516ec1 100644
>> --- a/monitor/packet.h
>> +++ b/monitor/packet.h
>> @@ -33,6 +33,7 @@
>> #define PACKET_FILTER_SHOW_TIME_OFFSET (1 << 3)
>> #define PACKET_FILTER_SHOW_ACL_DATA (1 << 4)
>> #define PACKET_FILTER_SHOW_SCO_DATA (1 << 5)
>> +#define PACKET_FILTER_SHOW_FRAME (1 << 6)
>
> Call it FRAME_COUNTER or something similar. Just FRAME is misleading. Or we might just always show the frame counter anyway. It is not really in the way.
I wondering if we should enable it by default and don't bother with
the option adding yet another option.
> Regards
>
> Marcel
>
--
Luiz Augusto von Dentz
^ permalink raw reply
* [PATCH V3 0/3] hci_ldisc hci_uart_init_work() fixes
From: Dean Jenkins @ 2017-04-20 17:06 UTC (permalink / raw)
To: Marcel Holtmann
Cc: Dean Jenkins, Gustavo F . Padovan, Johan Hedberg, linux-bluetooth
Hi Marcel,
To make things easier for you, I am going to break up my V2 patchset of 16
patches into smaller patchsets. I think this approach will increase the
probability of you taking the patches and providing me feedback. Therefore, you
can concentrate on a few tightly related patches in one go.
This is patchset V3 which are needed fixes before hci_uart_tty_close() can be
reorganised to overcome a design flaw related to the proper closure of the
Data Link protocol layer. In the worst case scenario a kernel crash occurs.
Previous Discussions
====================
Please refer to the discussion on my patchset V2 that can be found here:
https://www.spinics.net/lists/linux-bluetooth/msg70183.html
Please refer to the discussion on my RFC patchset V1 that can be found here:
https://www.spinics.net/lists/linux-bluetooth/msg70077.html
Changes between V2 and V3
=========================
1. Only presenting the first 3 patches of the V2 patchset. These changes relate
mainly to handling of the failure to register the hdev device for the h5
Protocol Data layer protocol.
2. The remaining 13 patches will be put into smaller patchsets after this first
patchset has been accepted.
3. Changed the patchset title from "hci_ldisc hci_uart_tty_close() fixes" to
"hci_ldisc hci_uart_init_work() fixes" because this patchset does not modify
hci_uart_tty_close().
Changes between V1 and V2
=========================
1. Implemented some minor code style changes that were suggested by Marcel
Holtmann.
2. Reordered some of the patches to better group together related changes.
Analysis
========
hci_uart_init_work() is used with the h5 Data Link layer protocol. Static code
inspection reveals issues. Instead of testing with h5, test code was used to
show that a kernel crash occurs in HCI LDISC.
hci_uart_init_work() is used to register the HCI UART device and sets the
HCI_UART_REGISTERED flag after the h5 protocol has reached the H5_ACTIVE state
and calls hci_uart_init_ready(). This procedure is armed by setting the
HCI_UART_INIT_PENDING flag via hci_uart_tty_ioctl() using HCIUARTSETFLAGS.
During my analysis, it became clear that the hci_uart_init_work() function was
incomplete. Initially, it caused me confusion in how the design allowed
HCI_UART_REGISTERED to be set despite hci_register_dev() failing.
Test code was added to:
a) set flag HCI_UART_INIT_PENDING - used with h5 to delay hdev registration
b) call hci_uart_init_ready() - simulates h5 reaching the H5_ACTIVE state
c) force hci_register_dev() to fail
This testcase caused a kernel crash because hdev was freed in
hci_uart_init_work() but the HCI_UART_REGISTERED flag was set. Therefore,
the HCI_UART_REGISTERED flag is erroneously set on the failure of
hci_register_dev(). This is fixed in the following patch by adding a missing
return statement:
Bluetooth: hci_ldisc: Add missing return in hci_uart_init_work()
Analysis of hu->hdev showed that the hdev member of hu could remain present
despite hdev having been freed. This is potentially dangerous as there is a risk
of using hu->hdev after hdev was freed. This is fixed in patch:
Bluetooth: hci_ldisc: Ensure hu->hdev set to NULL before freeing hdev
Analysis of the flag HCI_UART_PROTO_READY showed an inconsistency for
hci_register_dev() failing in hci_uart_init_work(). The oversight is that
HCI_UART_PROTO_READY must be cleared before the close "proto" function pointer
is called as per hci_uart_set_proto() and hci_uart_tty_close(). This is fixed
in patch:
Bluetooth: hci_ldisc: Add missing clear HCI_UART_PROTO_READY
Patch list
==========
The patches were rebased onto the bluetooth-next/master branch commit:
6493b63 ieee802154: don't select COMMON_CLK
Dean Jenkins (3):
Bluetooth: hci_ldisc: Add missing return in hci_uart_init_work()
Bluetooth: hci_ldisc: Ensure hu->hdev set to NULL before freeing hdev
Bluetooth: hci_ldisc: Add missing clear HCI_UART_PROTO_READY
drivers/bluetooth/hci_ldisc.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
--
2.7.4
^ permalink raw reply
* [PATCH V3 1/3] Bluetooth: hci_ldisc: Add missing return in hci_uart_init_work()
From: Dean Jenkins @ 2017-04-20 17:06 UTC (permalink / raw)
To: Marcel Holtmann
Cc: Dean Jenkins, Gustavo F . Padovan, Johan Hedberg, linux-bluetooth
In-Reply-To: <1492708001-30228-1-git-send-email-Dean_Jenkins@mentor.com>
If hci_register_dev() returns an error in hci_uart_init_work()
then the HCI_UART_REGISTERED bit gets erroneously set due to
a missing return statement. Therefore, add the missing return
statement.
The consequence of the missing return is that the HCI UART is not
registered but HCI_UART_REGISTERED is set which allows the code
to think that hu->hdev is safe to access but hu->hdev has been
freed so could lead to a crash.
Signed-off-by: Dean Jenkins <Dean_Jenkins@mentor.com>
---
drivers/bluetooth/hci_ldisc.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/bluetooth/hci_ldisc.c b/drivers/bluetooth/hci_ldisc.c
index cec4438..1166e3f 100644
--- a/drivers/bluetooth/hci_ldisc.c
+++ b/drivers/bluetooth/hci_ldisc.c
@@ -187,6 +187,7 @@ static void hci_uart_init_work(struct work_struct *work)
hci_free_dev(hu->hdev);
hu->hdev = NULL;
hu->proto->close(hu);
+ return;
}
set_bit(HCI_UART_REGISTERED, &hu->flags);
--
2.7.4
^ permalink raw reply related
* [PATCH V3 2/3] Bluetooth: hci_ldisc: Ensure hu->hdev set to NULL before freeing hdev
From: Dean Jenkins @ 2017-04-20 17:06 UTC (permalink / raw)
To: Marcel Holtmann
Cc: Dean Jenkins, Gustavo F . Padovan, Johan Hedberg, linux-bluetooth
In-Reply-To: <1492708001-30228-1-git-send-email-Dean_Jenkins@mentor.com>
When hci_register_dev() fails, hu->hdev should be set to NULL before
freeing hdev. This avoids potential use of hu->hdev after it has been
freed.
This commit sets hu->hdev to NULL before calling hci_free_dev() in error
handling scenarios in hci_uart_init_work() and hci_uart_register_dev().
Signed-off-by: Dean Jenkins <Dean_Jenkins@mentor.com>
---
drivers/bluetooth/hci_ldisc.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/bluetooth/hci_ldisc.c b/drivers/bluetooth/hci_ldisc.c
index 1166e3f..b1096d1 100644
--- a/drivers/bluetooth/hci_ldisc.c
+++ b/drivers/bluetooth/hci_ldisc.c
@@ -177,6 +177,7 @@ static void hci_uart_init_work(struct work_struct *work)
{
struct hci_uart *hu = container_of(work, struct hci_uart, init_ready);
int err;
+ struct hci_dev *hdev;
if (!test_and_clear_bit(HCI_UART_INIT_PENDING, &hu->hdev_flags))
return;
@@ -184,8 +185,9 @@ static void hci_uart_init_work(struct work_struct *work)
err = hci_register_dev(hu->hdev);
if (err < 0) {
BT_ERR("Can't register HCI device");
- hci_free_dev(hu->hdev);
+ hdev = hu->hdev;
hu->hdev = NULL;
+ hci_free_dev(hdev);
hu->proto->close(hu);
return;
}
@@ -603,6 +605,7 @@ static int hci_uart_register_dev(struct hci_uart *hu)
if (hci_register_dev(hdev) < 0) {
BT_ERR("Can't register HCI device");
+ hu->hdev = NULL;
hci_free_dev(hdev);
return -ENODEV;
}
--
2.7.4
^ permalink raw reply related
* [PATCH V3 3/3] Bluetooth: hci_ldisc: Add missing clear HCI_UART_PROTO_READY
From: Dean Jenkins @ 2017-04-20 17:06 UTC (permalink / raw)
To: Marcel Holtmann
Cc: Dean Jenkins, Gustavo F . Padovan, Johan Hedberg, linux-bluetooth
In-Reply-To: <1492708001-30228-1-git-send-email-Dean_Jenkins@mentor.com>
Ensure that HCI_UART_PROTO_READY is cleared before close(hu) is
called which closes the Data Link protocol layer.
Therefore, add the missing bit clear of HCI_UART_PROTO_READY to
hci_uart_init_work() so that the flag is cleared when
hci_register_dev fails.
Without the fix, the functions of the Data Link protocol layer could
potentially be accessed after that layer has been closed. This
could lead to a crash as memory would have been freed in that layer.
Signed-off-by: Dean Jenkins <Dean_Jenkins@mentor.com>
---
drivers/bluetooth/hci_ldisc.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/bluetooth/hci_ldisc.c b/drivers/bluetooth/hci_ldisc.c
index b1096d1..c53513c 100644
--- a/drivers/bluetooth/hci_ldisc.c
+++ b/drivers/bluetooth/hci_ldisc.c
@@ -188,6 +188,7 @@ static void hci_uart_init_work(struct work_struct *work)
hdev = hu->hdev;
hu->hdev = NULL;
hci_free_dev(hdev);
+ clear_bit(HCI_UART_PROTO_READY, &hu->flags);
hu->proto->close(hu);
return;
}
--
2.7.4
^ permalink raw reply related
* BlueZ 5 Unknown Connection Identifier
From: Steve Benton @ 2017-04-21 14:56 UTC (permalink / raw)
To: linux-bluetooth
Hello,
I have a Raspberry Pi 3 running the latest Raspbian, and I have
upgraded bluez from 5.23. to 5.43. I am attempting to connect to BLE
devices that advertise at 2 second interval. I wrote some code based
on gatttool and attempted to connect to these devices. I run into the
le connect request being cancelled after 2 seconds. From my research I
ran across this from about 15 months ago in the archives,
https://www.spinics.net/lists/linux-bluetooth/msg65434.html
However after following the threads, I did not see if a resolution was found.
I have ran tests with my code, the gatttool utility and well as using
bluetoothctl. I see the same type of activity in btmon that is listed
below:
< HCI Command: LE Set Scan Parameters (0x08|0x000b) plen 7
[hci0] 21:45:51.917070
Type: Passive (0x00)
Interval: 60.000 msec (0x0060)
Window: 30.000 msec (0x0030)
Own address type: Public (0x00)
Filter policy: Ignore not in white list (0x01)
> HCI Event: Command Complete (0x0e) plen 4 [hci0] 21:45:51.917819
LE Set Scan Parameters (0x08|0x000b) ncmd 1
Status: Success (0x00)
< HCI Command: LE Set Scan Enable (0x08|0x000c) plen 2
[hci0] 21:45:51.917876
Scanning: Enabled (0x01)
Filter duplicates: Enabled (0x01)
> HCI Event: Command Complete (0x0e) plen 4 [hci0] 21:45:51.918357
LE Set Scan Enable (0x08|0x000c) ncmd 1
Status: Success (0x00)
> HCI Event: LE Meta Event (0x3e) plen 27 [hci0] 21:45:52.597503
LE Advertising Report (0x02)
Num reports: 1
Event type: Connectable undirected - ADV_IND (0x00)
Address type: Random (0x01)
Address: D3:67:2D:D1:46:46 (Static)
Data length: 15
Flags: 0x06
LE General Discoverable Mode
BR/EDR Not Supported
Company: FedEx Services (321)
Data: 070a111080d28004
RSSI: -63 dBm (0xc1)
< HCI Command: LE Set Scan Enable (0x08|0x000c) plen 2
[hci0] 21:45:52.597611
Scanning: Disabled (0x00)
Filter duplicates: Disabled (0x00)
> HCI Event: Command Complete (0x0e) plen 4 [hci0] 21:45:52.599626
LE Set Scan Enable (0x08|0x000c) ncmd 1
Status: Success (0x00)
< HCI Command: LE Create Connection (0x08|0x000d) plen 25
[hci0] 21:45:52.599701
Scan interval: 60.000 msec (0x0060)
Scan window: 60.000 msec (0x0060)
Filter policy: White list is not used (0x00)
Peer address type: Random (0x01)
Peer address: D3:67:2D:D1:46:46 (Static)
Own address type: Public (0x00)
Min connection interval: 50.00 msec (0x0028)
Max connection interval: 70.00 msec (0x0038)
Connection latency: 0x0000
Supervision timeout: 420 msec (0x002a)
Min connection length: 0.000 msec (0x0000)
Max connection length: 0.000 msec (0x0000)
> HCI Event: Command Status (0x0f) plen 4 [hci0] 21:45:52.600508
LE Create Connection (0x08|0x000d) ncmd 1
Status: Success (0x00)
< HCI Command: LE Create Connection Cancel (0x08|0x000e) plen 0
[hci0] 21:45:54.597597
> HCI Event: Command Complete (0x0e) plen 4 [hci0] 21:45:54.684146
LE Create Connection Cancel (0x08|0x000e) ncmd 1
Status: Success (0x00)
> HCI Event: LE Meta Event (0x3e) plen 19 [hci0] 21:45:54.684361
LE Connection Complete (0x01)
Status: Unknown Connection Identifier (0x02)
Handle: 64
Role: Master (0x00)
Peer address type: Random (0x01)
Peer address: D3:67:2D:D1:46:46 (Static)
Connection interval: 67.50 msec (0x0036)
Connection latency: 0.00 msec (0x0000)
Supervision timeout: 420 msec (0x002a)
Master clock accuracy: 0x00
@ Connect Failed: D3:67:2D:D1:46:46 (2) status 0x02
Has there been a resolution to this? Is there a way to change the
connect timeout?
One thing to note is if I use hcitool to connect, I am able to connect
most all of the time. I know this is not the L2CAP layer, but I can
see that I am able to connect.
Thanks
^ permalink raw reply
* Re: [PATCH V3 0/3] hci_ldisc hci_uart_init_work() fixes
From: Marcel Holtmann @ 2017-04-21 16:26 UTC (permalink / raw)
To: Dean Jenkins; +Cc: Gustavo F. Padovan, Johan Hedberg, linux-bluetooth
In-Reply-To: <1492708001-30228-1-git-send-email-Dean_Jenkins@mentor.com>
Hi Dean,
> To make things easier for you, I am going to break up my V2 patchset of 16
> patches into smaller patchsets. I think this approach will increase the
> probability of you taking the patches and providing me feedback. Therefore, you
> can concentrate on a few tightly related patches in one go.
>
> This is patchset V3 which are needed fixes before hci_uart_tty_close() can be
> reorganised to overcome a design flaw related to the proper closure of the
> Data Link protocol layer. In the worst case scenario a kernel crash occurs.
>
> Previous Discussions
> ====================
>
> Please refer to the discussion on my patchset V2 that can be found here:
> https://www.spinics.net/lists/linux-bluetooth/msg70183.html
>
> Please refer to the discussion on my RFC patchset V1 that can be found here:
> https://www.spinics.net/lists/linux-bluetooth/msg70077.html
>
>
> Changes between V2 and V3
> =========================
>
> 1. Only presenting the first 3 patches of the V2 patchset. These changes relate
> mainly to handling of the failure to register the hdev device for the h5
> Protocol Data layer protocol.
>
> 2. The remaining 13 patches will be put into smaller patchsets after this first
> patchset has been accepted.
>
> 3. Changed the patchset title from "hci_ldisc hci_uart_tty_close() fixes" to
> "hci_ldisc hci_uart_init_work() fixes" because this patchset does not modify
> hci_uart_tty_close().
>
>
> Changes between V1 and V2
> =========================
>
> 1. Implemented some minor code style changes that were suggested by Marcel
> Holtmann.
> 2. Reordered some of the patches to better group together related changes.
>
> Analysis
> ========
>
> hci_uart_init_work() is used with the h5 Data Link layer protocol. Static code
> inspection reveals issues. Instead of testing with h5, test code was used to
> show that a kernel crash occurs in HCI LDISC.
>
> hci_uart_init_work() is used to register the HCI UART device and sets the
> HCI_UART_REGISTERED flag after the h5 protocol has reached the H5_ACTIVE state
> and calls hci_uart_init_ready(). This procedure is armed by setting the
> HCI_UART_INIT_PENDING flag via hci_uart_tty_ioctl() using HCIUARTSETFLAGS.
>
> During my analysis, it became clear that the hci_uart_init_work() function was
> incomplete. Initially, it caused me confusion in how the design allowed
> HCI_UART_REGISTERED to be set despite hci_register_dev() failing.
>
>
> Test code was added to:
> a) set flag HCI_UART_INIT_PENDING - used with h5 to delay hdev registration
> b) call hci_uart_init_ready() - simulates h5 reaching the H5_ACTIVE state
> c) force hci_register_dev() to fail
>
> This testcase caused a kernel crash because hdev was freed in
> hci_uart_init_work() but the HCI_UART_REGISTERED flag was set. Therefore,
> the HCI_UART_REGISTERED flag is erroneously set on the failure of
> hci_register_dev(). This is fixed in the following patch by adding a missing
> return statement:
>
> Bluetooth: hci_ldisc: Add missing return in hci_uart_init_work()
>
>
> Analysis of hu->hdev showed that the hdev member of hu could remain present
> despite hdev having been freed. This is potentially dangerous as there is a risk
> of using hu->hdev after hdev was freed. This is fixed in patch:
>
> Bluetooth: hci_ldisc: Ensure hu->hdev set to NULL before freeing hdev
>
>
> Analysis of the flag HCI_UART_PROTO_READY showed an inconsistency for
> hci_register_dev() failing in hci_uart_init_work(). The oversight is that
> HCI_UART_PROTO_READY must be cleared before the close "proto" function pointer
> is called as per hci_uart_set_proto() and hci_uart_tty_close(). This is fixed
> in patch:
>
> Bluetooth: hci_ldisc: Add missing clear HCI_UART_PROTO_READY
>
>
> Patch list
> ==========
>
> The patches were rebased onto the bluetooth-next/master branch commit:
> 6493b63 ieee802154: don't select COMMON_CLK
>
> Dean Jenkins (3):
> Bluetooth: hci_ldisc: Add missing return in hci_uart_init_work()
> Bluetooth: hci_ldisc: Ensure hu->hdev set to NULL before freeing hdev
> Bluetooth: hci_ldisc: Add missing clear HCI_UART_PROTO_READY
>
> drivers/bluetooth/hci_ldisc.c | 7 ++++++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
all 3 patches have been applied to bluetooth-next tree.
Regards
Marcel
^ permalink raw reply
* Re: GATT Server: DBus GATT Services not advertised/exported
From: Olivier MARTIN @ 2017-04-21 17:22 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: Barry Byford, Bluez mailing list
In-Reply-To: <CABBYNZK-2xr2n6B_JCD7uXkvHPLDsj5N-3Md=w6J_JUO7VXP7Q@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 32185 bytes --]
Hi Luiz,
after doing more investigation, I think the slow down comes from some
incompatibilities between Bluez v5.44 and the Linux kernel distributed
with Ubuntu 16.04 (ie: 4.4.0-72).
Android can discover the GATT services of Bluez's v5.37
'./tests/example-gatt-server' with bluez v5.37 distributed by Ubuntu
16.04 under a second.
FYI, I attached 'btmon.log' that is the result of 'btmon' when I had the
slowdown with Android 5.1.
Thanks,
Olivier
On 20.04.2017 13:31, Luiz Augusto von Dentz wrote:
> Hi Oliver,
>
> On Thu, Apr 20, 2017 at 2:20 AM, Olivier MARTIN <olivier@labapart.com>
> wrote:
>> I am back on the thread.
>> What I noticed last week when I tried on Android phone with both "BLE
>> Scanner" and "Nordic Connect", discovering GATT services is really
>> really
>> slow (it takes 2 min to discover all `example-gatt-server` GATT
>> services) on
>> Nexus 4 with Android 5.1.1 and Ubuntu 16.04 with Bluez v5.44 for the
>> GATT
>> server. I am using the Asus USB-BT400 (Broadcom chipset).
>>
>> I did more investigation this evening but I have not done any
>> progress.
>> I tried with `example-gatt-server` started by the user and root and no
>> change in the poor performance.
>>
>> I do not know what is taking so long but for instance it takes many
>> seconds
>> to execute this part:
>>
>> bluetoothd[12913]: src/device.c:gatt_debug() Read By Type - start:
>> 0x005e
>> end: 0x0061
>> bluetoothd[12913]: src/device.c:gatt_debug() Read By Type - start:
>> 0x0060
>> end: 0x0061
>> bluetoothd[12913]: src/device.c:gatt_debug() Find Info - start: 0x0061
>> end:
>> 0x0061
>> bluetoothd[12913]: src/device.c:gatt_debug() Read By Type - start:
>> 0x0062
>> end: 0x0071
>> bluetoothd[12913]: src/device.c:gatt_debug() Read By Type - start:
>> 0x0062
>> end: 0x0071
>> bluetoothd[12913]: src/device.c:gatt_debug() Read By Type - start:
>> 0x006e
>> end: 0x0071
>> bluetoothd[12913]: src/device.c:gatt_debug() Find Info - start: 0x0065
>> end:
>> 0x0067
>> bluetoothd[12913]: src/device.c:gatt_debug() Find Info - start: 0x0066
>> end:
>> 0x0067
>> bluetoothd[12913]: src/device.c:gatt_debug() Find Info - start: 0x0067
>> end:
>> 0x0067
>> bluetoothd[12913]: src/device.c:gatt_debug() Find Info - start: 0x006a
>> end:
>> 0x006c
>> bluetoothd[12913]: src/device.c:gatt_debug() Find Info - start: 0x006b
>> end:
>> 0x006c
>> bluetoothd[12913]: src/device.c:gatt_debug() Find Info - start: 0x006c
>> end:
>> 0x006c
>> bluetoothd[12913]: src/device.c:gatt_debug() Find Info - start: 0x006f
>> end:
>> 0x0071
>> bluetoothd[12913]: src/device.c:gatt_debug() Find Info - start: 0x0070
>> end:
>> 0x0071
>> bluetoothd[12913]: src/device.c:gatt_debug() Find Info - start: 0x0071
>> end:
>> 0x0071
>> bluetoothd[12913]: src/device.c:gatt_debug() Read By Type - start:
>> 0x0072
>> end: 0x0079
>> bluetoothd[12913]: src/device.c:gatt_debug() Read By Type - start:
>> 0x0072
>> end: 0x0079
>> bluetoothd[12913]: src/device.c:gatt_debug() Read By Type - start:
>> 0x0079
>> end: 0x0079
>> bluetoothd[12913]: src/device.c:gatt_debug() Find Info - start: 0x0077
>> end:
>> 0x0077
>
> You should be able to see their timings in HCI with btmon, or just use
> journalctl if are thinking there is a delay in processing the packets
> but I think that is not the case. These many Find Info does indeed
> looks odd, and there are even repeated range.
>
>>
>>
>>
>> On 14.04.2017 20:31, Barry Byford wrote:
>>>
>>> Hello Olivier,
>>>
>>> On 14 April 2017 at 19:14, Olivier MARTIN <olivier@labapart.com>
>>> wrote:
>>>>
>>>> Thanks Barry, setting 'ControllerMode = le' in
>>>> /etc/bluetooth/main.conf
>>>> fixed my issue. I can now see the GATT services.
>>>
>>>
>>> Good news!
>>>
>>>> But I guess my adapter now only works as BLE adapter and will ignore
>>>> the
>>>> non-LE devices.
>>>> In the comment of /etc/bluetooth/main.conf it is written the adapter
>>>> should
>>>> be by default set as 'dual'.
>>>>
>>>> Is it a bug in Bluez? Why GATT services are not exposed while using
>>>> the
>>>> default value for 'ControllerMode'?
>>>
>>>
>>> This issue has come up before and was discuss here:
>>> http://marc.info/?l=linux-bluetooth&m=146071596012263&w=2
>>>
>>>
>>>
>>>
>>>> On 14.04.2017 14:30, Barry Byford wrote:
>>>>>
>>>>>
>>>>> Hello Olivier,
>>>>>
>>>>>
>>>>> On 14 April 2017 at 12:01, Olivier MARTIN <olivier@labapart.com>
>>>>> wrote:
>>>>>>
>>>>>>
>>>>>> You are right Barry, `example-advertisement` seems to work well (I
>>>>>> installed
>>>>>> and tried Nordic nRF Connect and I can see the expected
>>>>>> advertisemet
>>>>>> data).
>>>>>
>>>>>
>>>>>
>>>>> Excellent!
>>>>>
>>>>>
>>>>>> But I cannot still manage to get `example-gatt-server` :-(
>>>>>> I am sure I got it working last year with an older version of
>>>>>> Bluez.
>>>>>> But
>>>>>> I
>>>>>> cannot make it work with Bluez v5.44.
>>>>>
>>>>>
>>>>>
>>>>> OK, I've taken a look at "example-gatt-server" and have it
>>>>> working...
>>>>>
>>>>>>
>>>>>> My testing procedure:
>>>>>>
>>>>>> 1. [Laptop] First terminal: Start `sudo ./src/bluetoothd -E -n -d`
>>>>>> 2. [Laptop] Second terminal: Start unmodified Bluez
>>>>>> ./test/example-gatt-server
>>>>>> 3. [Laptop] Third terminal: Ensure the adapter is "Powered: yes"
>>>>>> and
>>>>>> "Discoverable: yes"
>>>>>
>>>>>
>>>>>
>>>>> OK, I've done this slightly different (details below). However, the
>>>>> first thing I did was edit "/etc/bluetooth/main.conf"
>>>>> I added the following line to the end of the file:
>>>>>
>>>>> ControllerMode = le
>>>>>
>>>>> Then I did the following:
>>>>> 1. [SBC1:T1] sudo ./src/bluetoothd -E -n -d
>>>>> 2. [SBC1:T2] ./example-gatt-server
>>>>> 3. [SBC1:T3] ./example-advertisement
>>>>>
>>>>>
>>>>>>
>>>>>> 4. [Android] Connect using Nordic nRF Connect (I also tried with
>>>>>> "BLE
>>>>>> Scanner") and check I see the exposed GATT services by
>>>>>> `example-gatt-server`
>>>>>> Unfortunately, I can only see:
>>>>>> - Generic Access Service (0x1800)
>>>>>> - Generic Attribute Service (0x1801)
>>>>>>
>>>>>
>>>>> I've used bluetoothctl on SBC2 to connect and read the battery
>>>>> values
>>>>> that the GATT server is counting down.
>>>>>
>>>>> $ bluetoothctl
>>>>> [NEW] Controller 00:00:00:00:5A:AD linaro-alip [default]
>>>>> [bluetooth]# scan on
>>>>> Discovery started
>>>>> [CHG] Controller 00:00:00:00:5A:AD Discovering: yes
>>>>> [NEW] Device B8:27:EB:22:57:E0 BluezeroLight
>>>>> [bluetooth]# scan off
>>>>> Discovery stopped
>>>>> [CHG] Controller 00:00:00:00:5A:AD Discovering: no
>>>>> [bluetooth]# connect B8:27:EB:22:57:E0
>>>>> Attempting to connect to B8:27:EB:22:57:E0
>>>>> [CHG] Device B8:27:EB:22:57:E0 Connected: yes
>>>>> Connection successful
>>>>> [...snip...]
>>>>> [NEW] Primary Service
>>>>> /org/bluez/hci0/dev_B8_27_EB_22_57_E0/service000a
>>>>> 0000180f-0000-1000-8000-00805f9b34fb
>>>>> Battery Service
>>>>> [NEW] Characteristic
>>>>> /org/bluez/hci0/dev_B8_27_EB_22_57_E0/service000a/char000b
>>>>> 00002a19-0000-1000-8000-00805f9b34fb
>>>>> Battery Level
>>>>> [...snip...]
>>>>> [CHG] Device B8:27:EB:22:57:E0 ServicesResolved: yes
>>>>> [BluezeroLight]# select-attribute
>>>>> /org/bluez/hci0/dev_B8_27_EB_22_57_E0/service000a/char000b
>>>>> [BluezeroLight:/service000a/char000b]# read
>>>>> Attempting to read
>>>>> /org/bluez/hci0/dev_B8_27_EB_22_57_E0/service000a/char000b
>>>>> [CHG] Attribute
>>>>> /org/bluez/hci0/dev_B8_27_EB_22_57_E0/service000a/char000b Value:
>>>>> 0x46
>>>>> 46 F
>>>>> [BluezeroLight:/service000a/char000b]# notify on
>>>>> [CHG] Attribute
>>>>> /org/bluez/hci0/dev_B8_27_EB_22_57_E0/service000a/char000b
>>>>> Notifying:
>>>>> yes
>>>>> Notify started
>>>>> [CHG] Attribute
>>>>> /org/bluez/hci0/dev_B8_27_EB_22_57_E0/service000a/char000b Value:
>>>>> 0x46
>>>>> [CHG] Attribute
>>>>> /org/bluez/hci0/dev_B8_27_EB_22_57_E0/service000a/char000b Value:
>>>>> 0x44
>>>>> [CHG] Attribute
>>>>> /org/bluez/hci0/dev_B8_27_EB_22_57_E0/service000a/char000b Value:
>>>>> 0x42
>>>>> [CHG] Attribute
>>>>> /org/bluez/hci0/dev_B8_27_EB_22_57_E0/service000a/char000b Value:
>>>>> 0x40
>>>>> [CHG] Attribute
>>>>> /org/bluez/hci0/dev_B8_27_EB_22_57_E0/service000a/char000b Value:
>>>>> 0x3e
>>>>> [BluezeroLight:/service000a/char000b]# notify off
>>>>> [CHG] Attribute
>>>>> /org/bluez/hci0/dev_B8_27_EB_22_57_E0/service000a/char000b
>>>>> Notifying:
>>>>> no
>>>>> Notify stopped
>>>>>
>>>>>
>>>>> That seems to be working then. When I didn't have "ControllerMode =
>>>>> le" set then I did see it be unpredictable if it successfully
>>>>> connected or not.
>>>>> This also worked connecting with the nRF app.
>>>>>
>>>>>
>>>>> Does that work for you?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> If I had to suspect Bluez code, I will guess there is something
>>>>>> missing
>>>>>> around here:
>>>>>>
>>>>>> bluetoothd[20429]: src/device.c:gatt_server_init() #
>>>>>> gatt_server_init
>>>>>> bluetoothd[20429]: src/device.c:gatt_debug() Primary services
>>>>>> found: 2
>>>>>> bluetoothd[20429]: src/device.c:gatt_debug() start: 0x0001, end:
>>>>>> 0x0005,
>>>>>> uuid: 00001801-0000-1000-8000-00805f9b34fb
>>>>>> bluetoothd[20429]: src/device.c:gatt_debug() start: 0x0014, end:
>>>>>> 0xffff,
>>>>>> uuid: 00001800-0000-1000-8000-00805f9b34fb
>>>>>> bluetoothd[20429]: src/device.c:gatt_debug() Registered handler
>>>>>> for
>>>>>> "Service
>>>>>> Changed": 0
>>>>>> bluetoothd[20429]: src/device.c:gatt_client_ready_cb() status:
>>>>>> success,
>>>>>> error: 0
>>>>>>
>>>>>> As Bluez daemon does not get the GATT services from Buez GATT
>>>>>> Database.
>>>>>> But
>>>>>> it might be me who miss a step...
>>>>>>
>>>>>>
>>>>>> On 14.04.2017 12:37, Barry Byford wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> example-advertisementHello Oliver,
>>>>>>>
>>>>>>>
>>>>>>> On 14 April 2017 at 11:03, Olivier MARTIN <olivier@labapart.com>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Thanks for replying my message Barry,
>>>>>>>>
>>>>>>>> Sorry, I forgot to mention but I start Bluez daemon with `sudo
>>>>>>>> ./src/bluetoothd -E -n -d` (after stopping the bluetooth
>>>>>>>> service). So
>>>>>>>> I
>>>>>>>> already run it with sudo and experimental option.
>>>>>>>>
>>>>>>>> I am not sure to understand what you mean by "this kind of error
>>>>>>>> message".
>>>>>>>> Because I do not see any error message in the log I provided.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> OK, that was bad on my part. I read it as complaining that there
>>>>>>> were
>>>>>>> too many advertisements. Looking again that wasn't what it was
>>>>>>> say.
>>>>>>> Apologies.
>>>>>>>
>>>>>>>>
>>>>>>>> Any other idea?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> I am by Linux Single Board Computers (SBC) today so I'm able to
>>>>>>> run
>>>>>>> what you are running and can show you what I'm seeing. I'll focus
>>>>>>> on
>>>>>>> example-advertisement first as example-gatt-server doesn't change
>>>>>>> the
>>>>>>> advertisements.
>>>>>>>
>>>>>>> I've started the BlueZ daemon with "./src/bluetoothd -E -n -d"
>>>>>>>
>>>>>>> In another shell when I start "./example-advertisement" I see the
>>>>>>> following in the output:
>>>>>>>
>>>>>>> bluetoothd[2325]: src/adapter.c:property_set_mode() sending Set
>>>>>>> Powered command for index 0
>>>>>>> bluetoothd[2325]: src/adapter.c:property_set_mode_complete()
>>>>>>> Success
>>>>>>> (0x00)
>>>>>>> bluetoothd[2325]: src/adapter.c:new_settings_callback() Settings:
>>>>>>> 0x00000ad1
>>>>>>> bluetoothd[2325]: src/adapter.c:settings_changed() Changed
>>>>>>> settings:
>>>>>>> 0x00000001
>>>>>>> bluetoothd[2325]: src/adapter.c:adapter_start() adapter
>>>>>>> /org/bluez/hci0 has been enabled
>>>>>>> bluetoothd[2325]: src/adapter.c:trigger_passive_scanning()
>>>>>>> bluetoothd[2325]: src/advertising.c:register_advertisement()
>>>>>>> RegisterAdvertisement
>>>>>>> bluetoothd[2325]: src/advertising.c:client_create() Adding proxy
>>>>>>> for
>>>>>>> /org/bluez/example/advertisement0
>>>>>>> bluetoothd[2325]: src/advertising.c:register_advertisement()
>>>>>>> Registered advertisement at path
>>>>>>> /org/bluez/example/advertisement0
>>>>>>> bluetoothd[2325]: src/advertising.c:parse_service_uuids() Adding
>>>>>>> ServiceUUID: 180D
>>>>>>> bluetoothd[2325]: src/advertising.c:parse_service_uuids() Adding
>>>>>>> ServiceUUID: 180F
>>>>>>> bluetoothd[2325]: src/advertising.c:parse_manufacturer_data()
>>>>>>> Adding
>>>>>>> ManufacturerData for ffff
>>>>>>> bluetoothd[2325]: src/advertising.c:parse_service_data() Adding
>>>>>>> ServiceData for 9999
>>>>>>> bluetoothd[2325]: src/advertising.c:refresh_advertisement()
>>>>>>> Refreshing
>>>>>>> advertisement: /org/bluez/example/advertisement0
>>>>>>> bluetoothd[2325]: src/advertising.c:add_adv_callback()
>>>>>>> Advertisement
>>>>>>> registered: /org/bluez/example/advertisement0
>>>>>>>
>>>>>>>
>>>>>>> On a second SBC, at the command line I run "bluetoothctl" and do
>>>>>>> "scan
>>>>>>> on". Once my first SBC is found I do "scan off". I then do "info
>>>>>>> B8:27:EB:22:57:E0" (this is the address of the first SBC) which
>>>>>>> gives
>>>>>>> the following output:
>>>>>>>
>>>>>>> [bluetooth]# info B8:27:EB:22:57:E0
>>>>>>> Device B8:27:EB:22:57:E0
>>>>>>> Alias: B8-27-EB-22-57-E0
>>>>>>> Paired: no
>>>>>>> Trusted: no
>>>>>>> Blocked: no
>>>>>>> Connected: no
>>>>>>> LegacyPairing: no
>>>>>>> UUID: Heart Rate
>>>>>>> (0000180d-0000-1000-8000-00805f9b34fb)
>>>>>>> UUID: Battery Service
>>>>>>> (0000180f-0000-1000-8000-00805f9b34fb)
>>>>>>> ManufacturerData Key: 0xffff
>>>>>>> ManufacturerData Value: 0x00
>>>>>>> ManufacturerData Value: 0x01
>>>>>>> ManufacturerData Value: 0x02
>>>>>>> ManufacturerData Value: 0x03
>>>>>>> ManufacturerData Value: 0x04
>>>>>>> ServiceData Key: 00009999-0000-1000-8000-00805f9b34fb
>>>>>>> ServiceData Value: 0x00
>>>>>>> ServiceData Value: 0x01
>>>>>>> ServiceData Value: 0x02
>>>>>>> ServiceData Value: 0x03
>>>>>>> ServiceData Value: 0x04
>>>>>>>
>>>>>>>
>>>>>>> I've also done a scan from my Android phone (using the Nordic nRF
>>>>>>> Connect app) and can see the advertisements also (just hard to
>>>>>>> share
>>>>>>> that information on here).
>>>>>>>
>>>>>>> Does that help?
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 13.04.2017 19:59, Barry Byford wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Hello Olivier,
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 13 April 2017 at 12:14, Olivier MARTIN
>>>>>>>>> <olivier@labapart.com>
>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Hi all,
>>>>>>>>>> I am having issue to advertise/export GATT services exposed
>>>>>>>>>> through
>>>>>>>>>> DBus
>>>>>>>>>> API. I tried `./test/example-gatt-server`. And I also tried to
>>>>>>>>>> merge
>>>>>>>>>> `./test/example-advertisement` into
>>>>>>>>>> `./test/example-gatt-server`.
>>>>>>>>>> But
>>>>>>>>>> in
>>>>>>>>>> both cases I only see the two compulsory GATT services:
>>>>>>>>>> - Generic Access Service (0x1800)
>>>>>>>>>> - Generic Attribute Service (0x1801)
>>>>>>>>>>
>>>>>>>>>> I am using Bluez v5.44. And I also tried Bluez v5.37.
>>>>>>>>>>
>>>>>>>>>> GATT Services seem to be discovered by Bluez (note: I added
>>>>>>>>>> additional
>>>>>>>>>> debug
>>>>>>>>>> statement all prefixed with '#'):
>>>>>>>>>>
>>>>>>>>>> bluetoothd[16877]: src/gatt-database.c:manager_register_app()
>>>>>>>>>> #
>>>>>>>>>> manager_register_app
>>>>>>>>>> bluetoothd[16877]: src/gatt-database.c:create_app() #
>>>>>>>>>> create_app
>>>>>>>>>> bluetoothd[16877]: src/gatt-database.c:manager_register_app()
>>>>>>>>>> Registering
>>>>>>>>>> application: :1.404:/
>>>>>>>>>> bluetoothd[16877]: src/advertising.c:register_advertisement()
>>>>>>>>>> RegisterAdvertisement
>>>>>>>>>> bluetoothd[16877]: src/advertising.c:client_create() Adding
>>>>>>>>>> proxy
>>>>>>>>>> for
>>>>>>>>>> /org/bluez/example/advertisement0
>>>>>>>>>> bluetoothd[16877]: src/advertising.c:register_advertisement()
>>>>>>>>>> Registered
>>>>>>>>>> advertisement at path /org/bluez/example/advertisement0
>>>>>>>>>> bluetoothd[16877]: src/gatt-database.c:proxy_added_cb() Object
>>>>>>>>>> received:
>>>>>>>>>> /org/bluez/example/service0/char2, iface:
>>>>>>>>>> org.bluez.GattCharacteristic1
>>>>>>>>>> bluetoothd[16877]: src/gatt-database.c:proxy_added_cb() Object
>>>>>>>>>> received:
>>>>>>>>>> /org/bluez/example/service2/char0/desc0, iface:
>>>>>>>>>> org.bluez.GattDescriptor1
>>>>>>>>>> bluetoothd[16877]: src/gatt-database.c:proxy_added_cb() Object
>>>>>>>>>> received:
>>>>>>>>>> /org/bluez/example/service2/char2/desc3, iface:
>>>>>>>>>> org.bluez.GattDescriptor1
>>>>>>>>>> bluetoothd[16877]: src/gatt-database.c:proxy_added_cb() Object
>>>>>>>>>> received:
>>>>>>>>>> /org/bluez/example/service2/char2, iface:
>>>>>>>>>> org.bluez.GattCharacteristic1
>>>>>>>>>> bluetoothd[16877]: src/gatt-database.c:proxy_added_cb() Object
>>>>>>>>>> received:
>>>>>>>>>> /org/bluez/example/service1/char0, iface:
>>>>>>>>>> org.bluez.GattCharacteristic1
>>>>>>>>>> bluetoothd[16877]: src/gatt-database.c:proxy_added_cb() Object
>>>>>>>>>> received:
>>>>>>>>>> /org/bluez/example/service2/char1, iface:
>>>>>>>>>> org.bluez.GattCharacteristic1
>>>>>>>>>> bluetoothd[16877]: src/gatt-database.c:proxy_added_cb() Object
>>>>>>>>>> received:
>>>>>>>>>> /org/bluez/example/service0/char1, iface:
>>>>>>>>>> org.bluez.GattCharacteristic1
>>>>>>>>>> bluetoothd[16877]: src/gatt-database.c:proxy_added_cb() Object
>>>>>>>>>> received:
>>>>>>>>>> /org/bluez/example/service2/char1/desc3, iface:
>>>>>>>>>> org.bluez.GattDescriptor1
>>>>>>>>>> bluetoothd[16877]: src/gatt-database.c:proxy_added_cb() Object
>>>>>>>>>> received:
>>>>>>>>>> /org/bluez/example/service2/char1/desc2, iface:
>>>>>>>>>> org.bluez.GattDescriptor1
>>>>>>>>>> bluetoothd[16877]: src/gatt-database.c:proxy_added_cb() Object
>>>>>>>>>> received:
>>>>>>>>>> /org/bluez/example/service0/char0, iface:
>>>>>>>>>> org.bluez.GattCharacteristic1
>>>>>>>>>> bluetoothd[16877]: src/gatt-database.c:proxy_added_cb() Object
>>>>>>>>>> received:
>>>>>>>>>> /org/bluez/example/service2, iface: org.bluez.GattService1
>>>>>>>>>> bluetoothd[16877]: src/gatt-database.c:proxy_added_cb() Object
>>>>>>>>>> received:
>>>>>>>>>> /org/bluez/example/service1, iface: org.bluez.GattService1
>>>>>>>>>> bluetoothd[16877]: src/gatt-database.c:proxy_added_cb() Object
>>>>>>>>>> received:
>>>>>>>>>> /org/bluez/example/service0, iface: org.bluez.GattService1
>>>>>>>>>> bluetoothd[16877]: src/gatt-database.c:proxy_added_cb() Object
>>>>>>>>>> received:
>>>>>>>>>> /org/bluez/example/service2/char0/desc1, iface:
>>>>>>>>>> org.bluez.GattDescriptor1
>>>>>>>>>> bluetoothd[16877]: src/gatt-database.c:proxy_added_cb() Object
>>>>>>>>>> received:
>>>>>>>>>> /org/bluez/example/service2/char2/desc2, iface:
>>>>>>>>>> org.bluez.GattDescriptor1
>>>>>>>>>> bluetoothd[16877]: src/gatt-database.c:proxy_added_cb() Object
>>>>>>>>>> received:
>>>>>>>>>> /org/bluez/example/service2/char0, iface:
>>>>>>>>>> org.bluez.GattCharacteristic1
>>>>>>>>>> bluetoothd[16877]: src/gatt-database.c:client_ready_cb() #
>>>>>>>>>> client_ready_cb
>>>>>>>>>> bluetoothd[16877]: src/gatt-database.c:create_service() #
>>>>>>>>>> create_service
>>>>>>>>>> from /org/bluez/example/service2
>>>>>>>>>> bluetoothd[16877]: src/gatt-database.c:create_service() #
>>>>>>>>>> create_service
>>>>>>>>>> from /org/bluez/example/service1
>>>>>>>>>> bluetoothd[16877]: src/gatt-database.c:create_service() #
>>>>>>>>>> create_service
>>>>>>>>>> from /org/bluez/example/service0
>>>>>>>>>> bluetoothd[16877]: src/gatt-database.c:database_add_app() #
>>>>>>>>>> database_add_app
>>>>>>>>>> bluetoothd[16877]: src/gatt-database.c:database_add_service()
>>>>>>>>>> #
>>>>>>>>>> database_add_service
>>>>>>>>>> bluetoothd[16877]: src/gatt-database.c:cep_write_cb() Stored
>>>>>>>>>> CEP
>>>>>>>>>> value
>>>>>>>>>> in
>>>>>>>>>> the database
>>>>>>>>>> bluetoothd[16877]: src/gatt-database.c:database_add_cep()
>>>>>>>>>> Created
>>>>>>>>>> CEP
>>>>>>>>>> entry
>>>>>>>>>> for characteristic
>>>>>>>>>> bluetoothd[16877]: src/gatt-database.c:cep_write_cb() Stored
>>>>>>>>>> CEP
>>>>>>>>>> value
>>>>>>>>>> in
>>>>>>>>>> the database
>>>>>>>>>> bluetoothd[16877]: src/gatt-database.c:database_add_cep()
>>>>>>>>>> Created
>>>>>>>>>> CEP
>>>>>>>>>> entry
>>>>>>>>>> for characteristic
>>>>>>>>>> bluetoothd[16877]: src/gatt-database.c:cep_write_cb() Stored
>>>>>>>>>> CEP
>>>>>>>>>> value
>>>>>>>>>> in
>>>>>>>>>> the database
>>>>>>>>>> bluetoothd[16877]: src/gatt-database.c:database_add_cep()
>>>>>>>>>> Created
>>>>>>>>>> CEP
>>>>>>>>>> entry
>>>>>>>>>> for characteristic
>>>>>>>>>> bluetoothd[16877]: src/gatt-database.c:gatt_db_service_added()
>>>>>>>>>> #
>>>>>>>>>> gatt_db_service_added: GATT Service added to local database
>>>>>>>>>> bluetoothd[16877]: src/gatt-database.c:database_add_service()
>>>>>>>>>> #
>>>>>>>>>> database_add_service
>>>>>>>>>> bluetoothd[16877]: src/gatt-database.c:database_add_ccc()
>>>>>>>>>> Created
>>>>>>>>>> CCC
>>>>>>>>>> entry
>>>>>>>>>> for characteristic
>>>>>>>>>> bluetoothd[16877]: src/gatt-database.c:gatt_db_service_added()
>>>>>>>>>> #
>>>>>>>>>> gatt_db_service_added: GATT Service added to local database
>>>>>>>>>> bluetoothd[16877]: src/gatt-database.c:database_add_service()
>>>>>>>>>> #
>>>>>>>>>> database_add_service
>>>>>>>>>> bluetoothd[16877]: src/gatt-database.c:database_add_ccc()
>>>>>>>>>> Created
>>>>>>>>>> CCC
>>>>>>>>>> entry
>>>>>>>>>> for characteristic
>>>>>>>>>> bluetoothd[16877]: src/gatt-database.c:gatt_db_service_added()
>>>>>>>>>> #
>>>>>>>>>> gatt_db_service_added: GATT Service added to local database
>>>>>>>>>> bluetoothd[16877]: src/gatt-database.c:client_ready_cb() GATT
>>>>>>>>>> application
>>>>>>>>>> registered: :1.404:/
>>>>>>>>>> bluetoothd[16877]: src/advertising.c:parse_service_uuids()
>>>>>>>>>> Adding
>>>>>>>>>> ServiceUUID: 180D
>>>>>>>>>> bluetoothd[16877]: src/advertising.c:parse_service_uuids()
>>>>>>>>>> Adding
>>>>>>>>>> ServiceUUID: 180F
>>>>>>>>>> bluetoothd[16877]: src/advertising.c:parse_manufacturer_data()
>>>>>>>>>> Adding
>>>>>>>>>> ManufacturerData for ffff
>>>>>>>>>> bluetoothd[16877]: src/advertising.c:parse_service_data()
>>>>>>>>>> Adding
>>>>>>>>>> ServiceData
>>>>>>>>>> for 9999
>>>>>>>>>> bluetoothd[16877]: src/advertising.c:refresh_advertisement()
>>>>>>>>>> Refreshing
>>>>>>>>>> advertisement: /org/bluez/example/advertisement0
>>>>>>>>>> bluetoothd[16877]: src/advertising.c:add_adv_callback()
>>>>>>>>>> Advertisement
>>>>>>>>>> registered: /org/bluez/example/advertisement0
>>>>>>>>>>
>>>>>>>>>> I start `./test/example-gatt-server` as a normal user. But
>>>>>>>>>> Bluez
>>>>>>>>>> does
>>>>>>>>>> not
>>>>>>>>>> seem to have any permission issue with it.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Building from source I've seen something similar if I've used
>>>>>>>>> sudo
>>>>>>>>> for
>>>>>>>>> the
>>>>>>>>> make.
>>>>>>>>>
>>>>>>>>> To compile and install I use sudo for the install only:
>>>>>>>>>
>>>>>>>>> make -j 4 && sudo make install
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I am using 'BLE scanner' on Android to discover the GATT
>>>>>>>>>> services.
>>>>>>>>>> But
>>>>>>>>>> I
>>>>>>>>>> think the problem is coming from Bluez. When I connect the
>>>>>>>>>> Android
>>>>>>>>>> device
>>>>>>>>>> to
>>>>>>>>>> Bluez, I can see this log:
>>>>>>>>>>
>>>>>>>>>> bluetoothd[16877]: src/adapter.c:connected_callback() hci0
>>>>>>>>>> device
>>>>>>>>>> 98:D6:F7:31:7B:0D connected eir_len 14
>>>>>>>>>> bluetoothd[16877]: src/gatt-database.c:connect_cb() New
>>>>>>>>>> incoming
>>>>>>>>>> BR/EDR
>>>>>>>>>> ATT
>>>>>>>>>> connection
>>>>>>>>>> bluetoothd[16877]: attrib/gattrib.c:g_attrib_ref() 0x98cd908:
>>>>>>>>>> g_attrib_ref=1
>>>>>>>>>> bluetoothd[16877]: src/device.c:load_gatt_db() # load_gatt_db:
>>>>>>>>>> Restoring
>>>>>>>>>> 98:D6:F7:31:7B:0D gatt database from file
>>>>>>>>>> '/var/lib/bluetooth/5C:F3:70:6A:D9:3C/cache/98:D6:F7:31:7B:0D'
>>>>>>>>>> bluetoothd[16877]: src/device.c:load_gatt_db_impl() #
>>>>>>>>>> load_gatt_db_impl
>>>>>>>>>> bluetoothd[16877]: src/device.c:load_service() # load_service:
>>>>>>>>>> loading
>>>>>>>>>> service: 0x0001, end: 0x0005, uuid:
>>>>>>>>>> 00001801-0000-1000-8000-00805f9b34fb
>>>>>>>>>> bluetoothd[16877]: src/device.c:load_service() # load_service:
>>>>>>>>>> loading
>>>>>>>>>> service: 0x0014, end: 0xffff, uuid:
>>>>>>>>>> 00001800-0000-1000-8000-00805f9b34fb
>>>>>>>>>> bluetoothd[16877]: src/device.c:load_chrc() loading
>>>>>>>>>> characteristic
>>>>>>>>>> handle:
>>>>>>>>>> 0x0002, value handle: 0x0003, properties 0x0020 uuid:
>>>>>>>>>> 00002a05-0000-1000-8000-00805f9b34fb
>>>>>>>>>> bluetoothd[16877]: src/device.c:load_chrc() loading
>>>>>>>>>> characteristic
>>>>>>>>>> handle:
>>>>>>>>>> 0x0015, value handle: 0x0016, properties 0x0002 uuid:
>>>>>>>>>> 00002a00-0000-1000-8000-00805f9b34fb
>>>>>>>>>> bluetoothd[16877]: src/device.c:load_chrc() loading
>>>>>>>>>> characteristic
>>>>>>>>>> handle:
>>>>>>>>>> 0x0017, value handle: 0x0018, properties 0x0002 uuid:
>>>>>>>>>> 00002a01-0000-1000-8000-00805f9b34fb
>>>>>>>>>> bluetoothd[16877]: src/device.c:load_gatt_db() List GATT
>>>>>>>>>> Primaries
>>>>>>>>>> before
>>>>>>>>>> being free:
>>>>>>>>>> bluetoothd[16877]: src/device.c:print_primary() - Primary
>>>>>>>>>> UUID:
>>>>>>>>>> 00001801-0000-1000-8000-00805f9b34fb
>>>>>>>>>> bluetoothd[16877]: src/device.c:print_primary() - Primary
>>>>>>>>>> UUID:
>>>>>>>>>> 00001800-0000-1000-8000-00805f9b34fb
>>>>>>>>>> bluetoothd[16877]: src/device.c:add_primary() # add_primary
>>>>>>>>>> bluetoothd[16877]: src/device.c:add_primary() # add_primary
>>>>>>>>>> bluetoothd[16877]: profiles/gap/gas.c:gap_accept() GAP profile
>>>>>>>>>> accept
>>>>>>>>>> (98:D6:F7:31:7B:0D)
>>>>>>>>>> bluetoothd[16877]: src/service.c:change_state() 0x98c98e0:
>>>>>>>>>> device
>>>>>>>>>> 98:D6:F7:31:7B:0D profile gap-profile state changed:
>>>>>>>>>> disconnected
>>>>>>>>>> ->
>>>>>>>>>> connected (0)
>>>>>>>>>> bluetoothd[16877]:
>>>>>>>>>> src/gatt-client.c:btd_gatt_client_connected()
>>>>>>>>>> Device
>>>>>>>>>> connected.
>>>>>>>>>> bluetoothd[16877]: src/device.c:gatt_server_init() #
>>>>>>>>>> gatt_server_init
>>>>>>>>>> bluetoothd[16877]: src/device.c:gatt_debug() Primary services
>>>>>>>>>> found:
>>>>>>>>>> 2
>>>>>>>>>> bluetoothd[16877]: src/device.c:gatt_debug() start: 0x0001,
>>>>>>>>>> end:
>>>>>>>>>> 0x0005,
>>>>>>>>>> uuid: 00001801-0000-1000-8000-00805f9b34fb
>>>>>>>>>> bluetoothd[16877]: src/device.c:gatt_debug() start: 0x0014,
>>>>>>>>>> end:
>>>>>>>>>> 0xffff,
>>>>>>>>>> uuid: 00001800-0000-1000-8000-00805f9b34fb
>>>>>>>>>> bluetoothd[16877]: src/device.c:gatt_debug() Registered
>>>>>>>>>> handler for
>>>>>>>>>> "Service
>>>>>>>>>> Changed": 0
>>>>>>>>>> bluetoothd[16877]: src/device.c:gatt_client_ready_cb() status:
>>>>>>>>>> success,
>>>>>>>>>> error: 0
>>>>>>>>>> bluetoothd[16877]: src/device.c:register_gatt_services() #
>>>>>>>>>> register_gatt_services
>>>>>>>>>> bluetoothd[16877]: src/device.c:add_primary() # add_primary
>>>>>>>>>> bluetoothd[16877]: src/device.c:add_primary() # add_primary
>>>>>>>>>> bluetoothd[16877]: src/device.c:add_gatt_service() #
>>>>>>>>>> add_gatt_service:
>>>>>>>>>> UUID:00001801-0000-1000-8000-00805f9b34fb
>>>>>>>>>> bluetoothd[16877]: src/gatt-client.c:btd_gatt_client_ready()
>>>>>>>>>> GATT
>>>>>>>>>> client
>>>>>>>>>> ready
>>>>>>>>>> bluetoothd[16877]: src/gatt-client.c:create_services()
>>>>>>>>>> Exporting
>>>>>>>>>> objects
>>>>>>>>>> for
>>>>>>>>>> GATT services: 98:D6:F7:31:7B:0D
>>>>>>>>>> bluetoothd[16877]: src/gatt-client.c:service_create() Exported
>>>>>>>>>> GATT
>>>>>>>>>> service:
>>>>>>>>>> /org/bluez/hci0/dev_98_D6_F7_31_7B_0D/service0001
>>>>>>>>>> bluetoothd[16877]: src/gatt-client.c:characteristic_create()
>>>>>>>>>> Exported
>>>>>>>>>> GATT
>>>>>>>>>> characteristic:
>>>>>>>>>> /org/bluez/hci0/dev_98_D6_F7_31_7B_0D/service0001/char0002
>>>>>>>>>> bluetoothd[16877]: src/device.c:device_svc_resolved()
>>>>>>>>>> /org/bluez/hci0/dev_98_D6_F7_31_7B_0D err 0
>>>>>>>>>> bluetoothd[16877]: src/device.c:store_gatt_db() #
>>>>>>>>>> store_gatt_db
>>>>>>>>>> bluetoothd[16877]: src/device.c:store_service() #
>>>>>>>>>> store_service
>>>>>>>>>> bluetoothd[16877]: src/device.c:store_service() #
>>>>>>>>>> store_service
>>>>>>>>>> bluetoothd[16877]: profiles/gap/gas.c:read_device_name_cb()
>>>>>>>>>> GAP
>>>>>>>>>> Device
>>>>>>>>>> Name:
>>>>>>>>>> Nexus 4
>>>>>>>>>> bluetoothd[16877]: profiles/gap/gas.c:read_appearance_cb() GAP
>>>>>>>>>> Appearance:
>>>>>>>>>> 0x0000
>>>>>>>>>>
>>>>>>>>>> I also reduced DBus 'TestAdvertisement' interface to only
>>>>>>>>>> expose
>>>>>>>>>> one
>>>>>>>>>> GATT
>>>>>>>>>> Service as many BLE adapter got a limitation in the size of
>>>>>>>>>> the
>>>>>>>>>> advertisement packet:
>>>>>>>>>> class TestAdvertisement(Advertisement):
>>>>>>>>>>
>>>>>>>>>> def __init__(self, bus, index):
>>>>>>>>>> Advertisement.__init__(self, bus, index, 'peripheral')
>>>>>>>>>> #self.add_service_uuid('180D') # HeartRate
>>>>>>>>>> self.add_service_uuid('180F') # Battery
>>>>>>>>>> #self.add_manufacturer_data(0xffff, [0x00, 0x01, 0x02,
>>>>>>>>>> 0x03,
>>>>>>>>>> 0x04])
>>>>>>>>>> #self.add_service_data('9999', [0x00, 0x01, 0x02,
>>>>>>>>>> 0x03,
>>>>>>>>>> 0x04])
>>>>>>>>>> self.include_tx_power = True
>>>>>>>>>>
>>>>>>>>>> My concern is mainly these lines:
>>>>>>>>>>
>>>>>>>>>> bluetoothd[16877]: src/device.c:gatt_debug() Primary services
>>>>>>>>>> found:
>>>>>>>>>> 2
>>>>>>>>>> bluetoothd[16877]: src/device.c:gatt_debug() start: 0x0001,
>>>>>>>>>> end:
>>>>>>>>>> 0x0005,
>>>>>>>>>> uuid: 00001801-0000-1000-8000-00805f9b34fb
>>>>>>>>>> bluetoothd[16877]: src/device.c:gatt_debug() start: 0x0014,
>>>>>>>>>> end:
>>>>>>>>>> 0xffff,
>>>>>>>>>> uuid: 00001800-0000-1000-8000-00805f9b34fb
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I've seen this kind of error message when I've had a failure of
>>>>>>>>> a
>>>>>>>>> previous script and the Bluetooth daemon is in some unknown
>>>>>>>>> state.
>>>>>>>>> At
>>>>>>>>> this point it is worth restarting the bluetooth service with:
>>>>>>>>> sudo service bluetooth restart
>>>>>>>>>
>>>>>>>>> You will see in the advertising DBus API documentation that it
>>>>>>>>> is
>>>>>>>>> still in experimental mode in 5.44.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/doc/advertising-api.txt#n78
>>>>>>>>>
>>>>>>>>> This means that you need to make sure bluetoothd is started in
>>>>>>>>> experimental mode. Have you done this?
>>>>>>>>> You can check with "sudo service bluetooth status"
>>>>>>>>>
>>>>>>>>> Experimental can be switched on by default in the
>>>>>>>>> bluetooth.service
>>>>>>>>> file
>>>>>>>>>
>>>>>>>>> Edit /lib/systemd/system/bluetooth.service file to add
>>>>>>>>> --experimental
>>>>>>>>> flag
>>>>>>>>> e.g:
>>>>>>>>>
>>>>>>>>> sudo sed -i '/^ExecStart.*bluetoothd\s*$/ s/$/ --experimental/'
>>>>>>>>> /lib/systemd/system/bluetooth.service
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> I have not found the code that export GATT Services from GATT
>>>>>>>>>> Database
>>>>>>>>>> to
>>>>>>>>>> the BLE central.
>>>>>>>>>>
>>>>>>>>>> From my search on Internet, it looks I am not the only one who
>>>>>>>>>> is
>>>>>>>>>> having
>>>>>>>>>> this issue
>>>>>>>>>> I am happy to share/test anything that could help to make some
>>>>>>>>>> progress.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Olivier
>>>>>>>>>> --
>>>>>>>>>> To unsubscribe from this list: send the line "unsubscribe
>>>>>>>>>> linux-bluetooth"
>>>>>>>>>> in
>>>>>>>>>> the body of a message to majordomo@vger.kernel.org
>>>>>>>>>> More majordomo info at
>>>>>>>>>> http://vger.kernel.org/majordomo-info.html
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe
>> linux-bluetooth"
>> in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
[-- Attachment #2: btmon.log --]
[-- Type: text/plain, Size: 36147 bytes --]
= New Index: 5C:F3:70:6A:D9:3C (Primary,USB,hci0) [hci0] 0.264415
= Open Index: 5C:F3:70:6A:D9:3C [hci0] 0.264417
= Index Info: 5C:F3:70:6A:D9:3C (Broadcom Corporation) [hci0] 0.264418
> HCI Event: LE Meta Event (0x3e) plen 19 [hci0] 5.331404
LE Connection Complete (0x01)
Status: Success (0x00)
Handle: 64
Role: Slave (0x01)
Peer address type: Random (0x01)
Peer address: 5E:3A:99:E3:23:CD (Resolvable)
Connection interval: 48.75 msec (0x0027)
Connection latency: 0.00 msec (0x0000)
Supervision timeout: 20000 msec (0x07d0)
Master clock accuracy: 0x05
< ACL Data TX: Handle 64 flags 0x00 dlen 16 [hci0] 5.331611
LE L2CAP: Connection Parameter Update Request (0x12) ident 1 len 8
Min interval: 40
Max interval: 56
Slave latency: 0
Timeout multiplier: 2000
@ Device Connected: 5E:3A:99:E3:23:CD (2) flags 0x0000
< ACL Data TX: Handle 64 flags 0x00 dlen 7 [hci0] 5.332136
ATT: Exchange MTU Request (0x02) len 2
Client RX MTU: 517
> HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 5.396396
Num handles: 1
Handle: 64
Count: 2
> ACL Data RX: Handle 64 flags 0x02 dlen 10 [hci0] 5.444224
LE L2CAP: Connection Parameter Update Response (0x13) ident 1 len 2
Result: Connection Parameters accepted (0x0000)
> ACL Data RX: Handle 64 flags 0x02 dlen 7 [hci0] 5.542005
ATT: Exchange MTU Response (0x03) len 2
Server RX MTU: 517
< ACL Data TX: Handle 64 flags 0x00 dlen 11 [hci0] 5.542343
ATT: Read By Group Type Request (0x10) len 6
Handle range: 0x0001-0xffff
Attribute group type: Primary Service (0x2800)
> ACL Data RX: Handle 64 flags 0x02 dlen 11 [hci0] 5.590647
ATT: Read By Group Type Request (0x10) len 6
Handle range: 0x0001-0xffff
Attribute group type: Primary Service (0x2800)
< ACL Data TX: Handle 64 flags 0x00 dlen 24 [hci0] 5.590898
ATT: Read By Group Type Response (0x11) len 19
Attribute data length: 6
Attribute group list: 3 entries
Handle range: 0x0001-0x0005
UUID: Generic Access Profile (0x1800)
Handle range: 0x0006-0x0009
UUID: Generic Attribute Profile (0x1801)
Handle range: 0x000a-0x000d
UUID: Battery Service (0x180f)
> ACL Data RX: Handle 64 flags 0x02 dlen 18 [hci0] 5.639527
ATT: Read By Group Type Response (0x11) len 13
Attribute data length: 6
Attribute group list: 2 entries
Handle range: 0x0001-0x0005
UUID: Generic Attribute Profile (0x1801)
Handle range: 0x0014-0xffff
UUID: Generic Access Profile (0x1800)
< ACL Data TX: Handle 64 flags 0x00 dlen 11 [hci0] 5.639932
ATT: Read By Group Type Request (0x10) len 6
Handle range: 0x0001-0xffff
Attribute group type: Secondary Service (0x2801)
> ACL Data RX: Handle 64 flags 0x02 dlen 11 [hci0] 5.688156
ATT: Read By Group Type Request (0x10) len 6
Handle range: 0x000e-0xffff
Attribute group type: Primary Service (0x2800)
< ACL Data TX: Handle 64 flags 0x00 dlen 26 [hci0] 5.688413
ATT: Read By Group Type Response (0x11) len 21
Attribute data length: 20
Attribute group list: 1 entry
Handle range: 0x000e-0x001d
UUID: Vendor specific (12345678-1234-5678-1234-56789abcdef0)
> HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 5.689357
Num handles: 1
Handle: 64
Count: 2
> ACL Data RX: Handle 64 flags 0x02 dlen 9 [hci0] 5.736775
ATT: Error Response (0x01) len 4
Read By Group Type Request (0x10)
Handle: 0x0001
Error: Unsupported Group Type (0x10)
< ACL Data TX: Handle 64 flags 0x00 dlen 11 [hci0] 5.737047
ATT: Read By Type Request (0x08) len 6
Handle range: 0x0001-0x0005
Attribute type: Include (0x2802)
> HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 5.816420
Num handles: 1
Handle: 64
Count: 2
> ACL Data RX: Handle 64 flags 0x02 dlen 11 [hci0] 5.816432
ATT: Read By Group Type Request (0x10) len 6
Handle range: 0x001e-0xffff
Attribute group type: Primary Service (0x2800)
< ACL Data TX: Handle 64 flags 0x00 dlen 12 [hci0] 5.816695
ATT: Read By Group Type Response (0x11) len 7
Attribute data length: 6
Attribute group list: 1 entry
Handle range: 0x001e-0x0025
UUID: Heart Rate (0x180d)
> HCI Event: LE Meta Event (0x3e) plen 10 [hci0] 5.817423
LE Connection Update Complete (0x03)
Status: Success (0x00)
Handle: 64
Connection interval: 67.50 msec (0x0036)
Connection latency: 0.00 msec (0x0000)
Supervision timeout: 20000 msec (0x07d0)
> ACL Data RX: Handle 64 flags 0x02 dlen 9 [hci0] 5.883029
ATT: Error Response (0x01) len 4
Read By Type Request (0x08)
Handle: 0x0001
Error: Attribute Not Found (0x0a)
< ACL Data TX: Handle 64 flags 0x00 dlen 11 [hci0] 5.883233
ATT: Read By Type Request (0x08) len 6
Handle range: 0x0014-0xffff
Attribute type: Include (0x2802)
> ACL Data RX: Handle 64 flags 0x02 dlen 11 [hci0] 5.950685
ATT: Read By Group Type Request (0x10) len 6
Handle range: 0x0026-0xffff
Attribute group type: Primary Service (0x2800)
< ACL Data TX: Handle 64 flags 0x00 dlen 9 [hci0] 5.950965
ATT: Error Response (0x01) len 4
Read By Group Type Request (0x10)
Handle: 0x0026
Error: Attribute Not Found (0x0a)
> HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 5.951360
Num handles: 1
Handle: 64
Count: 2
> ACL Data RX: Handle 64 flags 0x02 dlen 9 [hci0] 6.085807
ATT: Error Response (0x01) len 4
Read By Type Request (0x08)
Handle: 0x0014
Error: Attribute Not Found (0x0a)
< ACL Data TX: Handle 64 flags 0x00 dlen 11 [hci0] 6.086017
ATT: Read By Type Request (0x08) len 6
Handle range: 0x0001-0x0005
Attribute type: Characteristic (0x2803)
> HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 6.086234
Num handles: 1
Handle: 64
Count: 2
> ACL Data RX: Handle 64 flags 0x02 dlen 11 [hci0] 6.153046
ATT: Read By Type Request (0x08) len 6
Handle range: 0x0001-0x0005
Attribute type: Include (0x2802)
< ACL Data TX: Handle 64 flags 0x00 dlen 9 [hci0] 6.153339
ATT: Error Response (0x01) len 4
Read By Type Request (0x08)
Handle: 0x0001
Error: Attribute Not Found (0x0a)
> ACL Data RX: Handle 64 flags 0x02 dlen 13 [hci0] 7.165684
ATT: Read By Type Response (0x09) len 8
Attribute data length: 7
Attribute data list: 1 entry
Handle: 0x0002
Value: 200300052a
< ACL Data TX: Handle 64 flags 0x00 dlen 11 [hci0] 7.165875
ATT: Read By Type Request (0x08) len 6
Handle range: 0x0003-0x0005
Attribute type: Characteristic (0x2803)
> HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 7.345432
Num handles: 1
Handle: 64
Count: 1
> ACL Data RX: Handle 64 flags 0x02 dlen 11 [hci0] 9.663320
ATT: Read By Type Request (0x08) len 6
Handle range: 0x0001-0x0005
Attribute type: Characteristic (0x2803)
< ACL Data TX: Handle 64 flags 0x00 dlen 20 [hci0] 9.663577
ATT: Read By Type Response (0x09) len 15
Attribute data length: 7
Attribute data list: 2 entries
Handle: 0x0002
Value: 020300002a
Handle: 0x0004
Value: 020500012a
> HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 9.845460
Num handles: 1
Handle: 64
Count: 1
> ACL Data RX: Handle 64 flags 0x02 dlen 9 [hci0] 12.160742
ATT: Error Response (0x01) len 4
Read By Type Request (0x08)
Handle: 0x0003
Error: Attribute Not Found (0x0a)
< ACL Data TX: Handle 64 flags 0x00 dlen 9 [hci0] 12.161073
ATT: Find Information Request (0x04) len 4
Handle range: 0x0004-0x0005
> HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 12.345483
Num handles: 1
Handle: 64
Count: 1
> ACL Data RX: Handle 64 flags 0x02 dlen 11 [hci0] 14.658367
ATT: Read By Type Request (0x08) len 6
Handle range: 0x0005-0x0005
Attribute type: Characteristic (0x2803)
< ACL Data TX: Handle 64 flags 0x00 dlen 9 [hci0] 14.658616
ATT: Error Response (0x01) len 4
Read By Type Request (0x08)
Handle: 0x0005
Error: Attribute Not Found (0x0a)
> HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 14.845516
Num handles: 1
Handle: 64
Count: 1
> ACL Data RX: Handle 64 flags 0x02 dlen 9 [hci0] 17.155765
ATT: Error Response (0x01) len 4
Find Information Request (0x04)
Handle: 0x0004
Error: Attribute Not Found (0x0a)
< ACL Data TX: Handle 64 flags 0x00 dlen 11 [hci0] 17.155920
ATT: Read By Type Request (0x08) len 6
Handle range: 0x0014-0xffff
Attribute type: Characteristic (0x2803)
> HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 17.346532
Num handles: 1
Handle: 64
Count: 1
> ACL Data RX: Handle 64 flags 0x02 dlen 11 [hci0] 19.653425
ATT: Read By Type Request (0x08) len 6
Handle range: 0x0006-0x0009
Attribute type: Include (0x2802)
< ACL Data TX: Handle 64 flags 0x00 dlen 9 [hci0] 19.653637
ATT: Error Response (0x01) len 4
Read By Type Request (0x08)
Handle: 0x0006
Error: Attribute Not Found (0x0a)
> HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 19.846562
Num handles: 1
Handle: 64
Count: 1
> ACL Data RX: Handle 64 flags 0x02 dlen 20 [hci0] 22.151046
ATT: Read By Type Response (0x09) len 15
Attribute data length: 7
Attribute data list: 2 entries
Handle: 0x0015
Value: 021600002a
Handle: 0x0017
Value: 021800012a
< ACL Data TX: Handle 64 flags 0x00 dlen 11 [hci0] 22.151258
ATT: Read By Type Request (0x08) len 6
Handle range: 0x0018-0xffff
Attribute type: Characteristic (0x2803)
> HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 22.346609
Num handles: 1
Handle: 64
Count: 1
> ACL Data RX: Handle 64 flags 0x02 dlen 11 [hci0] 24.648466
ATT: Read By Type Request (0x08) len 6
Handle range: 0x0006-0x0009
Attribute type: Characteristic (0x2803)
< ACL Data TX: Handle 64 flags 0x00 dlen 13 [hci0] 24.648692
ATT: Read By Type Response (0x09) len 8
Attribute data length: 7
Attribute data list: 1 entry
Handle: 0x0007
Value: 200800052a
> HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 24.846622
Num handles: 1
Handle: 64
Count: 1
> ACL Data RX: Handle 64 flags 0x02 dlen 9 [hci0] 27.145990
ATT: Error Response (0x01) len 4
Read By Type Request (0x08)
Handle: 0x0018
Error: Attribute Not Found (0x0a)
< ACL Data TX: Handle 64 flags 0x00 dlen 9 [hci0] 27.146285
ATT: Find Information Request (0x04) len 4
Handle range: 0x0019-0xffff
> HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 27.346656
Num handles: 1
Handle: 64
Count: 1
> ACL Data RX: Handle 64 flags 0x02 dlen 11 [hci0] 29.643540
ATT: Read By Type Request (0x08) len 6
Handle range: 0x0008-0x0009
Attribute type: Characteristic (0x2803)
< ACL Data TX: Handle 64 flags 0x00 dlen 9 [hci0] 29.643821
ATT: Error Response (0x01) len 4
Read By Type Request (0x08)
Handle: 0x0008
Error: Attribute Not Found (0x0a)
> HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 29.847674
Num handles: 1
Handle: 64
Count: 1
> ACL Data RX: Handle 64 flags 0x02 dlen 9 [hci0] 32.141054
ATT: Error Response (0x01) len 4
Find Information Request (0x04)
Handle: 0x0019
Error: Attribute Not Found (0x0a)
< ACL Data TX: Handle 64 flags 0x00 dlen 7 [hci0] 32.142594
ATT: Read Request (0x0a) len 2
Handle: 0x0016
> HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 32.347697
Num handles: 1
Handle: 64
Count: 1
> ACL Data RX: Handle 64 flags 0x02 dlen 9 [hci0] 34.638561
ATT: Find Information Request (0x04) len 4
Handle range: 0x0009-0x0009
< ACL Data TX: Handle 64 flags 0x00 dlen 10 [hci0] 34.638810
ATT: Find Information Response (0x05) len 5
Format: UUID-16 (0x01)
Handle: 0x0009
UUID: Client Characteristic Configuration (0x2902)
> HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 34.847732
Num handles: 1
Handle: 64
Count: 1
> ACL Data RX: Handle 64 flags 0x02 dlen 12 [hci0] 37.136212
ATT: Read Response (0x0b) len 7
Value: 4e657875732034
< ACL Data TX: Handle 64 flags 0x00 dlen 7 [hci0] 37.136595
ATT: Read Request (0x0a) len 2
Handle: 0x0018
> HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 37.347740
Num handles: 1
Handle: 64
Count: 1
> ACL Data RX: Handle 64 flags 0x02 dlen 11 [hci0] 39.633742
ATT: Read By Type Request (0x08) len 6
Handle range: 0x000a-0x000d
Attribute type: Include (0x2802)
< ACL Data TX: Handle 64 flags 0x00 dlen 9 [hci0] 39.633996
ATT: Error Response (0x01) len 4
Read By Type Request (0x08)
Handle: 0x000a
Error: Attribute Not Found (0x0a)
> HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 39.847757
Num handles: 1
Handle: 64
Count: 1
> HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 42.347796
Num handles: 1
Handle: 64
Count: 1
> ACL Data RX: Handle 64 flags 0x02 dlen 7 [hci0] 44.628674
ATT: Read Response (0x0b) len 2
Value: 0000
> HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 44.848813
Num handles: 1
Handle: 64
Count: 1
> ACL Data RX: Handle 64 flags 0x02 dlen 11 [hci0] 47.126454
ATT: Read By Type Request (0x08) len 6
Handle range: 0x000a-0x000d
Attribute type: Characteristic (0x2803)
< ACL Data TX: Handle 64 flags 0x00 dlen 13 [hci0] 47.126657
ATT: Read By Type Response (0x09) len 8
Attribute data length: 7
Attribute data list: 1 entry
Handle: 0x000b
Value: 120c00192a
> ACL Data RX: Handle 64 flags 0x02 dlen 11 [hci0] 52.121491
ATT: Read By Type Request (0x08) len 6
Handle range: 0x000c-0x000d
Attribute type: Characteristic (0x2803)
< ACL Data TX: Handle 64 flags 0x00 dlen 9 [hci0] 52.121737
ATT: Error Response (0x01) len 4
Read By Type Request (0x08)
Handle: 0x000c
Error: Attribute Not Found (0x0a)
> HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 52.348909
Num handles: 1
Handle: 64
Count: 1
> ACL Data RX: Handle 64 flags 0x02 dlen 9 [hci0] 57.116442
ATT: Find Information Request (0x04) len 4
Handle range: 0x000d-0x000d
< ACL Data TX: Handle 64 flags 0x00 dlen 10 [hci0] 57.116715
ATT: Find Information Response (0x05) len 5
Format: UUID-16 (0x01)
Handle: 0x000d
UUID: Client Characteristic Configuration (0x2902)
> HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 57.349962
Num handles: 1
Handle: 64
Count: 1
> ACL Data RX: Handle 64 flags 0x02 dlen 11 [hci0] 62.111720
ATT: Read By Type Request (0x08) len 6
Handle range: 0x000e-0x001d
Attribute type: Include (0x2802)
< ACL Data TX: Handle 64 flags 0x00 dlen 9 [hci0] 62.111935
ATT: Error Response (0x01) len 4
Read By Type Request (0x08)
Handle: 0x000e
Error: Attribute Not Found (0x0a)
> HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 62.349984
Num handles: 1
Handle: 64
Count: 1
> ACL Data RX: Handle 64 flags 0x02 dlen 11 [hci0] 67.106773
ATT: Read By Type Request (0x08) len 6
Handle range: 0x000e-0x001d
Attribute type: Characteristic (0x2803)
< ACL Data TX: Handle 64 flags 0x00 dlen 27 [hci0] 67.107075
< ACL Data TX: Handle 64 flags 0x01 dlen 27 [hci0] 67.107088
< ACL Data TX: Handle 64 flags 0x01 dlen 15 [hci0] 67.107091
ATT: Read By Type Response (0x09) len 64
Attribute data length: 21
Attribute data list: 3 entries
Handle: 0x000f
Value: 8a1000f5debc9a785634127856341278563412
Handle: 0x0014
Value: 8a1500f1debc9a785634127856341278563412
Handle: 0x0019
Value: 8a1a00f3debc9a785634127856341278563412
> HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 67.350037
Num handles: 1
Handle: 64
Count: 1
> HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 69.606070
Num handles: 1
Handle: 64
Count: 2
> ACL Data RX: Handle 64 flags 0x02 dlen 11 [hci0] 72.101945
ATT: Read By Type Request (0x08) len 6
Handle range: 0x001a-0x001d
Attribute type: Characteristic (0x2803)
< ACL Data TX: Handle 64 flags 0x00 dlen 9 [hci0] 72.102244
ATT: Error Response (0x01) len 4
Read By Type Request (0x08)
Handle: 0x001a
Error: Attribute Not Found (0x0a)
> HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 72.351106
Num handles: 1
Handle: 64
Count: 1
> ACL Data RX: Handle 64 flags 0x02 dlen 9 [hci0] 77.096746
ATT: Find Information Request (0x04) len 4
Handle range: 0x0011-0x0013
< ACL Data TX: Handle 64 flags 0x00 dlen 10 [hci0] 77.097040
ATT: Find Information Response (0x05) len 5
Format: UUID-16 (0x01)
Handle: 0x0011
UUID: Characteristic Extended Properties (0x2900)
> HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 77.226135
Num handles: 1
Handle: 64
Count: 1
> ACL Data RX: Handle 64 flags 0x02 dlen 9 [hci0] 82.091793
ATT: Find Information Request (0x04) len 4
Handle range: 0x0012-0x0013
< ACL Data TX: Handle 64 flags 0x00 dlen 24 [hci0] 82.092049
ATT: Find Information Response (0x05) len 19
Format: UUID-128 (0x02)
Handle: 0x0012
UUID: Vendor specific (12345678-1234-5678-1234-56789abcdef6)
> HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 82.227194
Num handles: 1
Handle: 64
Count: 1
> ACL Data RX: Handle 64 flags 0x02 dlen 9 [hci0] 87.086846
ATT: Find Information Request (0x04) len 4
Handle range: 0x0013-0x0013
< ACL Data TX: Handle 64 flags 0x00 dlen 10 [hci0] 87.087178
ATT: Find Information Response (0x05) len 5
Format: UUID-16 (0x01)
Handle: 0x0013
UUID: Characteristic User Description (0x2901)
> HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 87.227231
Num handles: 1
Handle: 64
Count: 1
> ACL Data RX: Handle 64 flags 0x02 dlen 9 [hci0] 92.081896
ATT: Find Information Request (0x04) len 4
Handle range: 0x0016-0x0018
< ACL Data TX: Handle 64 flags 0x00 dlen 10 [hci0] 92.082197
ATT: Find Information Response (0x05) len 5
Format: UUID-16 (0x01)
Handle: 0x0016
UUID: Characteristic Extended Properties (0x2900)
> HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 92.227292
Num handles: 1
Handle: 64
Count: 1
> ACL Data RX: Handle 64 flags 0x02 dlen 9 [hci0] 97.077070
ATT: Find Information Request (0x04) len 4
Handle range: 0x0017-0x0018
< ACL Data TX: Handle 64 flags 0x00 dlen 24 [hci0] 97.077318
ATT: Find Information Response (0x05) len 19
Format: UUID-128 (0x02)
Handle: 0x0017
UUID: Vendor specific (12345678-1234-5678-1234-56789abcdef2)
> HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 97.228332
Num handles: 1
Handle: 64
Count: 1
> ACL Data RX: Handle 64 flags 0x02 dlen 9 [hci0] 102.072117
ATT: Find Information Request (0x04) len 4
Handle range: 0x0018-0x0018
< ACL Data TX: Handle 64 flags 0x00 dlen 10 [hci0] 102.072328
ATT: Find Information Response (0x05) len 5
Format: UUID-16 (0x01)
Handle: 0x0018
UUID: Characteristic User Description (0x2901)
> HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 102.228382
Num handles: 1
Handle: 64
Count: 1
> ACL Data RX: Handle 64 flags 0x02 dlen 9 [hci0] 107.067171
ATT: Find Information Request (0x04) len 4
Handle range: 0x001b-0x001d
< ACL Data TX: Handle 64 flags 0x00 dlen 10 [hci0] 107.067470
ATT: Find Information Response (0x05) len 5
Format: UUID-16 (0x01)
Handle: 0x001b
UUID: Characteristic Extended Properties (0x2900)
> HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 107.229433
Num handles: 1
Handle: 64
Count: 1
> ACL Data RX: Handle 64 flags 0x02 dlen 9 [hci0] 112.062345
ATT: Find Information Request (0x04) len 4
Handle range: 0x001c-0x001d
< ACL Data TX: Handle 64 flags 0x00 dlen 24 [hci0] 112.062584
ATT: Find Information Response (0x05) len 19
Format: UUID-128 (0x02)
Handle: 0x001c
UUID: Vendor specific (12345678-1234-5678-1234-56789abcdef4)
> HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 112.229508
Num handles: 1
Handle: 64
Count: 1
> ACL Data RX: Handle 64 flags 0x02 dlen 9 [hci0] 117.057396
ATT: Find Information Request (0x04) len 4
Handle range: 0x001d-0x001d
< ACL Data TX: Handle 64 flags 0x00 dlen 10 [hci0] 117.057701
ATT: Find Information Response (0x05) len 5
Format: UUID-16 (0x01)
Handle: 0x001d
UUID: Characteristic User Description (0x2901)
> HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 117.229534
Num handles: 1
Handle: 64
Count: 1
> ACL Data RX: Handle 64 flags 0x02 dlen 11 [hci0] 122.052701
ATT: Read By Type Request (0x08) len 6
Handle range: 0x001e-0x0025
Attribute type: Include (0x2802)
< ACL Data TX: Handle 64 flags 0x00 dlen 9 [hci0] 122.053006
ATT: Error Response (0x01) len 4
Read By Type Request (0x08)
Handle: 0x001e
Error: Attribute Not Found (0x0a)
> HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 122.230576
Num handles: 1
Handle: 64
Count: 1
> ACL Data RX: Handle 64 flags 0x02 dlen 11 [hci0] 127.047783
ATT: Read By Type Request (0x08) len 6
Handle range: 0x001e-0x0025
Attribute type: Characteristic (0x2803)
< ACL Data TX: Handle 64 flags 0x00 dlen 27 [hci0] 127.048072
ATT: Read By Type Response (0x09) len 22
Attribute data length: 7
Attribute data list: 3 entries
Handle: 0x001f
Value: 022000382a
Handle: 0x0021
Value: 102200372a
Handle: 0x0024
Value: 082500392a
> HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 127.230664
Num handles: 1
Handle: 64
Count: 1
> ACL Data RX: Handle 64 flags 0x02 dlen 11 [hci0] 132.042665
ATT: Read By Type Request (0x08) len 6
Handle range: 0x0025-0x0025
Attribute type: Characteristic (0x2803)
< ACL Data TX: Handle 64 flags 0x00 dlen 9 [hci0] 132.042936
ATT: Error Response (0x01) len 4
Read By Type Request (0x08)
Handle: 0x0025
Error: Attribute Not Found (0x0a)
> HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 132.231652
Num handles: 1
Handle: 64
Count: 1
> ACL Data RX: Handle 64 flags 0x02 dlen 9 [hci0] 137.037598
ATT: Find Information Request (0x04) len 4
Handle range: 0x0023-0x0023
< ACL Data TX: Handle 64 flags 0x00 dlen 10 [hci0] 137.037799
ATT: Find Information Response (0x05) len 5
Format: UUID-16 (0x01)
Handle: 0x0023
UUID: Client Characteristic Configuration (0x2902)
> HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 137.231731
Num handles: 1
Handle: 64
Count: 1
^ permalink raw reply
* Re: Serial Port connection with DBus API
From: Barry Byford @ 2017-04-21 20:54 UTC (permalink / raw)
To: Bluez mailing list
In-Reply-To: <20170408071834.GA12144@x1c>
On 8 April 2017 at 08:18, Johan Hedberg <johan.hedberg@gmail.com> wrote:
> Hi Barry,
>
> On Fri, Apr 07, 2017, Barry Byford wrote:
>> = bluetoothd: Invalid value for profile option Channel
>
> Let's look at your code:
>
>> > 'Channel': GLib.Variant('i', 1),
>
> Yep, that's wrong. The expected D-Bus type for 'Channel' is UINT16,
> which is 'q' and not 'i'.
>
>> = bluetoothd: RFCOMM server failed for SerialPort: socket(STREAM,
>> RFCOMM): Protocol not supported (93)
>
> That usually means that your kernel is incorrectly configured and
> lacking RFCOMM support.
You were spot on with this!!! I now have the kernel patched and I'm
past this error.
However I'm now seeing this error appear in btmon when I try to bind
to the RFCOMM socket:
= bluetoothd: RFCOMM server failed for SerialPort: rfcomm_bind:
Address already in use (98)
Has anyone seen this kind of error before?
Thanks in advance,
Barry
>
> Johan
^ permalink raw reply
* Re: Serial Port connection with DBus API
From: Johan Hedberg @ 2017-04-22 5:26 UTC (permalink / raw)
To: Barry Byford; +Cc: Bluez mailing list
In-Reply-To: <CAAu3APahskA_b2Ydt8TzUWBQnkuC10UwjZ37RaOyhAt4s1iyiQ@mail.gmail.com>
Hi Barry,
On Fri, Apr 21, 2017, Barry Byford wrote:
> >> > 'Channel': GLib.Variant('i', 1),
...
> However I'm now seeing this error appear in btmon when I try to bind
> to the RFCOMM socket:
>
> = bluetoothd: RFCOMM server failed for SerialPort: rfcomm_bind:
> Address already in use (98)
I think that means that you already have some other service listening on
RFCOMM channel 1. Try using some other channel, or identify and stop the
other service that's using channel 1. You can find the per-profile
recommended channels (to avoid conflicts) in doc/assigned-numbers.txt in
the BlueZ source tree. Pure SPP doesn't seem to be listed there, so you
could just pick one that's not yet allocated.
Johan
^ permalink raw reply
* pull request: bluetooth-next 2017-04-22
From: Johan Hedberg @ 2017-04-22 13:13 UTC (permalink / raw)
To: davem; +Cc: linux-bluetooth, netdev
[-- Attachment #1: Type: text/plain, Size: 1473 bytes --]
Hi Dave,
Here are some more Bluetooth patches (and one 802.15.4 patch) in the
bluetooth-next tree targeting the 4.12 kernel. Most of them are pure
fixes.
Please let me know if there are any issues pulling. Thanks.
Johan
---
The following changes since commit fb796707d7a6c9b24fdf80b9b4f24fa5ffcf0ec5:
Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net (2017-04-21 20:23:53 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git for-upstream
for you to fetch changes up to d160b74da85a4ec072b076db056e27ba7246eba0:
Bluetooth: hci_ldisc: Add missing clear HCI_UART_PROTO_READY (2017-04-22 10:28:40 +0200)
----------------------------------------------------------------
Arnd Bergmann (2):
Bluetooth: try to improve CONFIG_SERIAL_DEV_BUS dependency
ieee802154: don't select COMMON_CLK
Dean Jenkins (3):
Bluetooth: hci_ldisc: Add missing return in hci_uart_init_work()
Bluetooth: hci_ldisc: Ensure hu->hdev set to NULL before freeing hdev
Bluetooth: hci_ldisc: Add missing clear HCI_UART_PROTO_READY
Sebastian Reichel (1):
Bluetooth: hci_ll: Fix NULL pointer deref on FW upload failure
drivers/bluetooth/Kconfig | 8 +++++++-
drivers/bluetooth/Makefile | 2 +-
drivers/bluetooth/hci_ldisc.c | 7 ++++++-
drivers/bluetooth/hci_ll.c | 3 +--
drivers/net/ieee802154/Kconfig | 2 +-
5 files changed, 16 insertions(+), 6 deletions(-)
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Segfault when pairing A2DP device
From: Lukas Wagner @ 2017-04-22 13:13 UTC (permalink / raw)
To: linux-bluetooth
Hello,
when I try to pair my Bose QC35 Headset, bluetoothd crashes with the
following stack trace:
#0 0x000000000048d932 ba2str (bluetoothd)
#1 0x00000000004882d1 update_bredr_services (bluetoothd)
#2 0x0000000000488b9e browse_cb (bluetoothd)
#3 0x000000000045e6cc search_completed_cb (bluetoothd)
#4 0x00000000004a03f2 sdp_process (bluetoothd)
#5 0x000000000045e780 search_process_cb (bluetoothd)
#6 0x00007f28aca7545a g_main_context_dispatch (libglib-2.0.so.0)
#7 0x00007f28aca75810 n/a (libglib-2.0.so.0)
#8 0x00007f28aca75b32 g_main_loop_run (libglib-2.0.so.0)
#9 0x000000000044d267 main (bluetoothd)
#10 0x00007f28ac04b511 __libc_start_main (libc.so.6)
#11 0x000000000040ad6a _start (bluetoothd)
Coredump: http://wikisend.com/download/366074/core
Version: bluez 5.44-17-g677a3456a
Steps to reproduce:
- Remove (if already paired) bluetooth headset
- Pair in bluetoothctl
I believe this might be related to the bug reported here:
http://marc.info/?l=linux-bluetooth&m=149121146509800&w=2
Please let me know any more information on this.
I'm also willing to do some debugging myself if anybody can point me
in the right direction.
Cheers
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox