Zephyr Master/Slave not conforming with Core Spec. 5.2 connection policies

[runegrunnet]

Describe the bug
According to the Bluetooth Specification, Core 5.2, on any multiple incoming connection requests from a Master, the slave device shall ignore such requests if it is already in a connection with that Master.

Also, it is not allowed for a Master to initiate multiple connections to the same Slave on a released product.

See [1] and [2].

To Reproduce
Steps to reproduce the behavior:
It was reproduced by having a Master application issue two connection requests towards the same Zephyr Slave device.
Both devices had privacy enabled, using Private Resolvable Addressing.

Expected behavior
An initiator shall not send a connection request to an
advertiser it is already connected to.
If an advertiser receives a connection request from an initiator it is already
connected to, it shall ignore that request.

It seems that policies are not enforced - a Zephyr Master can connect multiple times to the same identified slave (currently only verified by code inspection) and a Zephyr slave can accept multiple connection requests from the same identified Master (reproduced/verified in practice).

Expected behavior would be that the Zephyr slave would ignore multiple connection indication packets from the same identified Master.

Impact
The currently allowed spec. violation causes a risk that a product based on the Zephyr project cannot be qualified if/when the qualification test suite from Bluetooth SIG would check for the compliance on these connection policies.

Screenshots or console output

Environment (please complete the following information):

Additional context

References

[1] [CS 5.2, Vol 6, Part B, 1.1.1 Permitted state and role combinations]

The Link Layer may optionally support multiple state machines. If it does
support multiple state machines, then any combination of states and roles may
be supported. In particular, the Link Layer is permitted to be in the Connection
State multiple times with any mix of Master Role and Slave Role. However, any
two devices shall not have more than one connection between them.

[2] [CS 5.2, Vol 6, Part B, 4.5 Connection state]

When two devices are in a connection, the two devices act in different roles. A
Link Layer in the Master Role is called a master. A Link Layer in the Slave Role
is called a slave. The master controls the timing of a connection event. A
connection event is a point of synchronization between the master and the
slave. There shall be only one connection, whether or not established, between
two LE device addresses. An initiator shall not send a connection request to an
advertiser it is already connected to.
If an advertiser receives a connection request from an initiator it is already
connected to, it shall ignore that request.

[carlescufi]

@rugr-demant this is a very useful feature while debugging multiple connections. I would be against removing it entirely, but if you think this is something you'd like to have please send a PR that adds a new Kconfig option (which could be disabled by default) that turns this "feature" on.

[cvinayak]

I would relate this feature to blacklisting connected addresses. This would require added resources in terms of RAM and CPU time. Also, the CPU time are in the order of n supported simultaneous connections supported. With privacy support, in addition to identity, the resolvable address blacklist too would be required, with deferred resolutions.

[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.

[runegrunnet]

I am requesting to re-open this issue.
It was closed by mistake/inactivity and has still not been addressed yet.

The Zephyr stack is still vulnerable/does not comply with the Core Bluetooth Spec. 5.2.