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. -- Luiz Augusto von Dentz -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
