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?
-- ��.n��������+%������w��{.n�����{��� �^n�r������&��z�ޗ�zf���h���~����������_��+v���)ߣ�
