public inbox for linux-bluetooth@vger.kernel.org
 help / color / mirror / Atom feed
From: Konrad Zapalowicz <konrad.zapalowicz@canonical.com>
To: Luiz Augusto von Dentz <luiz.dentz@gmail.com>
Cc: "linux-bluetooth@vger.kernel.org" <linux-bluetooth@vger.kernel.org>
Subject: Re: Read by Group Type is denied when issued before Pairing is finsihed
Date: Thu, 24 Aug 2017 10:24:19 +0200	[thread overview]
Message-ID: <20170824082419.GE7309@annapurna> (raw)
In-Reply-To: <CABBYNZ+6Rnb8PYKwDv-ObaaZsQn8-h_iVM2hP1dvSHzf5q7a0w@mail.gmail.com>

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

  reply	other threads:[~2017-08-24  8:24 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
2017-08-24  8:40     ` Luiz Augusto von Dentz
2017-08-24  9:16       ` Konrad Zapalowicz
2017-08-30 15:10       ` Konrad Zapalowicz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170824082419.GE7309@annapurna \
    --to=konrad.zapalowicz@canonical.com \
    --cc=linux-bluetooth@vger.kernel.org \
    --cc=luiz.dentz@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox