[jira] [Commented] (MYNEWT-702) BLE Host - duplicate connection update entries

["ASF subversion and git services (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/MYNEWT-702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15951721#comment-15951721 ] 

ASF subversion and git services commented on MYNEWT-702:
--------------------------------------------------------

Commit 091fbe124365ee8b109368928526ed86301b5af8 in incubator-mynewt-core's branch refs/heads/develop from [~ccollins476]
[ https://git-wip-us.apache.org/repos/asf?p=incubator-mynewt-core.git;h=091fbe1 ]

MYNEWT-702 BLE Host - duplicate update entries

If the application calls ble_gap_update_params() while an update
connection procedure for that connection is already in progress, the
existing entry gets re-inserted in the ble_gap_update_entries list. This
yields a cycle in the list, causing the host task to loop endlessly
during iteration.

More details:

1. Host initiates a connection update procedure; creates an entry and
   inserts it into the list (ble_gap_update_entries).

2. Host attempts to initiate a second connection update procedure for
   the same connection. Since an existing update procedure is ongoing,
   this attempt fails with a status code of BLE_HS_EALREADY.

3. On detecting the error, the ble_gap_update_params() function tries
   to clean up (goto done). Part of this cleanup involves freeing the
   update entry that got allocated earlier in the function but never got
   inserted into the list. In this case, no entry was allocated, but it
   looks like one was, because the entry pointer was used to detect a
   duplicate entry. Consequently, the entry is freed but never removed
   from the list!

4. The host initiates a third connection update procedure for the same
   connection. This time, no duplicate is detected because the entry in
   the list got corrupted when it was freed, making its connection
   handle value indeterminate. The host allocates the same entry from
   the pool, populates it, and inserts it into the list. Now the same
   entry is in the list twice, creating a cycle. When the host iterates
   this list, it loops forever.


> BLE Host - duplicate connection update entries
> ----------------------------------------------
>
>                 Key: MYNEWT-702
>                 URL: https://issues.apache.org/jira/browse/MYNEWT-702
>             Project: Mynewt
>          Issue Type: Bug
>            Reporter: Christopher Collins
>            Assignee: Christopher Collins
>             Fix For: v1_1_0_rel
>
>
> If the application calls ble_gap_update_params() while an update connection procedure for that connection is already in progress, the existing entry gets re-inserted in the ble_gap_update_entries list.  This yields a cycle in the list, causing the host task to loop endlessly during iteration.
> More details:
> # Host initiates a connection update procedure; creates an entry and inserts it into the list (ble_gap_update_entries).
> # Host attempts to initiate a second connection update procedure for the same connection.  Since an existing update procedure is ongoing, this attempt fails with a status code of BLE_HS_EALREADY.
> # On detecting the error, the ble_gap_update_params() function tries to clean up (goto done).  Part of this cleanup involves freeing the update entry that got allocated earlier in the function but never got inserted into the list.  In this case, no entry was allocated, but it looks like one was, because the entry pointer was used to detect a duplicate entry.  Consequently, the entry is freed but never removed from the list!
> # The host initiates a third connection update procedure for the same connection.  This time, no duplicate is detected because the entry in the list got corrupted when it was freed, making its connection handle value indeterminate.  The host allocates the same entry from the pool, populates it, and inserts it into the list.  Now the same entry is in the list twice, creating a cycle.  When the host iterates this list, it loops forever.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)