Read Characteristic Value vs. Read Long Characteristic Values

Read Characteristic Value vs. Read Long Characteristic Values

[Anderson Lizardo]

Hi Brian,

On the implementation you did for Long Characteristic value read, you
integrated the Read Blob Request handling into the existing "Read
Characteristic Value" implementation. From my understanding of the
code, the read blob request is issued if the response PDU size is
greater than or equal to LE ATT_MTU (23).

The problem I see with this approach is that if the client knows that
the characteristic value is exactly 22 bytes (which makes total PDU
size equal to 23 with the opcode), a spurious read blob request (and
corresponding response) is sent. How could we avoid this overhead?

My idea was to separate the procedures, having a "Read Long
Characteristic Value" and revert Read Characteristic Value to read
only the first ATT_MTU - 1 bytes as before. For characteristic values
which the client knows to be within ATT_MTU - 1 bytes (of if it only
cares about these bytes at the time) it would use the latter. For
cases where value length is unknown, it would use the former.

This would also allow us to better map to GATT procedures and have
fine control on the client implementation and on our test tool
(igatttool).

Any other ideas?
-- 
Anderson Lizardo
OpenBossa Labs - INdT
Manaus - Brazil

Re: Read Characteristic Value vs. Read Long Characteristic Values

[Brian Gix]

Hi Anderson,

On Tue, 2011-01-25 at 15:07 -0400, Anderson Lizardo wrote:
> Hi Brian,
> 
> On the implementation you did for Long Characteristic value read, you
> integrated the Read Blob Request handling into the existing "Read
> Characteristic Value" implementation. From my understanding of the
> code, the read blob request is issued if the response PDU size is
> greater than or equal to LE ATT_MTU (23).
> 
> The problem I see with this approach is that if the client knows that
> the characteristic value is exactly 22 bytes (which makes total PDU
> size equal to 23 with the opcode), a spurious read blob request (and
> corresponding response) is sent. How could we avoid this overhead?
> 
> My idea was to separate the procedures, having a "Read Long
> Characteristic Value" and revert Read Characteristic Value to read
> only the first ATT_MTU - 1 bytes as before. For characteristic values
> which the client knows to be within ATT_MTU - 1 bytes (of if it only
> cares about these bytes at the time) it would use the latter. For
> cases where value length is unknown, it would use the former.
> 
> This would also allow us to better map to GATT procedures and have
> fine control on the client implementation and on our test tool
> (igatttool).
> 

>>From a practical perspective, the only attributes that would be
*exactly* 22 octets would be strings which defy attempts for a client to
predict their length without knowing what the content is ahead of time.

You are correct that if a *profile* defines a particular characteristic
attribute value to be exactly 22 octets, that this would result in
result it a harmless extra read.

For string reads this is not really a useless extra operation, because
it does supply definitive termination of the string, which per ATT
protocol cannot be provided any other way.

As far as test case coverage per the qualification test specification, I
do not believe that there is a problem.  Any non long "Reads" can be
tested by reading < 22 octet attributes, and long read tests by reading
>= 22 octet attributes. 



-- 
Brian Gix
bgix@codeaurora.org
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum

Re: Read Characteristic Value vs. Read Long Characteristic Values

[Anderson Lizardo]

On Tue, Jan 25, 2011 at 3:46 PM, Brian Gix <bgix@codeaurora.org> wrote:
> As far as test case coverage per the qualification test specification, I
> do not believe that there is a problem.  Any non long "Reads" can be
> tested by reading < 22 octet attributes, and long read tests by reading
>>= 22 octet attributes.

Now that you mentioned this topic, the issue that brought this thread
is that there is a specific qualification test where PTS sends a 22
bytes characteristic value, expecting a single Read Request to be
sent, and it refuses to answer to any further Read Blob Requests (i.e.
it does not send any response PDUs). This makes the client (e.g.
igatttool) wait forever for a answer or timeout.

Looks like more a PTS bug, but makes me wonder if it is not better for
BlueZ to have separate procedures instead of this "automatic" usage of
read blob request ?

Regards,
-- 
Anderson Lizardo
OpenBossa Labs - INdT
Manaus - Brazil

Re: Read Characteristic Value vs. Read Long Characteristic Values

[Anderson Lizardo]

On Wed, Jan 26, 2011 at 9:33 AM, Anderson Lizardo
<anderson.lizardo@openbossa.org> wrote:
> Looks like more a PTS bug, but makes me wonder if it is not better for
> BlueZ to have separate procedures instead of this "automatic" usage of
> read blob request ?

BTW, the test which presented this issue with sending spurious read
blob request is named "Read Characteristic Descriptors – by client". I
also can see that the behavior you implemented satisfies both "Read
Long Characteristic Value - by client" and "Read Long Characteristic
Descriptor - by client" tests. All theses tests come from the GATT TS
document.

Regards,
-- 
Anderson Lizardo
OpenBossa Labs - INdT
Manaus - Brazil

Re: Read Characteristic Value vs. Read Long Characteristic Values

[Anderson Lizardo]

Hi Brian,

On Wed, Jan 26, 2011 at 9:58 AM, Anderson Lizardo
<anderson.lizardo@openbossa.org> wrote:
> On Wed, Jan 26, 2011 at 9:33 AM, Anderson Lizardo
> <anderson.lizardo@openbossa.org> wrote:
>> Looks like more a PTS bug, but makes me wonder if it is not better for
>> BlueZ to have separate procedures instead of this "automatic" usage of
>> read blob request ?
>
> BTW, the test which presented this issue with sending spurious read
> blob request is named "Read Characteristic Descriptors – by client". I
> also can see that the behavior you implemented satisfies both "Read
> Long Characteristic Value - by client" and "Read Long Characteristic
> Descriptor - by client" tests. All theses tests come from the GATT TS
> document.

Another update... Test "Read Long Characteristic Value – Invalid
handle" expects a Read Blob request specifically. The only way I see
to satisfy it is to provide a separate "read long characteristic
value" procedure separate from the "read characteristic value". Any
other ideas?

Regards,
-- 
Anderson Lizardo
OpenBossa Labs - INdT
Manaus - Brazil

Re: Read Characteristic Value vs. Read Long Characteristic Values

[Brian Gix]

Hi Anderson,

On Wed, 2011-01-26 at 09:58 -0400, Anderson Lizardo wrote:
> On Wed, Jan 26, 2011 at 9:33 AM, Anderson Lizardo
> <anderson.lizardo@openbossa.org> wrote:
> > Looks like more a PTS bug, but makes me wonder if it is not better for
> > BlueZ to have separate procedures instead of this "automatic" usage of
> > read blob request ?
> 
> BTW, the test which presented this issue with sending spurious read
> blob request is named "Read Characteristic Descriptors – by client". I
> also can see that the behavior you implemented satisfies both "Read
> Long Characteristic Value - by client" and "Read Long Characteristic
> Descriptor - by client" tests. All theses tests come from the GATT TS
> document.

Can you tell me the specific Test Case number(s) that you are having
difficulty testing?  I do not have a current release of the PTS tool
available to me at this time, although I do know that PTS is developed
in parallel, and is just as prone to bugs as the rest of us. I should be
able to test this stuff against the PTS guys at UPF week after next, and
talk to the guys who are writing it.

Thanks,

-- 
Brian Gix
bgix@codeaurora.org
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum

Re: Read Characteristic Value vs. Read Long Characteristic Values

[Anderson Lizardo]

On Wed, Jan 26, 2011 at 1:59 PM, Brian Gix <bgix@codeaurora.org> wrote:
> Hi Anderson,
>
> On Wed, 2011-01-26 at 09:58 -0400, Anderson Lizardo wrote:
>> On Wed, Jan 26, 2011 at 9:33 AM, Anderson Lizardo
>> <anderson.lizardo@openbossa.org> wrote:
>> > Looks like more a PTS bug, but makes me wonder if it is not better for
>> > BlueZ to have separate procedures instead of this "automatic" usage of
>> > read blob request ?
>>
>> BTW, the test which presented this issue with sending spurious read
>> blob request is named "Read Characteristic Descriptors – by client". I
>> also can see that the behavior you implemented satisfies both "Read
>> Long Characteristic Value - by client" and "Read Long Characteristic
>> Descriptor - by client" tests. All theses tests come from the GATT TS
>> document.
>
> Can you tell me the specific Test Case number(s) that you are having
> difficulty testing?  I do not have a current release of the PTS tool
> available to me at this time, although I do know that PTS is developed
> in parallel, and is just as prone to bugs as the rest of us. I should be
> able to test this stuff against the PTS guys at UPF week after next, and
> talk to the guys who are writing it.

At least these break with the current implementation:

TP/GAR/CL/BV-06-C (PTS does not expect a Read blob request after Read Request)
TP/GAR/CL/BI-12-C (test procedure expects Read Blob Request, not Read Request)
TP/GAR/CL/BI-13-C (same as above)
TP/GAR/CL/BI-14-C (same as above)
TP/GAR/CL/BI-28-C (same as above)
TP/GAR/CL/BV-07-C (same as above)

Except for the first test case, the specific requirement for a Read
Blob Request is defined on the test procedure of the GATT TS document
itself, so in these cases I don't think it's PTS bug.

Regards,
-- 
Anderson Lizardo
OpenBossa Labs - INdT
Manaus - Brazil

Re: Read Characteristic Value vs. Read Long Characteristic Values

[Brian Gix]

On Wed, 2011-01-26 at 14:28 -0400, Anderson Lizardo wrote:
> On Wed, Jan 26, 2011 at 1:59 PM, Brian Gix <bgix@codeaurora.org> wrote:
> > Hi Anderson,
> >
> > On Wed, 2011-01-26 at 09:58 -0400, Anderson Lizardo wrote:
> >> On Wed, Jan 26, 2011 at 9:33 AM, Anderson Lizardo
> >> <anderson.lizardo@openbossa.org> wrote:
> >> > Looks like more a PTS bug, but makes me wonder if it is not better for
> >> > BlueZ to have separate procedures instead of this "automatic" usage of
> >> > read blob request ?
> >>
> >> BTW, the test which presented this issue with sending spurious read
> >> blob request is named "Read Characteristic Descriptors – by client". I
> >> also can see that the behavior you implemented satisfies both "Read
> >> Long Characteristic Value - by client" and "Read Long Characteristic
> >> Descriptor - by client" tests. All theses tests come from the GATT TS
> >> document.
> >
> > Can you tell me the specific Test Case number(s) that you are having
> > difficulty testing?  I do not have a current release of the PTS tool
> > available to me at this time, although I do know that PTS is developed
> > in parallel, and is just as prone to bugs as the rest of us. I should be
> > able to test this stuff against the PTS guys at UPF week after next, and
> > talk to the guys who are writing it.
> 
> At least these break with the current implementation:
> 
> TP/GAR/CL/BV-06-C (PTS does not expect a Read blob request after Read Request)

This sounds like a PTS failure.  The actual MSC will be followed, and
the fact that a follow READ_BLOB is made is outside the scope of the
test.  If the PTS were working as a properly functioning server it
should respond with *something* even if it is "Command Not Supported" or
something, which would be handled correctly by bluez.

> TP/GAR/CL/BI-12-C (test procedure expects Read Blob Request, not Read Request)



> TP/GAR/CL/BI-13-C (same as above)
> TP/GAR/CL/BI-14-C (same as above)

These two tests will need special APIs written which do not necessarily
need to be exposed as upper layer APIs. The test in both cases is to
ensure that the client can properly handle error returns from the
server.  These are not tests that a high level application would
typically be able to run, since using an invalid offset or handle should
never come up.  However, these tests were likely added as robustness
tests for client to prevent, for example, denial of service attacks, or
other robustness issues made famous in the BT world by tools such as
Codenomicon's robustness suite.

Therefore, for these two tests, a test-only GATT API could be written
that specifies specific Handle and Offset arguments to a bare ATT
READ_BLOB call.  But I would argue against including this as an upper
layer (D-Bus) API.


> TP/GAR/CL/BI-28-C (same as above)

The above Test API would again work for this. However, again, a properly
function high level Application should never be issuing an actual Read
to an attribute that has been flagged as Write Only, or Security
Required (withoutout the security in place).

> TP/GAR/CL/BV-07-C (same as above)

I believe this Test Case itself may be flawed.  While it can also be
tested with the above described Test API, the "Read Long Characteristic
Values" GATT functionality is explicitly allowed as a chain from the
single pkt "Read Characteristic Value", from the Note (3rd Paragraph) of
page 562 in the Core 4.0 specification for GATT. (this is page 1922 of
the full Cove 4.0 PDF file) --> "Note: The Read Blob Request may be used
to read the remainder of an Attribute where the first part was read
using a simple Read Request."

The test cases are intended to ensure that the functionality used are
used correctly.  They are not intended to force the usage of unneeded
functionality.

I will talk to the PTS guys at UPF, and make sure that the PIXIT lists
are setup such that the tests required for qualification correctly
mandate the correct subset of test cases as required by the ruling
specification.

> 
> Except for the first test case, the specific requirement for a Read
> Blob Request is defined on the test procedure of the GATT TS document
> itself, so in these cases I don't think it's PTS bug.
> 
> Regards,

-- 
Brian Gix
bgix@codeaurora.org
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum

Re: Read Characteristic Value vs. Read Long Characteristic Values

[Anderson Lizardo]

Hi Brian,

On Wed, Jan 26, 2011 at 4:57 PM, Brian Gix <bgix@codeaurora.org> wrote:
> I will talk to the PTS guys at UPF, and make sure that the PIXIT lists
> are setup such that the tests required for qualification correctly
> mandate the correct subset of test cases as required by the ruling
> specification.

Did you manage to get some input from PTS guys on these tests? I did
not check the recently released 4.2.0 yet.

Regards,
-- 
Anderson Lizardo
OpenBossa Labs - INdT
Manaus - Brazil

Re: Read Characteristic Value vs. Read Long Characteristic Values

[Brian Gix]

Hi Anderson,

On 2/8/2011 12:46 PM, Anderson Lizardo wrote:
> Hi Brian,
>
> On Wed, Jan 26, 2011 at 4:57 PM, Brian Gix<bgix@codeaurora.org>  wrote:
>> I will talk to the PTS guys at UPF, and make sure that the PIXIT lists
>> are setup such that the tests required for qualification correctly
>> mandate the correct subset of test cases as required by the ruling
>> specification.
>
> Did you manage to get some input from PTS guys on these tests? I did
> not check the recently released 4.2.0 yet.
>
> Regards,


I was talking to the guy who wrote most of the GATT tests, and he said 
that the test for "Read Long" in particular should Pass wether it was 
initiated with a standard READ or READ_BLOB.  He said that if the test 
does not work that way, to send him a PTS log of the particular test 
session that did not work as expected (that test or any other).

I will try to get the exact email address to use for PTS log submissions 
and get back to you.

-- 
Brian Gix
bgix@codeaurora.org
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum