New issue
Advanced search Search tips
Note: Color blocks (like █ or █) mean that a user may not be available. Tooltip shows the reason.

Issue 852575 link

Starred by 1 user
Status: Verified
Owner:
█ mcchou@chromium.org
Last visit > 30 days ago
Closed: Jul 3
Cc:
snanda@chromium.org
█ sonnysasaka@chromium.org
█ dmitrygr@chromium.org
█ dwmclary@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 1
Type: Feature



Sign in to add a comment

Implement passkey entry pairing as initiator and responder roles

Project Member Reported by mcchou@chromium.org, Jun 13 2018 
This tracks the implementation of passkey entry pairing for nitiator and responder roles.

The work items include
 - provide public APIs for a daemon to register itself as the observer and handler for passkey display and request
 - modify test program to verify the APIs

The requirements include
 - run the test program to test against a LE keyboard to verify the role as a initiator of pairing
 - Run the test program on two DUTs - one as the initiator and one as the responder to verify the role as a responder of pairing
Project Member

Comment 1 by bugdroid1@chromium.org, Jun 26 2018 

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/platform/newblue/+/ab7baf8bfd0f6f7932867b92e8b1f726a576a2bf

commit ab7baf8bfd0f6f7932867b92e8b1f726a576a2bf
Author: Miao-chen Chou <mcchou@chromium.org>
Date: Mon Jun 25 23:32:24 2018

sm,build: implement passkey entry pairing and its public APIs

This patch includes the following changes.

- Introduce 5 SM phases - SM_PHASE_MCONF_SENT, SM_PHASE_MCONF_RECEIVED,
  SM_PHASE_SCONF_READY, SM_PHASE_SCONF_SENT, SM_PHASE_SCONF_RECEIVED to
  distinguish the sending and receiving of master and slave confirmation
  values, so that the transition is feasible with the wait time for
  passkey entry
- Introduce APIs and callbacks for a daemon to register itself as the
  observer for passkey display and request events and provide a daemon
  a function to respond to the passkey request
- Allow address type BT_ADDR_TYPE_LE_PUBLIC to be sent as the identity
  address
- Modify new_blue_test to adopt HCI_DISP_CAP_KBD_DISP and make use of the
  newly-added APIs to verify the passkey entry pairing
- Expose timer.h for new_blue_test use

BUG= chromium:852575 
TEST=To verify the initiator role, run the test program on veyron_minnie
     with "restart bluetoothd && new_blue_test pair
     <the target LE keyboard address>" and enter passkey on the target LE
     keyboard
     To verify the responder role, run the test program on two
     veyron_minnies with "restart bluetoothd && new_blue_test" and
     "restart bluetoothd && new_blue_test pair"
     Verified that the pairing phase transit to SM_PHASE_DONE for the
     above test cases

Change-Id: Id6fcb1f5d9e6c22d1d9c71654c567f1584feec7f

[modify] https://crrev.com/ab7baf8bfd0f6f7932867b92e8b1f726a576a2bf/sm.c
[modify] https://crrev.com/ab7baf8bfd0f6f7932867b92e8b1f726a576a2bf/sm.h
[modify] https://crrev.com/ab7baf8bfd0f6f7932867b92e8b1f726a576a2bf/test.c
[modify] https://crrev.com/ab7baf8bfd0f6f7932867b92e8b1f726a576a2bf/Makefile
[modify] https://crrev.com/ab7baf8bfd0f6f7932867b92e8b1f726a576a2bf/timer.h

Comment 2 by mcchou@chromium.org, Jul 3

Status: Fixed (was: Assigned)

Comment 3 by pbath...@chromium.org, Sep 26

Status: Verified (was: Fixed)
►

Sign in to add a comment