* Read by Group Type is denied when issued before Pairing is finsihed @ 2017-08-23 19:38 Konrad Zapalowicz 2017-08-24 8:04 ` Luiz Augusto von Dentz 0 siblings, 1 reply; 6+ messages in thread From: Konrad Zapalowicz @ 2017-08-23 19:38 UTC (permalink / raw) To: linux-bluetooth Hey, I have stumbled upon a problem with one of the BLE devices that I have on my desk. BlueZ (bluetoothctl) failed to discover the primary services and the error returned by the Read by Group type request was "Insufficient Authentication". It did work when using gatttool though. I have tracked it down and realized that if calling the bt_gatt_discover_all_primary_services is delayed until after the pairing is finished then the primary services are discovered without any issues. The simplified bt for bt_gatt_discover_all_primary_services is: (gdb) bt #0 discover_services #1 bt_gatt_discover_primary_services #2 bt_gatt_discover_all_primary_services #3 exchange_mtu_cb Now, what would be the best way of approaching this. Calling it could be delayed with a timer but would it be an optimal solution - thoughts? Thanks, K ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Read by Group Type is denied when issued before Pairing is finsihed 2017-08-23 19:38 Read by Group Type is denied when issued before Pairing is finsihed Konrad Zapalowicz @ 2017-08-24 8:04 ` Luiz Augusto von Dentz 2017-08-24 8:24 ` Konrad Zapalowicz 0 siblings, 1 reply; 6+ messages in thread From: Luiz Augusto von Dentz @ 2017-08-24 8:04 UTC (permalink / raw) To: Konrad Zapalowicz; +Cc: linux-bluetooth Hi Konrad, On Wed, Aug 23, 2017 at 10:38 PM, Konrad Zapalowicz <konrad.zapalowicz@canonical.com> wrote: > Hey, > > I have stumbled upon a problem with one of the BLE devices that I have > on my desk. BlueZ (bluetoothctl) failed to discover the primary services > and the error returned by the Read by Group type request was > "Insufficient Authentication". It did work when using gatttool though. > > I have tracked it down and realized that if calling the > bt_gatt_discover_all_primary_services is delayed until after the pairing > is finished then the primary services are discovered without any issues. > > The simplified bt for bt_gatt_discover_all_primary_services is: > > (gdb) bt > #0 discover_services > #1 bt_gatt_discover_primary_services > #2 bt_gatt_discover_all_primary_services > #3 exchange_mtu_cb > > Now, what would be the best way of approaching this. Calling it could be > delayed with a timer but would it be an optimal solution - thoughts? Sounds to me that the device is requiring authentication for primary services which is not following the spec: 4.4.1 Discover All Primary Services ... Note: The service declaration described in Section 3.1 specifies that the service declaration is readable and requires no authentication or authorization, therefore insufficient authentication or read not permitted errors shall not occur. Is this a device already on the market? Perhaps we should contact the manufacturer since it seems to not comply to the spec when it comes to discovery. Delaying is never a nice thing since it affects all devices, but we could perhaps attempt to pair if that happens, actually, we usually do this for regular Read/Write procedures so in case there is an authentication error we pair and try again which might work here as well despite not following the spec. > Thanks, > K > -- > 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 [flat|nested] 6+ messages in thread
* Re: Read by Group Type is denied when issued before Pairing is finsihed 2017-08-24 8:04 ` Luiz Augusto von Dentz @ 2017-08-24 8:24 ` Konrad Zapalowicz 2017-08-24 8:40 ` Luiz Augusto von Dentz 0 siblings, 1 reply; 6+ messages in thread From: Konrad Zapalowicz @ 2017-08-24 8:24 UTC (permalink / raw) To: Luiz Augusto von Dentz; +Cc: linux-bluetooth On 08/24, Luiz Augusto von Dentz wrote: > Hi Konrad, > > On Wed, Aug 23, 2017 at 10:38 PM, Konrad Zapalowicz > <konrad.zapalowicz@canonical.com> wrote: > > Hey, > > > > I have stumbled upon a problem with one of the BLE devices that I have > > on my desk. BlueZ (bluetoothctl) failed to discover the primary services > > and the error returned by the Read by Group type request was > > "Insufficient Authentication". It did work when using gatttool though. > > > > I have tracked it down and realized that if calling the > > bt_gatt_discover_all_primary_services is delayed until after the pairing > > is finished then the primary services are discovered without any issues. > > > > The simplified bt for bt_gatt_discover_all_primary_services is: > > > > (gdb) bt > > #0 discover_services > > #1 bt_gatt_discover_primary_services > > #2 bt_gatt_discover_all_primary_services > > #3 exchange_mtu_cb > > > > Now, what would be the best way of approaching this. Calling it could be > > delayed with a timer but would it be an optimal solution - thoughts? > > Sounds to me that the device is requiring authentication for primary > services which is not following the spec: Yes, this is true as well and it is also my concern. Yet at the same time I would love to get this device operational. This is a Transport Data Logger btw that I'm playing with. > > 4.4.1 Discover All Primary Services > ... > Note: The service declaration described in Section 3.1 specifies that the > service declaration is readable and requires no authentication or authorization, > therefore insufficient authentication or read not permitted errors > shall not occur. > > Is this a device already on the market? Perhaps we should contact the > manufacturer since it seems to not comply to the spec when it comes to > discovery. > > Delaying is never a nice thing since it affects all devices, but we > could perhaps attempt to pair if that happens, actually, we usually do > this for regular Read/Write procedures so in case there is an > authentication error we pair and try again which might work here as > well despite not following the spec. In the meantime I have cross-checked with the Android code and it does things differently. So the services discovery is started in pairing_cb that is being called when the pairing is done. I can't tell however if this affects interoperability in any way, i.e. has a negative impact over Linux implementation. Thanks, K > > > Thanks, > > K > > -- > > 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 [flat|nested] 6+ messages in thread
* Re: Read by Group Type is denied when issued before Pairing is finsihed 2017-08-24 8:24 ` Konrad Zapalowicz @ 2017-08-24 8:40 ` Luiz Augusto von Dentz 2017-08-24 9:16 ` Konrad Zapalowicz 2017-08-30 15:10 ` Konrad Zapalowicz 0 siblings, 2 replies; 6+ messages in thread From: Luiz Augusto von Dentz @ 2017-08-24 8:40 UTC (permalink / raw) To: Konrad Zapalowicz; +Cc: linux-bluetooth Hi Konrad, On Thu, Aug 24, 2017 at 11:24 AM, Konrad Zapalowicz <konrad.zapalowicz@canonical.com> wrote: > On 08/24, Luiz Augusto von Dentz wrote: >> Hi Konrad, >> >> On Wed, Aug 23, 2017 at 10:38 PM, Konrad Zapalowicz >> <konrad.zapalowicz@canonical.com> wrote: >> > Hey, >> > >> > I have stumbled upon a problem with one of the BLE devices that I have >> > on my desk. BlueZ (bluetoothctl) failed to discover the primary services >> > and the error returned by the Read by Group type request was >> > "Insufficient Authentication". It did work when using gatttool though. >> > >> > I have tracked it down and realized that if calling the >> > bt_gatt_discover_all_primary_services is delayed until after the pairing >> > is finished then the primary services are discovered without any issues. >> > >> > The simplified bt for bt_gatt_discover_all_primary_services is: >> > >> > (gdb) bt >> > #0 discover_services >> > #1 bt_gatt_discover_primary_services >> > #2 bt_gatt_discover_all_primary_services >> > #3 exchange_mtu_cb >> > >> > Now, what would be the best way of approaching this. Calling it could be >> > delayed with a timer but would it be an optimal solution - thoughts? >> >> Sounds to me that the device is requiring authentication for primary >> services which is not following the spec: > > Yes, this is true as well and it is also my concern. Yet at the same > time I would love to get this device operational. This is a Transport > Data Logger btw that I'm playing with. > >> >> 4.4.1 Discover All Primary Services >> ... >> Note: The service declaration described in Section 3.1 specifies that the >> service declaration is readable and requires no authentication or authorization, >> therefore insufficient authentication or read not permitted errors >> shall not occur. >> >> Is this a device already on the market? Perhaps we should contact the >> manufacturer since it seems to not comply to the spec when it comes to >> discovery. >> >> Delaying is never a nice thing since it affects all devices, but we >> could perhaps attempt to pair if that happens, actually, we usually do >> this for regular Read/Write procedures so in case there is an >> authentication error we pair and try again which might work here as >> well despite not following the spec. > > In the meantime I have cross-checked with the Android code and it does > things differently. So the services discovery is started in pairing_cb > that is being called when the pairing is done. I can't tell however if > this affects interoperability in any way, i.e. has a negative impact > over Linux implementation. Not sure how Android would determine if it needs pairing before discovering the services, in GATT the pairing is normally done on demand when there is an authentication error. Though perhaps Android pairs with any device capable of pairing, anyway the same could be done with bluetoothctl> pair instead of connect command. Btw, even for profiles requiring pairing, like HoG, it hasn't been a problem to pair on demand though it is probably recommended to pair first so we don't lose a round trip while accessing the attributes that would cause the authentication error. > Thanks, > K > >> >> > Thanks, >> > K >> > -- >> > 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 -- Luiz Augusto von Dentz ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Read by Group Type is denied when issued before Pairing is finsihed 2017-08-24 8:40 ` Luiz Augusto von Dentz @ 2017-08-24 9:16 ` Konrad Zapalowicz 2017-08-30 15:10 ` Konrad Zapalowicz 1 sibling, 0 replies; 6+ messages in thread From: Konrad Zapalowicz @ 2017-08-24 9:16 UTC (permalink / raw) To: Luiz Augusto von Dentz; +Cc: linux-bluetooth On 08/24, Luiz Augusto von Dentz wrote: > Hi Konrad, > > On Thu, Aug 24, 2017 at 11:24 AM, Konrad Zapalowicz > <konrad.zapalowicz@canonical.com> wrote: > > On 08/24, Luiz Augusto von Dentz wrote: > >> Hi Konrad, > >> > >> On Wed, Aug 23, 2017 at 10:38 PM, Konrad Zapalowicz > >> <konrad.zapalowicz@canonical.com> wrote: > >> > Hey, > >> > > >> > I have stumbled upon a problem with one of the BLE devices that I have > >> > on my desk. BlueZ (bluetoothctl) failed to discover the primary services > >> > and the error returned by the Read by Group type request was > >> > "Insufficient Authentication". It did work when using gatttool though. > >> > > >> > I have tracked it down and realized that if calling the > >> > bt_gatt_discover_all_primary_services is delayed until after the pairing > >> > is finished then the primary services are discovered without any issues. > >> > > >> > The simplified bt for bt_gatt_discover_all_primary_services is: > >> > > >> > (gdb) bt > >> > #0 discover_services > >> > #1 bt_gatt_discover_primary_services > >> > #2 bt_gatt_discover_all_primary_services > >> > #3 exchange_mtu_cb > >> > > >> > Now, what would be the best way of approaching this. Calling it could be > >> > delayed with a timer but would it be an optimal solution - thoughts? > >> > >> Sounds to me that the device is requiring authentication for primary > >> services which is not following the spec: > > > > Yes, this is true as well and it is also my concern. Yet at the same > > time I would love to get this device operational. This is a Transport > > Data Logger btw that I'm playing with. > > > >> > >> 4.4.1 Discover All Primary Services > >> ... > >> Note: The service declaration described in Section 3.1 specifies that the > >> service declaration is readable and requires no authentication or authorization, > >> therefore insufficient authentication or read not permitted errors > >> shall not occur. > >> > >> Is this a device already on the market? Perhaps we should contact the > >> manufacturer since it seems to not comply to the spec when it comes to > >> discovery. > >> > >> Delaying is never a nice thing since it affects all devices, but we > >> could perhaps attempt to pair if that happens, actually, we usually do > >> this for regular Read/Write procedures so in case there is an > >> authentication error we pair and try again which might work here as > >> well despite not following the spec. > > > > In the meantime I have cross-checked with the Android code and it does > > things differently. So the services discovery is started in pairing_cb > > that is being called when the pairing is done. I can't tell however if > > this affects interoperability in any way, i.e. has a negative impact > > over Linux implementation. > > Not sure how Android would determine if it needs pairing before > discovering the services, in GATT the pairing is normally done on > demand when there is an authentication error. Though perhaps Android > pairs with any device capable of pairing, anyway the same could be > done with bluetoothctl> pair instead of connect command. I have not read the Andoid code throughtly howeve I think that this is exactly what it is doing - just pairing whenever possible. I do pair first. The primary services are fetched automagically as soon as the exchange mtu is done - fired in the callback for this procedure. > > Btw, even for profiles requiring pairing, like HoG, it hasn't been a > problem to pair on demand though it is probably recommended to pair > first so we don't lose a round trip while accessing the attributes > that would cause the authentication error. Right, pairing first. Then the whole procedure would have to be started/restarted once the pairing is finished the fetch the primary services. /K > > > Thanks, > > K > > > >> > >> > Thanks, > >> > K > >> > -- > >> > 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 > > > > -- > Luiz Augusto von Dentz ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Read by Group Type is denied when issued before Pairing is finsihed 2017-08-24 8:40 ` Luiz Augusto von Dentz 2017-08-24 9:16 ` Konrad Zapalowicz @ 2017-08-30 15:10 ` Konrad Zapalowicz 1 sibling, 0 replies; 6+ messages in thread From: Konrad Zapalowicz @ 2017-08-30 15:10 UTC (permalink / raw) To: Luiz Augusto von Dentz; +Cc: linux-bluetooth On 08/24, Luiz Augusto von Dentz wrote: > Hi Konrad, > > On Thu, Aug 24, 2017 at 11:24 AM, Konrad Zapalowicz > <konrad.zapalowicz@canonical.com> wrote: > > On 08/24, Luiz Augusto von Dentz wrote: > >> Hi Konrad, > >> > >> On Wed, Aug 23, 2017 at 10:38 PM, Konrad Zapalowicz > >> <konrad.zapalowicz@canonical.com> wrote: > >> > Hey, > >> > > >> > I have stumbled upon a problem with one of the BLE devices that I have > >> > on my desk. BlueZ (bluetoothctl) failed to discover the primary services > >> > and the error returned by the Read by Group type request was > >> > "Insufficient Authentication". It did work when using gatttool though. > >> > > >> > I have tracked it down and realized that if calling the > >> > bt_gatt_discover_all_primary_services is delayed until after the pairing > >> > is finished then the primary services are discovered without any issues. > >> > > >> > The simplified bt for bt_gatt_discover_all_primary_services is: > >> > > >> > (gdb) bt > >> > #0 discover_services > >> > #1 bt_gatt_discover_primary_services > >> > #2 bt_gatt_discover_all_primary_services > >> > #3 exchange_mtu_cb > >> > > >> > Now, what would be the best way of approaching this. Calling it could be > >> > delayed with a timer but would it be an optimal solution - thoughts? > >> > >> Sounds to me that the device is requiring authentication for primary > >> services which is not following the spec: > > > > Yes, this is true as well and it is also my concern. Yet at the same > > time I would love to get this device operational. This is a Transport > > Data Logger btw that I'm playing with. > > > >> > >> 4.4.1 Discover All Primary Services > >> ... > >> Note: The service declaration described in Section 3.1 specifies that the > >> service declaration is readable and requires no authentication or authorization, > >> therefore insufficient authentication or read not permitted errors > >> shall not occur. > >> > >> Is this a device already on the market? Perhaps we should contact the > >> manufacturer since it seems to not comply to the spec when it comes to > >> discovery. > >> > >> Delaying is never a nice thing since it affects all devices, but we > >> could perhaps attempt to pair if that happens, actually, we usually do > >> this for regular Read/Write procedures so in case there is an > >> authentication error we pair and try again which might work here as > >> well despite not following the spec. > > > > In the meantime I have cross-checked with the Android code and it does > > things differently. So the services discovery is started in pairing_cb > > that is being called when the pairing is done. I can't tell however if > > this affects interoperability in any way, i.e. has a negative impact > > over Linux implementation. > > Not sure how Android would determine if it needs pairing before > discovering the services, in GATT the pairing is normally done on > demand when there is an authentication error. Though perhaps Android > pairs with any device capable of pairing, anyway the same could be > done with bluetoothctl> pair instead of connect command. So I have investigated further and realized that there is an incomming ATT connection that I have missed for the first time. As a result the connect_cb from gatt-database.c is execued which calls the device_attach_att that ultimately leads to gatt_client_init being called. The device_attach_att would be called anyway through the new_long_term_key_callback and device_browse_gatt however since the services are already discovered it never happens. Which is perfecly fine btw. I'm thinking however though if this is sane to make sure that the services are discovered only through the new_long_term_key_callback path. Something which would happen after the device_bonding_complete thus would be a little bit more forgiving for devices that behave like the described one. Does it make sense? > > Btw, even for profiles requiring pairing, like HoG, it hasn't been a > problem to pair on demand though it is probably recommended to pair > first so we don't lose a round trip while accessing the attributes > that would cause the authentication error. > > > Thanks, > > K > > > >> > >> > Thanks, > >> > K > >> > -- > >> > 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 > > > > -- > Luiz Augusto von Dentz ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2017-08-30 15:10 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-08-23 19:38 Read by Group Type is denied when issued before Pairing is finsihed Konrad Zapalowicz 2017-08-24 8:04 ` Luiz Augusto von Dentz 2017-08-24 8:24 ` Konrad Zapalowicz 2017-08-24 8:40 ` Luiz Augusto von Dentz 2017-08-24 9:16 ` Konrad Zapalowicz 2017-08-30 15:10 ` Konrad Zapalowicz
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.