intel
Pts for br edr gap
- gap: add conn command for BR transport
In order to support BR/EDR PTS test environment, add a GAP conn command for BR transport.
- GAP: Add GAP pair command with sec level setting
Add a command gap_pair_with_sec_level to set a specific security level when starting a pairing procedure.
If peer is already paired IUT is expected to enable security (encryption) with peer. If peer is not paired IUT shall start pairing process. Possible values for the Security_level parameter are: 0 - Only for BR/EDR special cases, like SDP 1 - No encryption and no authentication 2 - Encryption and no authentication (no MITM) 3 - Encryption and authentication (MITM) 4 - Authenticated Secure Connections and 128-bit key
- GAP: Add a function clear_discov_results
Add a function clear_discov_results to clear discovery results.
- GAP: Add a event for encryption failed
Add a event GAP_EV_ENCRYPTION_FAILED=91 for encryption failed.
Handle the event GAP_EV_ENCRYPTION_FAILED.
Put the received data to gap.encryption_failed_rcvd.data.
Add a function gap_wait_for_encryption_fail to wait the encryption failed event.
Hi,
Some comments inline, But in general the starting point should be to agree on how we are going to identify BR/EDR in BTP, I see 3 options
- dedicated address type - allows to reuse most of the events (and possible comments), few BR/EDR specific can be tuned via dedicated new commands (or BR/EDR only parameters/flags in existing commands)
- BR/EDR dedicated commands and events with no address type - this makes BR/EDR very explicit in BTP but would lead to duplication of events and commands (especially in GAP and L2CAP services)
- dedicated BTP services for BR/EDR - eg. GAP_BREDR, L2CAP_BREDR etc, this makes BR/EDR quite separated from current LE-only implementation but could also lead to code/function duplication, also could be trouble some with dualmode scenarios, and we have few BR/EDR specific bits in GAP already (from very early times of autopts)
My personal selection would be option 1) but would be good to get opinion (and ideas) from others
Yes, option 1 is also my action. We can use a dedicated address type for BR, such as 0xFF?
Hi,
While BTP doesn't necessarily follow sHCI address types, 0xff is used for "No address provided" (aka. anonymous advertisement) in advertising reports, and 0xfe is used for "Resolvable Private Address (Controller unable to resolve)" in directed advertising. And 0x02 and 0x03 are used for own address types in HCI.
I'd suggest to use something maybe from the middle range, just to avoid confusion? eg 0x7f ?
But maybe other have some thoughts on this as well? @jhedberg @Thalley @mringwal
Well, BTstack internally uses 0xfc for SCO connections, 0xfd for ACL, and 0xfe for Unknown/Invalid connection types.
0x02 and 0x03 are from HCI for Public and Random Identity Addresses.
If the addresses are for internal BTP usage, I'm fine with placing them also in 0xf0-0xff range. Maye use 0xe0..0ef to keep things tidy (similar to 0x7f suggestion, just not so far away). I guess there will be a mapping in each BTP tester anyway.
Hi,
While BTP doesn't necessarily follow sHCI address types, 0xff is used for "No address provided" (aka. anonymous advertisement) in advertising reports, and 0xfe is used for "Resolvable Private Address (Controller unable to resolve)" in directed advertising. And 0x02 and 0x03 are used for own address types in HCI.
I'd suggest to use something maybe from the middle range, just to avoid confusion? eg 0x7f ?
But maybe other have some thoughts on this as well? @jhedberg @Thalley @mringwal
I think we either follow the HCI address types, or we don't.
If we do, then that limits what we can set (keep in mind that there are several address type value ranges in the HCI spec). If we don't, then the actual values of the BTP address types doesn't really matter, and we should be able to use any values, i.e. there's no advantage of using specific ranges.
the thing is that BR/EDR address has no type, it is just address
and while I agree that BTP can use any values, it might be less confusing if those don't overlap
and while I agree that BTP can use any values, it might be less confusing if those don't overlap
I'm more worried about when they overlap / share some value if they are not the same :D If they overlap, users may wrongly assume that they can directly use the types from BTP for HCI or vice versa.
the thing is that BR/EDR address has no type, it is just address
I know that's the conclusion when one reads the spec word by word. For practical purposes however, would it make sense to do two simplifications/clarifications:
- treat a BR/EDR address as public, since the value is the same as an LE public address in the case of a dual-mode device
- Disambiguate transport from address type, e.g. "public address over BR/EDR" vs "public address over LE". Of course with this, some types become impossible on some transports.
2. Disambiguate transport from address type
Just to add to this: the disambiguation can be done at least in two alternative ways
- have a dedicated "transport" field in the BTP messages
- have transport-specific BTP messages ("this message only applies to transport X")
I suddenly realized that adding a dedicated address type to existing commands is not a good idea.
Some Windows handles are shared by BR and LE. When this window handle is called, we cannot confirm which transport we need to transfer data on. If we need to correctly know which transport this Windows handle should be transmitting data on, we need to maintain a test case list for br or le. However, this is not a good idea.
So we only have one way, which is to perform the same BTP command on all transports once.
And my current approach is that auto pts only sends one BTP command. For this BTP command, I will use the address to find the valid connect from le connects pool. If it cannot be found and it is a public address, I will search it on br connects pool.
Hmm initially BTP GAP service was meant to handle both LE and BR/EDR devices, but maybe it will be simpler to just make it 'LE-only' (ie remove any BR/EDR mentions from settings etc) and just have dedicated services for BR/EDR (GAP_BR, L2CAP_BR), other services (like SDP, RFCOMM etc) are BR/EDR by definition anyway...
This was BR/EDR can be handled separately and there is no need to mix it into existing de facto LE-only services.
Hmm initially BTP GAP service was meant to handle both LE and BR/EDR devices, but maybe it will be simpler to just make it 'LE-only' (ie remove any BR/EDR mentions from settings etc) and just have dedicated services for BR/EDR (GAP_BR, L2CAP_BR), other services (like SDP, RFCOMM etc) are BR/EDR by definition anyway...
This was BR/EDR can be handled separately and there is no need to mix it into existing de facto LE-only services.
But if we do so, it means auto-pts will be divided into two parts. And there can not be used at the same time because the BR and LE case will share same one windows handle. A new set of BTP commands is needed for BR. Right?
If so, I need to start my task for this change right now.
Hmm initially BTP GAP service was meant to handle both LE and BR/EDR devices, but maybe it will be simpler to just make it 'LE-only' (ie remove any BR/EDR mentions from settings etc) and just have dedicated services for BR/EDR (GAP_BR, L2CAP_BR), other services (like SDP, RFCOMM etc) are BR/EDR by definition anyway...
Background: The PTS Windows handle is partially shared between BR and BLE test cases.
I have evaluated and if BR uses the new BTP service sets, it means that the existing PTS windows handle needs to add BTP service support for BR. There are two ways to achieve this, Option 1: Pre save the test case list for BR and BLE. Check the table in the Windows handle to determine whether the current case belongs to BR or BLE. Maintaining such a table requires a huge amount of work, as the case list changes with the release of PTS versions. In addition, the existing Windows handle also incurs significant changes and maintenance costs.
Option 2: Provide a new Windows handle for BR. When in BLE mode, the Windows handle is routed to BLE's Windows handle. When in BR mode, the windows handle is routed to the windows handle of BR. This means that the patterns of BR and BLE are mutually exclusive. There is also a issue with this method, as it cannot support PTS project that enables both BLE and BR simultaneously.
So the suggestion is still for BR and BLE to share the current BTP service sets. For unsupported cases, support them by extending the command set of the service.
This issue has been under discussion or pending more than 6 months. We have been blocked long time without any progress. I think we need to move forward. If there is really no feasible way and my suggestion can not be accepted, I suggest forking another auto-pts for supporting PTS of BR and BR/BLE combo. Because I don't see any outcome for this issue.
@Thalley @jhedberg What do you think? Any idea?
@lylezhu2012 what do you mean by "PTS Windows handle"?
The public LE BD_ADDR is generally the same as the Classic BD_ADDR but a an ACL LE connection and a ACL Classic connection will have different HCI Connection Handles.
I unfortunately cannot spend too much time on designing AutoPTS/BTP for BR/EDR, so I'll have to defer to @sjanc or @jhedberg (whom I think also have more knowledge/experience than I on BR/EDR)
@lylezhu2012 what do you mean by "PTS Windows handle"?
In PTS, each test case may pop up the dialog box when doing PTS test. And each dialog box has a id. Auto-pts will send the BTP frame according to the id of dialog box. Such as, if the id is 200, then the function hdl_wid_200 is provided by auto-pts to handle this dialog box.
And the dialog box with same id may be shared by the different test cases, including BR and BLE test cases.
Hi,
I've been thinking a bit recently on how this should be handled. Here is my suggestion:
There are few ideas on how we could add BR/EDR but since we seem to be going back and forth on this and none of them is ideal, something needs to be selected.
I suggest to go with address type that indicate BR/EDR transport (0xe0 as suggested few comments above). This allows to use most of existing events and clearly allows to differentiate transports used in BTP (which is important for dual mode tests were both LE and BR/EDR are connected).
Regarding changes in this PR,
- I suggest to extended BTP with a bit more generic events and commands. Since we already started to add versioned commands I suggest adding PairV2 command that allows for more control over expected pairing process (not only required sec level, but also maybe flags that would allow fine tuning like SC, MITM etc, as currently this is implicitly done by settings and IOcapa). This command should handle both LE and BR/EDR, it is also fine to have transport specific fields there (ie mark some option valid only for specific transport).
- For BTP event I suggest extend it in more generic way, currently we have security change event only which is for 'successful' case only, and error are handled by timeouting. I think we can add generic 'Encryption Change' event with status that would be used to indicate encryption change status, and maybe current security level too. It would eventually replace Security Level Change event, should also cover both LE and BR/EDR cases
- Regarding same MMIs being used for both LE and BR/EDR: this is not uncommon for PTS and thus it is fine to have various paths in MMI handlers. Selection of path (transport used in this particular case) can be done based on MMI description (in PTS is using different string for BR/EDR), supported settings in IUT or even test case name. We do that already in numerous places, it is fine to update MMI handler (but keep in mind other IUTs, so change should be 'backward compatible', especially if it is common MMI). WIDParams class provides this sort of info to WID handler.
Let me know if this is fine for you!
Also, I'd like to do at least some smoke testing of this in office, what board should I use?
- I suggest to extended BTP with a bit more generic events and commands. Since we already started to add versioned commands I suggest adding PairV2 command that allows for more control over expected pairing process (not only required sec level, but also maybe flags that would allow fine tuning like SC, MITM etc, as currently this is implicitly done by settings and IOcapa). This command should handle both LE and BR/EDR, it is also fine to have transport specific fields there (ie mark some option valid only for specific transport).
It is fine for me.
- For BTP event I suggest extend it in more generic way, currently we have security change event only which is for 'successful' case only, and error are handled by timeouting. I think we can add generic 'Encryption Change' event with status that would be used to indicate encryption change status, and maybe current security level too. It would eventually replace Security Level Change event, should also cover both LE and BR/EDR cases
Sure, I will add more generic commands/events from a protocol perspective if needed.
- Regarding same MMIs being used for both LE and BR/EDR: this is not uncommon for PTS and thus it is fine to have various paths in MMI handlers. Selection of path (transport used in this particular case) can be done based on MMI description (in PTS is using different string for BR/EDR), supported settings in IUT or even test case name. We do that already in numerous places, it is fine to update MMI handler (but keep in mind other IUTs, so change should be 'backward compatible', especially if it is common MMI). WIDParams class provides this sort of info to WID handler.
Yes, we can identify BR and BLE based on the MMI description, but the premise is that they are really different. Since I don't re-run the BLE test case, I can't compare the descriptions of BLE and BR to see if they are really different for the same MMI. But I can raise it when I encounter relevant problems.
Also, I'd like to do at least some smoke testing of this in office, what board should I use?
I am using MIMXRT1170-EVKB + 2EL(CONFIG_BT_NXP_NW612). So, I suggest you use such a platform. Is it convenient for you to get the platform? If not, Hi @dleach02 could you help solve this problem?
The changes are applied by PR https://github.com/auto-pts/auto-pts/pull/1407. Close it.