PTS: Test framework: Bluetooth: GATT/SR/GAC/BI-01-C - FAIL

[KKopyscinski]

Describe the bug
When EATT is enabled, MTU exchange request should be met with response with error 0x06 (BT_ATT_ERR_NOT_SUPPORTED). Instead, 0x0000 is received.

Steps To Reproduce
GATT/SR/GAC/BI-01-C can be enabled by ICS GATT 2/3, which can be enabled for Core 5.2 spec:

Attribute Protocol Supported (L2CAP fixed EATT PSM supported)
Excluded IF SUM ICS 31/17 “Core Spec Version 4.2” OR SUM ICS 31/18 “Core Specification
Version 4.2 + HS” OR SUM ICS 31/19 "Core Specification Version 5.0" OR SUM ICS 31/20 "Core
Specification Version 5.1" OR (NOT GATT 2/1 “Attribute Protocol Supported over BR/EDR (L2CAP
fixed channel support)” AND NOT GATT 2/2 ” Attribute Protocol Supported over LE”) is supported,
otherwise Optional.

As this is new test, autopts should have it implemented:
https:/KKopyscinski/auto-pts/tree/gatt-sr-gac-bi-01

A clear and concise description of what the bug is.
PTS ends test with FAIL result, with verdict description:

FAILED: Request not supported error is expected but the received response code = 0x0000.

PTS logs attached
GATT_SR_GAC_BI_01_C_2020_10_15_09_53_01.zip

[carlescufi]

@KKopyscinski will you submit a fix for this?

[carlescufi]

@KKopyscinski will you submit a fix for this?

Answering the question myself: Yes, but in the future. This issue is just here to remind us of the qualification problem.

[github-actions]

This issue has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this issue will automatically be closed in 14 days. Note, that you can always re-open a closed issue at any time.

[carlescufi]

Downgrading to low because there is a plan to address all qualification-related issues in the Host in the near future as part of a new qualification automated test plan.

[Vudentz]

Afaik this is already handled:

https:/zephyrproject-rtos/zephyr/blob/master/subsys/bluetooth/host/att.c#L521

I wonder if this isn't a PTS problem as it should only work when sending on the non-fixed cid L2CAP channel.

[joerchan]

Looked into the logs, I cannot see the MTU exchange mentioned. The connection is disconnected immediately after the L2CAP credit based connection request & response.

[carlescufi]

Looked into the logs, I cannot see the MTU exchange mentioned. The connection is disconnected immediately after the L2CAP credit based connection request & response.

According to all of this information from @Vudentz and @joerchan, this seems to be a test issue, and not a Zephyr implementation one.

[github-actions]

This issue has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this issue will automatically be closed in 14 days. Note, that you can always re-open a closed issue at any time.

[joerchan]

@KKopyscinski Can you please clarify this issue?

[KKopyscinski]

@joerchan I don’t remember now more than I wrote here, but I’ll revisit this issue on Monday

[KKopyscinski]

Last time it was tested on PTS v7.6.x. I tested it today on v8.0.2 and it passes, so indeed it was PTS issue. I'm closing the issue