Hi Luiz, On 10/09/2017 01:30 PM, Luiz Augusto von Dentz wrote: > Hi Isaac, > > On Mon, Oct 9, 2017 at 1:21 PM, Hermida, Isaac <Isaac.Hermida@xxxxxxxx> wrote: >> 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. > > Im pretty sure it is possible since chrome OS has done it: > > https://www.bluetooth.org/tpg/QLI_viewQDL.cfm?qid=22333 > > Though I can see the ATT over BR/EDR is in fact mandatory, the ICS says: > > C.1: Mandatory IF (SUM ICS 12/2 “Bluetooth Basic Rate Core Host > Configuration” OR SUM ICS 12/9 > “Bluetooth Basic Rate and Low Energy Combined Core Host > Configuration”) is supported, > otherwise Excluded. > I am really like a newbie on this so I have really nothing to help on that and I can be completely wrong with my comments. That link you send is about 2014, and the specification talks about 4.0. Probably the certification has been updated for 4.2. I think(?) that if we were 4.0, then we should not be accomplish that test case. >> 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. > > Afaik any service not registered over SDP should not be available over > BR/EDR, which is perhaps why the current code only does expose GATT > and GAP service, nothing else. Now I haven't found anything > prohibiting GATT discovery to happen over BR/EDR, just exchange MTU, > but the SDP service already carries the handles which I assume is what > PTS uses given there are tests like: > > 4.4.15 TP/GAD/SR/BV-07-C [Discover Primary Services using SDP - from Server] > That was the point that initially confused me and I did not understand the cert lab. I though that GATT/ATT was only LE. Detailed GATT/ATT information: Bluetooth Core Specification v5.0 https://www.bluetooth.com/specifications/bluetooth-core-specification According to this document (page 254), ‘GATT and ATT are not transport specific and can be used in both BR/EDR and LE. However, GATT and ATT are mandatory to implement in LE since it is used for discovering services.’ > Anyway, the end result is that we cannot completely disable ATT over > BR/EDR, and might have to push the bearer details up to the > application. > In fact, I think we should not. > Note that exposing the connected bearer is not enough in case a device > connects over both bearers the application will have no means to > distinguish in which bearer the command is coming from, this appears > to be a problem to Android HAL as well: > > https://android.googlesource.com/platform/hardware/libhardware/+/master/include/hardware/bt_gatt_server.h#71 > > So probably everyone is passing with a custom application which > detects, or asks the user input, when to return an error. > That was, in fact, our problem to pass this certification test cases. And based that I did not find other user complaining about that, I assume it is something "new" or well they pass the test by doing some custom adjustments. >> 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���)ߣ�
