Hello:

Was wondering if there were any folks out there that could comment on something 
regarding a disconnect issue with an Android Phone running 7.1.1 and our 
bluetooth stack (the controller).

What appears to be happening is this: 

* Nimble wants to do Data Length Extension and enqueues a LL_LENGTH_REQ when a 
connection gets created. Nimble is a peripheral btw.
* The Android controller wants to do a feature exchange so it enqueues a 
LL_FEATURE_REQ.
* Android controller sends the LL_FEATURE_REQ.
* Nimble controller sends a LL_LENGTH_REQ.
* Once the nimble controller succeeds in sending the LL_LENGTH_REQ, it sends 
the LL_FEATURE_RSP.
* Android responds with a LL_REJECT_IND with error code 0x24 LMP PDU not 
allowed.
* Android resends the LL_FEATURE_REQ.
* Nimble responds with LL_FEATURE_RSP.
* Android sends LL_LENGTH_REQ
* Nimble controller sends LL_LENGTH_RSP.
* All goes fine until nimble controller times out due to a failed LL control 
procedure: the nimble stack never received a LL_LENGTH_RSP.

NOTE: from the above it is hard to say why the Android controller sent the 
LL_REJECT_IND. Basically, it appears that the LL_LENGTH_REQ messed up the 
Android controller as the Android controller was expecting a LL_FEATURE_RSP.

My questions are the following:
* I think this is a bug on the part of the Android controller. The 
specification allows for non-real time response to control PDU’s and it is 
quite possible that a controller starts a procedure “at the same time” that the 
remote controller starts a procedure. What I would have expected is that the 
Android controller should have responded to the LL_LENGTH_REQ with a 
LL_LENGTH_RSP. Eventually, the Android controller gets the LL_FEATURE_RSP and 
all should have been fine. Do folks agree with this?
* A controller should not use a LL_REJECT_IND as a generic response when a 
controller sends something unexpected. The LL_REJECT_IND is only used during 
encryption procedures, connection parameter request update procedures and in a 
couple of cases where there are Control Procedure collisions. Note that the 
scenario described above is NOT one of the Control Procedure collisions 
mentioned in the specification.

Thanks!


Reply via email to