Hi Luiz,
On 10/05/2017 11:40 AM, Luiz Augusto von Dentz wrote:
> Hi Isaac,
>
> On Wed, Oct 4, 2017 at 6:43 PM, Hermida, Isaac <Isaac.Hermida@xxxxxxxx> wrote:
>> Hi Luiz,
>>
>> On 10/03/2017 08:54 AM, Hermida, Isaac wrote:
>>> Hi Luiz,
>>>
>>> On 10/02/2017 06:00 PM, Luiz Augusto von Dentz wrote:
>>>> Hi Isaac,
>>>>
>>>> On Mon, Oct 2, 2017 at 10:03 AM, Hermida, Isaac <Isaac.Hermida@xxxxxxxx> wrote:
>>>>> Hi Luiz et all,
>>>>>
>>>>> On 09/29/2017 08:44 AM, Hermida, Isaac wrote:
>>>>>> Hi Luiz,
>>>>>>
>>>>>> On 09/28/2017 08:21 PM, Luiz Augusto von Dentz wrote:
>>>>>>> Hi Isaac,
>>>>>>>
>>>>>>> On Thu, Sep 28, 2017 at 7:43 PM, Hermida, Isaac <Isaac.Hermida@xxxxxxxx> wrote:
>>>>>>>> Hi group,
>>>>>>>>
>>>>>>>> As part of the bluetooth SIG certification there are two test cases
>>>>>>>> /TP/GAR/CL/BI-34-C and /TP/GAR/CL/BI-35-C (you can see they defined in
>>>>>>>> unit/test-gatt.c).
>>>>>>>> Currently I am able to run the "test/example-gatt-server" and see my
>>>>>>>> custom services and characteristics, but I need to define an specific
>>>>>>>> service/characteristic to be only accessible trough LE or BR/EDR
>>>>>>>> transport parameter. I was digging into the code but I was unable to
>>>>>>>> find how to set it for the GATT server.
>>>>>>>>
>>>>>>>> In other words, what I want to do is launch the gatt-server and then,
>>>>>>>> when inspecting the services/characteristic with gatttool, the returned
>>>>>>>> list should be different if I run gatttool with "-p 31" or not (notice
>>>>>>>> how the gatttool prompt is set to LE or BR).
>>>>>>>>
>>>>>>>> # gatttool -I -b 00:40:9D:98:99:BD -p 0
>>>>>>>> [00:40:9D:98:99:BD][LE]> connect
>>>>>>>> Attempting to connect to 00:40:9D:98:99:BD
>>>>>>>> Connection successful
>>>>>>>> [00:40:9D:98:99:BD][LE]> primary
>>>>>>>> attr handle: 0x0001, end grp handle: 0x0005 uuid:
>>>>>>>> 00001800-0000-1000-8000-00805f9b34fb
>>>>>>>> attr handle: 0x0006, end grp handle: 0x0009 uuid:
>>>>>>>> 00001801-0000-1000-8000-00805f9b34fb
>>>>>>>> attr handle: 0x000a, end grp handle: 0x000d uuid:
>>>>>>>> 0000180f-0000-1000-8000-00805f9b34fb
>>>>>>>> attr handle: 0x000e, end grp handle: 0x001d uuid:
>>>>>>>> 12345678-1234-5678-1234-56789abcdef0
>>>>>>>> attr handle: 0x001e, end grp handle: 0x0025 uuid:
>>>>>>>> 0000180d-0000-1000-8000-00805f9b34fb
>>>>>>>>
>>>>>>>>
>>>>>>>> # /tmp/gatttool -I -b 00:40:9D:98:99:BD -p 31
>>>>>>>> [00:40:9D:98:99:BD][BR]> connect
>>>>>>>> Attempting to connect to 00:40:9D:98:99:BD
>>>>>>>> Connection successful
>>>>>>>> [00:40:9D:98:99:BD][BR]> primary
>>>>>>>> attr handle: 0x0001, end grp handle: 0x0005 uuid:
>>>>>>>> 00001800-0000-1000-8000-00805f9b34fb
>>>>>>>> attr handle: 0x0006, end grp handle: 0x0009 uuid:
>>>>>>>> 00001801-0000-1000-8000-00805f9b34fb
>>>>>>>> attr handle: 0x000a, end grp handle: 0x0019 uuid:
>>>>>>>> 12345678-1234-5678-1234-56789abcdef0
>>>>>>>> attr handle: 0x001a, end grp handle: 0x001d uuid:
>>>>>>>> 0000180f-0000-1000-8000-00805f9b34fb
>>>>>>>> attr handle: 0x001e, end grp handle: 0x0025 uuid:
>>>>>>>> 0000180d-0000-1000-8000-00805f9b34fb
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> I am using bluez 5.41. Is possible to advertise a service only for LE or
>>>>>>>> BR? I guess it should because is part of the SIG certification and is
>>>>>>>> part of the unit/test-gatt.
>>>>>>> This might be because the spec was no clear about the database being
>>>>>>> bearer specific, which in my opinion this is a oversight since then we
>>>>>>> can't represent attributes of dual mode devices with a unified object,
>>>>>>> and I really wonder if this has to be forced up into the API, if it
>>>>>>> does then we would have to encode bearer information into the object
>>>>>>> path (argh!) for client and for server would probably need a property
>>>>>>> telling which bearer this would be available and encode this into to
>>>>>>> the database which may leave gaps in the handles or just duplicate
>>>>>>> everything, for server Id probably just hide the services based on the
>>>>>>> bearer, but we still need to store the CCC configuration in a bearer
>>>>>>> specific manner.
>>>>>>>
>>>>>>
>>>>>> So, what can I do in order to pass that specific bluetooth SIG tests?
>>>>>> That test cases need to ensure that an specific service/char in only
>>>>>> accessible on LE or BR, so they had to be different.
>>>>>> Do you have any idea or suggestion? It would be really welcome, if not I
>>>>>> have no idea how to proceed to complete the SIG validation with bluez stuff.
>>>>>> I was even trying to modify some files into the code, but I am not
>>>>>> familiar with that and it obviously did not work.
>>>>>
>>>>> I understand the silent to this last question as a no. So I assume that
>>>>> any user trying to pass this test will fail (at least if using bluez).
>>>>> So should the specification be changed? Should bluez adapt to it? In the
>>>>> current state that SIG certification can not be passed.
>>>>
>>>> That if you want to qualify with GATT over BR/EDR, something that we
>>>> may actually have an option to disable in the future, or perhaps just
>>>> remove it entirely given this tests would possible affect that GATT
>>>> database layout, either by creating handle gaps or duplication. So
>>>> perhaps you could give some feedback if you do intend to use GATT over
>>>> BR/EDR or not? If it turn out no one benefit from it Id just remove
>>>> it.
>>>>
>>>
>>> Thanks for the quick reply. I do not know how any other people was able
>>> to pass these SIG lab tests (BI-34-C and BI-35-C).
>>> I do not plan to use GATT over BR/EDR. For me just removing it would be
>>> enough. If you can point me where/how to do that it would be great so I
>>> can dig in the code (I am not familiar with that code).
>>>
>>> Thx,
>>> Isaac
>>
>>
>> Yesterday I did apply the patch (gatt: Remove support of ATT over
>> BR/EDR) on bluez-5.41 (my current version) and passed it to the lab. I
>> was waiting for their feedback but I did not get a reply yet, so just to
>> let you know that I get the patch and applied it.
>> As I see it, that patch removed the support for ATT over BR/EDR, so I
>> guess that another way to pass that test is modifying the firmware of
>> the bluetooth chip to disable it at a hw level.
>> And, in order to pass the other test case (BI-35-C), I will need to do
>> not apply the mentioned patch and create a similar one for ATT over LE,
>> or is there another way to accomplish /TP/GAR/CL/BI-35-C?
>
> Id assume you would not have to run those tests if ATT over BR/EDR is
> not supported:
>
> 4.5.72 TP/GAR/CL/BI-35-C [Read Characteristic Value \u2013 Invalid
> Transport Access over
> LE]
> Verify Generic Attribute Profile client behavior when an attempt to
> use LE transport to execute
> the Read Characteristic Value procedure on a characteristic contained
> within a service defined
> for use only over BR/EDR transport.
>
> Without BR/EDR there is no reason to run this test as all the
> attributes should be valid.
>
Our product is dual so those tests are mandatory. Additionally, our
product is 4.2, no 4.0.
The patch you proposed (gatt: Remove support of ATT over BR/EDR) is not
valid and will not work (if you want I can add details to the other
thread) and it will break other tests needed for the certification. I
would suggest to reject it.
To put some light in tests BI-34-C and BI-35-C, it consists in define a
characteristic only available through the transport layer LE or BR/EDR,
so in one case the value can be read, and in the other case it is
rejected. I can add more details if needed.
Currently the workaround that I am doing is record the type of
connection (LE or BR/EDR) and return the error code for one specific
characteristic (that I register in my gatt server application), so I
customize my application. The lab did not confirm/dismiss it yet, but
hopefully it is what they need.
Thanks for the support on this issue. Let me know if I can help in
anything, if I need to provide more details, if you want a reply in the
patch thread or any other stuff.
Regards,
Isaac��.n��������+%������w��{.n�����{��� �^n�r������&��z�ޗ�zf���h���~����������_��+v���)ߣ�
