Here are some relevant errors from /var/log/messages:
...
2018-07-13T13:06:03.689128-04:00 ERR cryptohomed[1885]: Failed to read keyset file for user c3448e7172bdfde817acdc78d215853f2b76ec10
2018-07-13T13:06:03.832564-04:00 INFO cryptohomed[1885]: Pinweaver GetLog: 65537
2018-07-13T13:06:03.832621-04:00 ERR cryptohomed[1885]: Pinweaver error on pinweaver GetLog operation: 65537
2018-07-13T13:06:03.832639-04:00 ERR cryptohomed[1885]: Couldn't get LE Log.
2018-07-13T13:06:03.832654-04:00 ERR cryptohomed[1885]: InsertLECredential failed: hash tree error.
2018-07-13T13:06:03.832671-04:00 WARNING cryptohomed[1885]: Failed to encrypt or write the new keyset
2018-07-13T13:06:03.833308-04:00 ERR cryptohomed[1885]: Failed to read keyset file for user c3448e7172bdfde817acdc78d215853f2b76ec10
2018-07-13T13:06:12.630050-04:00 INFO session_manager[1214]: [INFO:session_manager_impl.cc(802)] LockScreen() method called.
2018-07-13T13:06:12.633336-04:00 ERR cryptohomed[1885]: Failed to read keyset file for user c3448e7172bdfde817acdc78d215853f2b76ec10
2018-07-13T13:06:12.664598-04:00 INFO session_manager[1214]: [INFO:session_manager_impl.cc(807)] HandleLockScreenShown() method called.
...
2018-07-13T13:06:22.401114-04:00 ERR cryptohomed[1885]: Failed to read keyset file for user c3448e7172bdfde817acdc78d215853f2b76ec10
2018-07-13T13:06:22.423674-04:00 ERR cryptohomed[1885]: DecryptFinal Error: 101077092: digital envelope routines, EVP_DecryptFinal_ex, bad decrypt
2018-07-13T13:06:23.272464-04:00 ERR cryptohomed[1885]: AsymmetricDecrypt: Error performing RSA decrypt: TPM_RC_VALUE
2018-07-13T13:06:23.272487-04:00 ERR cryptohomed[1885]: Error decrypting plaintext: TPM_RC_VALUE
2018-07-13T13:06:23.272498-04:00 ERR cryptohomed[1885]: The TPM failed to unwrap the intermediate key with the supplied credentials
2018-07-13T13:06:26.341713-04:00 ERR cryptohomed[1885]: Failed to read keyset file for user c3448e7172bdfde817acdc78d215853f2b76ec10
2018-07-13T13:06:26.357727-04:00 ERR cryptohomed[1885]: Failed to read keyset file for user c3448e7172bdfde817acdc78d215853f2b76ec10

Right. Curiously, earlier in the log I see:
2018-07-12T20:25:11.415113-04:00 INFO cryptohomed[1885]: Pinweaver IsSupported: 0

From what I can tell it looks like Cr50 is up to date:

96:2018-07-12T18:41:34.943158-04:00 NOTICE cr50-update.sh[16718]: Starting
797:2018-07-12T18:41:34.966917-04:00 NOTICE cr50-update.sh[16718]: Will use trunks_send
798:2018-07-12T18:41:34.967562-04:00 NOTICE cr50_get_name[16729]: updater is /usr/sbin/gsctool -t
799:2018-07-12T18:41:34.995972-04:00 NOTICE cr50_get_name[16738]: board_id: '5a5a4146:a5a5beb9:00007f80' board_flags: '0x00007f80', extension: 'prod'
800:2018-07-12T18:41:48.783504-04:00 NOTICE cr50-update.sh[16718]: success (1)
1473:2018-07-12T18:48:01.358145-04:00 INFO kernel: [    0.333516] cr50_i2c i2c-GOOG0005:00: cr50 TPM 2.0 (i2c 0x50 irq 24 id 0x28) [gentle shutdown]
1782:2018-07-12T18:48:04.052057-04:00 NOTICE cr50-update[1753]: Starting cr50 update
1783:2018-07-12T18:48:04.060208-04:00 NOTICE cr50_get_name[1755]: updater is /usr/sbin/gsctool -s
1813:2018-07-12T18:48:04.138661-04:00 NOTICE cr50_get_name[1811]: board_id: '5a5a4146:a5a5beb9:00007f80' board_flags: '0x00007f80', extension: 'prod'
1814:2018-07-12T18:48:04.139926-04:00 NOTICE cr50-update[1817]: hashing /opt/google/cr50/firmware/cr50.bin.prod
1825:2018-07-12T18:48:04.201412-04:00 NOTICE cr50-update[1856]: creating new state /var/cache/cr50.a3055efbc9.state
1828:2018-07-12T18:48:04.222755-04:00 NOTICE cr50-update[1877]: version retrieved: start#012target running protocol version 6#012keyids: RO 0xaa66150f, RW 0xde88588d#012offsets: backup RO at 0x40000, backup RW at 0x4000#012Current versions:#012RO 0.0.10#012RW 0.3.7
1843:2018-07-12T18:48:04.330567-04:00 NOTICE cr50-update[1917]: Will run /usr/sbin/gsctool -s -u /opt/google/cr50/firmware/cr50.bin.prod
1846:2018-07-12T18:48:04.356753-04:00 NOTICE cr50-update[1922]: cr50 is running updated firmware
1858:2018-07-12T18:48:04.549775-04:00 NOTICE cr50-result[1981]: Will check Board ID settings
1866:2018-07-12T18:48:04.638579-04:00 NOTICE cr50-result[2009]: ERROR: Flag has been set differently.
1890:2018-07-12T18:48:04.741957-04:00 NOTICE cr50-metrics[2052]: Finished, flags 0x00007f80, RLZ 0x5a5a4146, bid 0x5a5a4146
2018:2018-07-12T18:48:05.335948-04:00 INFO kernel: [    6.022396] hid-generic 0006:18D1:502C.0004: hidraw2: <UNKNOWN> HID v0.02 Device [Integrated U2F] on u2fd-tpm-cr50-18D1:502C
2093:2018-07-12T18:48:12.839997-04:00 INFO cryptohomed[2069]: Successfully invalidated inactive Cr50 RW
4046:2018-07-12T20:25:05.380617-04:00 INFO kernel: [    0.345358] cr50_i2c i2c-GOOG0005:00: cr50 TPM 2.0 (i2c 0x50 irq 24 id 0x28) [gentle shutdown]
4358:2018-07-12T20:25:07.344592-04:00 NOTICE cr50-update[1593]: Starting cr50 update
4359:2018-07-12T20:25:07.351437-04:00 NOTICE cr50_get_name[1617]: updater is /usr/sbin/gsctool -s
4406:2018-07-12T20:25:07.433521-04:00 NOTICE cr50_get_name[1662]: board_id: '5a5a4146:a5a5beb9:00007f80' board_flags: '0x00007f80', extension: 'prod'
4410:2018-07-12T20:25:07.437066-04:00 NOTICE cr50-update[1664]: hashing /opt/google/cr50/firmware/cr50.bin.prod
4433:2018-07-12T20:25:07.526426-04:00 NOTICE cr50-update[1724]: current state 3 in /var/cache/cr50.a3055efbc9.state
4434:2018-07-12T20:25:07.532807-04:00 NOTICE cr50-update[1729]:  not running
4444:2018-07-12T20:25:07.674920-04:00 NOTICE cr50-result[1769]: Will check Board ID settings
4446:2018-07-12T20:25:07.726085-04:00 NOTICE cr50-result[1798]: ERROR: Flag has been set differently.
4483:2018-07-12T20:25:08.055800-04:00 NOTICE cr50-metrics[1899]: Finished, flags 0x00007f80, RLZ 0x5a5a4146, bid 0x5a5a4146
4568:2018-07-12T20:25:08.919023-04:00 INFO kernel: [    4.940504] hid-generic 0006:18D1:502C.0004: hidraw2: <UNKNOWN> HID v0.02 Device [Integrated U2F] on u2fd-tpm-cr50-18D1:502C
4640:2018-07-12T20:25:13.258811-04:00 INFO cryptohomed[1885]: Successfully invalidated inactive Cr50 RW
5968:2018-07-13T08:35:28.323831-04:00 INFO kernel: [ 6129.578837] calling  i2c-GOOG0005:00+ @ 24301, parent: i2c-7, cb: cr50_resume
10376:2018-07-13T09:34:50.320467-04:00 INFO kernel: [ 9537.925584] calling  i2c-GOOG0005:00+ @ 12022, parent: i2c-7, cb: cr50_resume
11981:2018-07-13T12:50:48.317470-04:00 INFO kernel: [16520.722769] calling  i2c-GOOG0005:00+ @ 32194, parent: i2c-7, cb: cr50_resume

The RSA decrypt error in the logs is possibly due to just incorrect password entered (e.g. PIN entered instead of password due to confusion after smartlock & PIN failed to work). But the first error is interesting:
2018-07-13T13:06:03.689128-04:00 ERR cryptohomed[1885]: Failed to read keyset file for user c3448e7172bdfde817acdc78d215853f2b76ec10
2018-07-13T13:06:03.832564-04:00 INFO cryptohomed[1885]: Pinweaver GetLog: 65537

1) We are attempting to read a non-existing VKK file.
2) Why is PinWeaver even invoked, even though Pinweaver IsSupported: 0 at start, and there were no reboots since then. 
3) Why is IsSupported == 0 even though RW is 0.3.7:
2018-07-12T18:48:04.222755-04:00 NOTICE cr50-update[1877]: version retrieved: start#012target running protocol version 6#012keyids: RO 0xaa66150f, RW 0xde88588d#012offsets: backup RO at 0x40000, backup RW at 0x4000#012Current versions:#012RO 0.0.10#012RW 0.3.7

To answer part of question 2 - no reboot between tests

Ah, PinWeaver IsSupport is printed from ConvertStatus in cryptohome/pinweaver_le_credential_backend.cc, and there it means success. So, PinWeaver *is* supported on 0.3.7, as it should be. And my items (2) and (3) from #6 are wrong.

But was a PIN ever set up for login? Probably not.

Jacob, please take a look. Looks like the case, where a PIN was set for unlock, PinWeaver is now enabled, but there was never a PIN keyset created. Still, attempting to use a PIN keyset for unlock instead of the old PIN-checking approach. And then the whole tail of errors because of that - looking for a non-existent keyset; getting error -> deciding to replay the log; the log doesn't exist etc.
How do we decide if an old or new PIN-checking approach is used?

No - I did not have a pin setup on this specific device, I only added one for testing. I did have Smart Lock setup prior 

error 65537 is PW_ERR_TREE_INVALID

When should PinWeaver be returning that?

That pretty much means a tree reset is needed. It should only happen when the tree has invalid parameters or doesn't exist.

The only time LECredentialManager performs a Reset on Pinweaver backend is in the LECredentialManager ctor when it is creating the low_entropy_creds directory for the first time. If the directory already exists, reset isn't executed.

The logs don't show "Reset" being called (it's possible it was called earlier).

If no PIN was ever set up for this device, no PinWeaver operations should have executed (apart from reset), so the state in Cr50 *should* be unchanged.

Can you verify whether /home/.shadow/low_entropy_creds exists?

Reset seems to be called here:
2018-07-12T18:48:06.472262-04:00 INFO cryptohomed[2069]: Pinweaver Reset: 0

Oh great. Well then that suggested the state of the Cr50 is messed up for some reason (and it's unrecoverable) :(

Q) Can you verify whether /home/.shadow/low_entropy_creds exists?

No, this specific device is not in developer mode, just on the developer channel. 

Basically, here's what happened:
0) Originally, cr50 didn't support PinWeaver, so we were getting
2018-07-11T11:45:24.980917-04:00 WARNING cryptohomed[1875]: PinWeaverIsSupported: command failed: 0x57f Unknown error: 1407 (0x57f)
2018-07-11T11:45:24.980942-04:00 ERR cryptohomed[1875]: TPM error on pinweaver IsSupported operation: Unknown error: 1407 (0x57f)

1) Cr50 was updated to 0.3.7
2018-07-12T18:48:04.222755-04:00 NOTICE cr50-update[1877]: version retrieved: start#012target running protocol version 6#012keyids: RO 0xaa66150f, RW 0xde88588d#012offsets: backup RO at 0x40000, backup RW at 0x4000#012Current versions:#012RO 0.0.10#012RW 0.3.7

2) We got response that it is supported and successfully reset the tree:
2018-07-12T18:48:06.367858-04:00 INFO cryptohomed[2069]: Pinweaver IsSupported: 0
2018-07-12T18:48:06.472262-04:00 INFO cryptohomed[2069]: Pinweaver Reset: 0


Curiously, memd decided to die right at this moment,not sure if can be related:
2018-07-12T18:48:06.493755-04:00 WARNING crash_reporter[2602]: [user] Received crash notification for memd[2585] sig 6, user 0 (handling)

3) Asked if supported again shortly after that, still everything is fine:
2018-07-12T18:48:08.911417-04:00 INFO cryptohomed[2069]: Pinweaver IsSupported: 0

4) Reboot
2018-07-12T19:08:44.273581-04:00 INFO VMBOOT(3)[13051]: [    0.000000] Linux version 4.14.43-05062-g1048e72698de (chrome-bot@swarm-cros-54) (gcc version 4.9.x 20150123 (prerelease) (4.9.2_cos_gg_4.9.2-r191-71959ce8f47f676a26bb21da7117101d9d73867e_4.9.2-r191)) #1 SMP PREEMPT Thu May 31 11:00:23 PDT 2018#015

5) At cryptohome start asked a couple time if PinWeaver is supported, got 'yes':
2018-07-12T20:25:09.061947-04:00 INFO cryptohomed[1885]: Pinweaver IsSupported: 0
...
2018-07-12T20:25:11.415113-04:00 INFO cryptohomed[1885]: Pinweaver IsSupported: 0

6) Next thing we do is GetLog, and it fails:
2018-07-13T13:06:03.832564-04:00 INFO cryptohomed[1885]: Pinweaver GetLog: 65537
2018-07-13T13:06:03.832621-04:00 ERR cryptohomed[1885]: Pinweaver error on pinweaver GetLog operation: 65537


So, from cr50 point of view it was just:
 - Reset
 - Ping (1 or 2 times)
 - GetLog - fail here

Reset tree shouldn't succeeded unless the flash was written (see: https://cs.corp.google.com/chromeos_public/src/platform/ec/common/pinweaver.c?rcl=3099f182b5fb03ac6f05e0d15eb81b9438d252aa&l=613).

This is the code that generates the particular error that was returned: https://cs.corp.google.com/chromeos_public/src/platform/ec/common/pinweaver.c?rcl=3099f182b5fb03ac6f05e0d15eb81b9438d252aa&l=343

I am wondering if the initialization code isn't being called: https://cs.corp.google.com/chromeos_public/src/platform/ec/common/pinweaver.c?rcl=3099f182b5fb03ac6f05e0d15eb81b9438d252aa&l=1273

Still, three separate questions remain. PinWeaver doesn't seem to be the main culprit here.


1) Why SmartLock unlock failed?

It all seemingly started (from ui.log) here:
[1255:1255:0713/125055.701994:ERROR:login_screen_controller.cc(86)] Authentication stage is 0
[1255:1255:0713/125055.708643:ERROR:views_screen_locker.cc(118)] Not implemented reached in virtual void chromeos::ViewsScreenLocker::SetPasswordInputEnabled(bool)
[1255:1255:0713/125055.720355:ERROR:views_screen_locker.cc(135)] Not implemented reached in virtual void chromeos::ViewsScreenLocker::AnimateAuthenticationSuccess()
[1255:1255:0713/125056.549080:ERROR:login_screen_controller.cc(287)] Not implemented reached in virtual void ash::LoginScreenController::ClearErrors()
[1255:1255:0713/125124.639222:ERROR:host_verifier_impl.cc(59)] Not implemented reached in virtual bool chromeos::multidevice_setup::HostVerifierImpl::IsHostVerified()
[1255:1255:0713/125152.995311:ERROR:login_screen_controller.cc(86)] Authentication stage is 0
[1255:1255:0713/125152.999606:ERROR:views_screen_locker.cc(118)] Not implemented reached in virtual void chromeos::ViewsScreenLocker::SetPasswordInputEnabled(bool)
[1255:1255:0713/125153.007884:ERROR:views_screen_locker.cc(135)] Not implemented reached in virtual void chromeos::ViewsScreenLocker::AnimateAuthenticationSuccess()
[1255:1255:0713/125153.872532:ERROR:login_screen_controller.cc(287)] Not implemented reached in virtual void ash::LoginScreenController::ClearErrors()
[1255:1255:0713/125203.551248:ERROR:host_verifier_impl.cc(59)] Not implemented reached in virtual bool chromeos::multidevice_setup::HostVerifierImpl::IsHostVerified()
[1255:1255:0713/125203.556998:ERROR:easy_unlock_create_keys_operation.cc(161)] Unable to wrap RSA key
[1255:1255:0713/125203.557033:ERROR:easy_unlock_create_keys_operation.cc(296)] Easy unlock failed to create challenge for key creation.
[1255:1255:0713/125204.685646:ERROR:host_verifier_impl.cc(59)] Not implemented reached in virtual bool chromeos::multidevice_setup::HostVerifierImpl::IsHostVerified()
[1255:1255:0713/125204.687758:ERROR:easy_unlock_create_keys_operation.cc(161)] Unable to wrap RSA key
[1255:1255:0713/125204.687791:ERROR:easy_unlock_create_keys_operation.cc(296)] Easy unlock failed to create challenge for key creation.

with no errors in system log.

Eventually, here the screenshot was taken, was it the point when the error report was filed? or help articles were searched?
2018-07-13T12:54:31.306419-04:00 ERR chrome[1255]: [1255:1255:0713/125431.306330:INFO:chrome_screenshot_grabber.cc(544)] Screenshot taken

Somewhere around this point we also have:
[1255:1255:0713/125423.294252:ERROR:answer_card_web_contents.cc(121)] Failed to parse response headers: SearchAnswer-HasResult header != true


2) Why insert PIN keyset was invoked? I don't see anything in ui.log, but we have insert LECredential. Possibly, that the point when SmartUnlock was disabled and then re-enabled? Is that supposed to happen?

2018-07-13T13:06:03.689128-04:00 ERR cryptohomed[1885]: Failed to read keyset file for user c3448e7172bdfde817acdc78d215853f2b76ec10
2018-07-13T13:06:03.832564-04:00 INFO cryptohomed[1885]: Pinweaver GetLog: 65537
2018-07-13T13:06:03.832621-04:00 ERR cryptohomed[1885]: Pinweaver error on pinweaver GetLog operation: 65537
2018-07-13T13:06:03.832654-04:00 ERR cryptohomed[1885]: InsertLECredential failed: hash tree error.

After that more SmartUnlock attempts. Still unsuccessful.
[1255:1255:0713/130622.395033:ERROR:login_screen_controller.cc(86)] Authentication stage is 0
[1255:1255:0713/130622.398666:ERROR:views_screen_locker.cc(118)] Not implemented reached in virtual void chromeos::ViewsScreenLocker::SetPasswordInputEnabled(bool)
[1255:1255:0713/130623.272906:ERROR:extended_authenticator_impl.cc(291)] Supervised user cryptohome error, code: 2
[1255:1255:0713/130623.272995:ERROR:views_screen_locker.cc(118)] Not implemented reached in virtual void chromeos::ViewsScreenLocker::SetPasswordInputEnabled(bool)
[1255:1255:0713/130623.273058:ERROR:login_screen_controller.cc(283)] Not implemented reached in virtual void ash::LoginScreenController::ShowErrorMessage(int32_t, const std::string &, const std::string &, int32_t)
[1255:1255:0713/130626.336352:ERROR:login_screen_controller.cc(86)] Authentication stage is 0
[1255:1255:0713/130626.339802:ERROR:views_screen_locker.cc(118)] Not implemented reached in virtual void chromeos::ViewsScreenLocker::SetPasswordInputEnabled(bool)
[1255:1255:0713/130626.345674:ERROR:views_screen_locker.cc(135)] Not implemented reached in virtual void chromeos::ViewsScreenLocker::AnimateAuthenticationSuccess()
[1255:1255:0713/130626.351833:ERROR:easy_unlock_create_keys_operation.cc(161)] Unable to wrap RSA key
[1255:1255:0713/130626.351920:ERROR:easy_unlock_create_keys_operation.cc(296)] Easy unlock failed to create challenge for key creation.
[1255:1255:0713/130627.127356:ERROR:login_screen_controller.cc(287)] Not implemented reached in virtual void ash::LoginScreenController::ClearErrors()


3) And finally: Why PinWeaver GetLog failed. That probably deserves to be split into a separate bug. Allen, can you please do that?

And for this one, jdufault@ should probably take a look first for (1) and (2) from UI point of view.

RE: #18

Can pinweaver flash be written if pinweaver_init()_ hasn't been called?

These seem like cryptohome bugs to me; UI should not able to corrupt state like this, ie, UI-side is unfamiliar with keyset.

Fundamentally for PIN all UI side does is this:
- get cryptohome supported policies
- if low entropy credentials are supported, after a login check if the user has prefs-based PIN; if so migrate by issuing an AddKeyEx call
- pin can be removed via RemoveKey
- login is done via MountEx
- unlock is done via CheckKeyEx

The not implemented errors above are working as intended.

I'm not familiar enough with easy unlock to say why key unwrapping would fail; +tbarzic@ who may know.

+few people that were working on smart lock related code recently

Its been a while I touched this code, so I'll need to refresh my memory a little.

There is some possibility the smartlock issues are being caused by: https://bugs.chromium.org/p/chromium/issues/detail?id=781882

+few more Smart Lock stakeholders.

I'm actively looking into this breakage. I initially suspect that this is a cryptohome issue, as jdufault@ mentioned. Nothing has changed recently with how Smart Lock behaves with key unwrapping.

re: #26, it's also unlikely that this is related to Bluetooth issues.

Apologies if this isn't helpful at all. I was running developer channel 69.0.3486.0 and experienced both SmartLock and Pins broken on eve.

Today I moved same device to Canary and successfully was able to login multiple times with both SmartLock and Pin on Version 69.0.3491.0 (Official Build) canary (64-bit)

Issue appears resolved to me.

There were several SmartLock related commits in the change log https://chromium.googlesource.com/chromium/src/+log/69.0.3486.0..69.0.3491.0?pretty=fuller&n=10000

Echoing #28, I cannot reproduce this issue on head. Smart Lock works as expected. 

Was there a firmware update across those two builds (69.0.3486 ---> 69.0.3491) ?

RE: #c30
There was a firmware update on eve in the previous version for me:

 -       OS Release : Linux 4.4.138-14447-g7e90a0e25e5e
 -       Kernel Rel.: 4.4.138-14447-g7e90a0e25e5e
 -       CROS Root  : ROOT-B (/dev/mmcblk0p5)
 -       OS Vers.   : 10820.0.0
 -       Browser Ver: Google Chrome 69.0.3473.0
 -       ARC Vers.  : 4861648
 -       CrOS FWID  : Google_Eve.9584.151.0

 +       OS Release : Linux 4.4.139-14472-g6853af561948
 +       Kernel Rel.: 4.4.139-14472-g6853af561948
 +       CROS Root  : ROOT-A (/dev/mmcblk0p3)
 +       OS Vers.   : 10866.1.0
 +       Browser Ver: Google Chrome 69.0.3486.0
 +       ARC Vers.  : 4884711
 +       CrOS FWID  : Google_Eve.9584.160.0    

I'm fairly convinced at this point that this issue no longer exists. Has anyone observed this issue either today or yesterday, either on ToT or canary? If not, this should be closed.

@32 - It is still an issue for me (on Dev)

To follow up on #28, has been working as expected on Canary for 3 days/releases. Currently running version 69.0.3494.0 and no issues.

I cannot confirm comment 34.

SmartLock has not been working as expected for me on at least the past few canary releases.
I thought it was odd, so I tried disabling and re-enabling the SmartLock feature.  The PixelBook can't find my phone, or, for that matter even pair properly via Bluetooth.  It will connect briefly, then disconnect.

The end result is my PixelBook still cannot find my phone at all (Pixel 2 XL).
I'm running Android 9 PPP4.180612.004 on the phone but SmartLock was working fine in the beginning of July when DP4 was released.  

I have no reason to think it's the phone and DP4, Bluetooth is working fine with all of my other paired devices, including the audio gear in my car.

Version 69.0.3494.0 (Official Build) canary (64-bit)

Don't mean to pile on but with the latest dev update on Eve today both smartlock & the pin code are working again. And Bluetooth too so I am quite happy.

Google Chrome	69.0.3494.0 (Official Build) dev (64-bit)
Revision	e91414c45bcdc6397f1a38faa0c826fbc47cd772-refs/branch-heads/3494@{#1}
Platform	10888.0.0 (Official Build) dev-channel eve
Firmware Version	Google_Eve.9584.160.0

Thanx much.

I am not seeing that update on my unit yet
Version 69.0.3486.0 (Official Build) dev (64-bit)

Comments 36 and 37, it appears that we are talking apples and oranges as you both seem to be on the dev channel I'm on canary. 

I can confirm it is now working in Version 69.0.3494.0 (Official Build) dev (64-bit)

My pixelbook just got the update about an hour ago. I did not need to remove/re-add my phone for it to start working again. 

Hi bryan.liesner@,

First off, thank you for taking the time to give us feedback.

Smart Lock does not use conventional classic Bluetooth pairing, so unpairing/pairing will not help in this situation. However, because you're having Bluetooth pairing issues, I suspect that you're actually hitting known intermittent Bluetooth issues, not this particular bug. 

Would you mind trying to set your phone up again after a) toggling Bluetooth on and off on the Chromebook, and b) rebooting the Chromebook?

If neither of those allow the Smart Lock setup to work, would you mind completing the following steps?
1) Go through the Smart Lock setup flow until it fails and asks you to retry (this is accessed by Settings > Screen Lock > Smart Lock for anyone following along).
2) Navigate to chrome://proximity-auth.
3) Click the "Save Logs" button on the top right. This will download debug logs.
4) Please attach those logs in a reply to this bug.

Again, thank you for your feedback!

Mr. Hansbury, I'll give your suggestion a shot. Thanks. 

Mr. Hansberry, I'll give your suggestion a shot. 
Thanks. I'm a little tied up today, but I'll try to get it in ASAP. It's not quite as critical an issue as no wifi for a few days. 

In reply to comment #43, I tried your suggestion on toggling Bluetooth on/off and still no dice.  Attached are the logs you requested.

Deleted: proximity_auth_logs_2018-07-20T23_13_50.677Z.txt 113 KB

proximity_auth_logs_2018-07-20T23_13_50.677Z.txt 113 KB View Download

I would like to add something related to comment 48. I was able to pair to my Samsung soundbar from my PixelBook. Played a YouTube video with the sound coming from the remote speaker system, no apparent issues.  The video was about fifteen minutes long, no disconnect.  

I believe I mentioned before that the Pixel 2 XL is on Android 9 DP4. No Bluetooth issues with it so far.  It's connected to my car, phone, audio, and contacts dump all work fine. My beloved Yamaha SRT-1000 works great too. (Off topic, but Yamaha rocks.) Out of sheer curiosity, I also paired it with my FreeBSD box and was able to transfer a photo from my phone via OBEX as well. The phone might be the culprit, but unlikely, it's behaving perfectly with several other devices.

Fixed in the most recent Chrome OS Dev update for me too (ASUS C302).

I'm happy for you archon, but again apples and oranges. I'm on canary you're on dev. Two completely different channels. I have a Pixelbook you have an Asus. 

More logs for Mr. Hansberry
Version 70.0.3498.0 (Official Build) canary (64-bit)

Deleted: proximity_auth_logs_2018-07-21T18_12_53.592Z.txt 166 KB

proximity_auth_logs_2018-07-21T18_12_53.592Z.txt 166 KB View Download

Thank you for the logs bryan.liesner@! We really do appreciate your help.

Your logs definitely confirm that you're hitting intermittent Bluetooth issues. Those Bluetooth bugs are orthogonal to this bug, and are already known to the Bluetooth team. They're tricky bugs, and the team is hard at work trying to resolve them.

Thank you for the background on your phone -- that's helpful, and further confirms my suspicion. The primary known source of Bluetooth issues so far is on the Chromebook, not phone.

Can you please confirm that when you attempt to use Smart Lock, even though it does not work, that the spinning icon still appears? Additionally, can you confirm that Pin entry is not broken for you? I'd like to ensure that the bug at hand is no longer affecting you -- then we can focus on what seems to be the actual issue for you, Bluetooth.

Finally, I realized I misspoke in comment #43 -- instead of simply rebooting the Chromebook, try to completely *power off* the device, wait several seconds, and turn the device back on, to completely reset Bluetooth. Let me know if that seems to help the issue.

Thanks!

Huh.  That all I can say. When it initially broke, I turned off Smart Lock and wasn't able to set it back up.  Just the retry trying to find the phone. 

Maybe it was opportunistic timing, maybe it was hard work on the Bluetooth team's part.  I was able to set up Smart Lock this evening, the Pixelbook found my phone.  I set the phone as discoverable, as I did before. I don't know if setting the phone as discoverable is just voodoo magic, or a requirement.  This was in PIN or Password mode tonight.  I did try both Password only and PIN or Password and always got the retry dialog setting up Smart Lock prior to this evening.  

After rebooting the Pixelbook, I could see the moving ring around the lock icon, but it gave up saying it could not find my phone. A step in the right direction, Smart Lock is once again enabled! 

I can enter a PIN and unlock.  I don't like PIN, I have screen smudge OCD.  :) 

I know from experience that there's nothing like a cold boot, I always do that.

If you need more info, I'm happy to give it up.
I'll be starting a new job tomorrow, then going directly to Aikido summer camp for a long weekend.
I'll  be back on Monday.

I can confirm that Smart Lock works On the following build:
Version 70.0.3502.0 (Official Build) canary (64-bit)

I can also pair the phone and the PixelBook, the pairing dialog "stays" until you can confirm.

Has this issue been observed in the past few days? I'd like to close it if not.

On comment #56:
The issue seems resolved on my end, thanks.

I would also say it has been resolved on my end

This issue seems to have been resolved. Closing now, but feel free to reopen if it pops up again.