#91 Connection table divergencies between BT module and stack

[Mustafa Yuecel]

I found a bug which explains the non-possibility to establish new connection, although e.g. only 1-2 connection are established. The Bluetooth stack maintains some "zombie" connection entries, as showed below. In combination that the number of connection is limited (BT_HCI_MAX_NUM_CON), the stack "looses" entries for new connections.

Another point: BT_HCI_MAX_NUM_CON is set to 8. As far as I know a Bluetooth module can maintain 7 Slaves and 1+ Masters. Even Zeevo can maintain 3 Master --> 10 links

I wrote a command which prints out a dump of the connection table

#ConnEntry: ConnState, ShortAddress, AppConnHandle, ModuleConnHandle

0: 0, 02:09, -1, -1
1: 3, 00:00, 7, -1
2: 3, 00:00, 123, -1
3: 3, 00:00, 124, -1
4: 3, 00:00, 147, -1
5: 5, 01:fe, 195, 1
6: 0, 00:d5, -1, -1
7: 0, 01:fe, -1, -1

ConnState:
0: Invalid connection (free entry)
3: Create connection request has been sent, waiting for ack
5: Connection is open and ready

ConnEntries 1-4 remains UNUSABLE for the stack...

[Mustafa Yuecel]

Logged In: YES
user_id=749518

[bt-cmd@btnode]$bt dump
conn_request: 8
pin_request: 0
0: 2, 02:24
1: 2, 01:ec
2: 2, 02:24
3: 2, 02:01
4: 2, 02:01
5: 2, 02:15
6: 2, 02:15
7: 2, 02:01

[Mustafa Yuecel]

Logged In: YES
user_id=749518

Suggestions to improve the situation:

- reject connection request (instead of expire the timeout, see also bug 1543965)
- improve the state-machine (e.g. atomar transitions)
- verify/probe the connection table by the Bluetooth module (e.g. with create_connection or (better) another HCI command with a con_handle param)