Hi pbathini@ - do you have a bug report from the phone side?

I see a continuing pattern of these logs:
15:10:33.001
secure_channel.cc:269
Sending message to 45:7F:14:1A:4C:20: {feature: "magic_tether", payload: "{"data":"","type":1}"}
15:10:33.016
bluetooth_low_energy_weave_client_connection.cc:656
Writing 179 bytes to {id: "CAESR...lTS8=", addr: "45:7F:14:1A:4C:20"}.
15:10:33.785
secure_channel.cc:291
Received message from 45:7F:14:1A:4C:20: {feature: "easy_unlock", payload: "{"type":"status_update","user_presence":"present","secure_screen_lock":"enabled","trust_agent":"disabled"}"}

This indicates that the Chromebook is sending an Instant Tethering request to the phone, but the phone is responding instead with a Smart Lock message. Thus, the Chromebook can't determine if the phone is nearby. This seems like an issue on the phone side.

PFA the bug report from the pixel phone

Deleted: bugreport-sailfish-OC-MR1-2018-12-21-15-33-30.zip 7.2 MB

bugreport-sailfish-OC-MR1-2018-12-21-15-33-30.zip 7.2 MB Download

Hey Pramod, are you still stuck in this state now?

I just took a look at the logs and it seems like Magic Tether on the phone side did not register the Bob device (ID CAESR...9MHk=) to listen for connections, while easyunlock did. It looks like this account has >50 devices associated with it in cryptauth, so I think what's happening may be that the list got truncated. Toggling on and off bluetooth or rebooting the phone should probably get you out of this state. However, it's definitely strange to me that Magic Tether and EasyUnlock would have different devices that they get from ProximityAuth during registration.

Looping themaxli@ in here. It does seem like the current state in production is that MagicTether is still reading devices from Authzen while easyunlock reads from ProximityAuth directly. This could explain the (temporary) discrepancy right after a sync. In this case, it's good that ProximityAuth is the data source showing the correct behavior, since that's what we're trying to move all use cases over to :-).

This issue has an owner, a component and a priority, but is still listed as untriaged or unconfirmed. By definition, this bug is triaged. Changing status to "assigned". Please reach out to me if you disagree with how I've done this.