Re: endless loop in client.c when read request is rejected

Hi Anderson,

On Fri, Jul 1, 2011 at 4:40 PM, Anderson Lizardo
[off-list ref] wrote:

Hi again,

On Fri, Jul 1, 2011 at 7:38 PM, Anderson Lizardo
[off-list ref] wrote:

quoted

Hi Mike,

On Fri, Jul 1, 2011 at 6:06 PM, mike tsai [off-list ref] wrote:

quoted

  I am not sure what effect bt_io_set should have to improve the
security (bonding?), but the code simply has no effect in my
environment (with 2.6.39.1 kernel and latest bluez), therefore the
read_req, error_response will continue until link is disconnected.

bt_io_set(..., BT_IO_OPT_SEC_LEVEL, BT_IO_SEC_HIGH, ...) will trigger
SMP pairing (and block further writes until pairing is complete). I
believe you see the loop because your kernel does not have SMP
support, which has been added upstream only a few weeks ago (so should
come only on 3.0, I believe). Therefore SMP does never happen in your
case.

Forgot to mention: I still think we need a fix on BlueZ though, which
cannot assume SMP pairing will succeed. Therefore we should have a way
to abort the write attempt.

After upgrade the kernel to 2.6-next branch, it does initiate the
just-work, no-bonding operation and it does work.(no more endless
loop). However, I found another issue is that during discovery, the
client will try to read every characteristic it found, regardless the
property setting. This causes "Read Not Permitted" error response for
some characteristic that does not allowed to be read (like the
alert-level). I am not sure why the discovery process wants to read
the characteristic value though, that should be invoked by profile
later when needed,

Regards,

Mike

Regards,
--
Anderson Lizardo
Instituto Nokia de Tecnologia - INdT
Manaus - Brazil