Way, I've added a call to "SecureConnection" for when we see the ER_BUS_MESSAGE_DECRYPTION_FAILED. Tt seems to be doing better, considering that MESSAGE_DECRYPTION_FAILED always precedes the ER_BUS_KEY_UNAVAILABLE. I haven't had a lot of time to test though. I can let you know if I see this issue again.
Could you clarify what the call to "secureConnection" does differently from the automatic authentication that gets triggered as a result of a method call? Do you have a recommended approach for initiating authentication? Currently we create a proxy object and initiate a method call on the device. To attempt to answer your question about restarting the bus: It seems to me that this is a complex state that our application gets into after establishing communication with remote clients, then leaving and rejoining sessions after the sessions have become stale in a long-running scenario. As a result, restarting the application (thus the bus attachment) will not always yield the same results without going through the same steps in the same order. I can however confirm that the issue is intermittent. Let me know if you would like me to log a bug or anything else to track this. Thanks for your feedback, -Jeff From: Way Vadhanasin [mailto:[email protected]] Sent: Monday, July 25, 2016 1:39 PM To: Blayney, Jeff <[email protected]>; [email protected] Cc: Poole, Gary <[email protected]>; Cazier, Robb P (CEPS SW Development) <[email protected]>; Mozzetta, Jonathan <[email protected]>; Singh, Baljit ((PPS-ASG)) <[email protected]> Subject: RE: Auth Failures Galore Hi Jeff, When you get ER_BUS_KEY_UNAVAILABLE on the PC side, do things recover if you call SecureConnection(true) or re-create a new bus attachment? Thanks, Way From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Blayney, Jeff Sent: Friday, July 22, 2016 2:38 PM To: [email protected]<mailto:[email protected]> Cc: Poole, Gary <[email protected]<mailto:[email protected]>>; Cazier, Robb P (CEPS SW Development) <[email protected]<mailto:[email protected]>>; Mozzetta, Jonathan <[email protected]<mailto:[email protected]>>; Singh, Baljit ((PPS-ASG)) <[email protected]<mailto:[email protected]>> Subject: [Allseen-core] Auth Failures Galore Hey guys, I was hoping to get some input on an issue we're seeing with an ER_BUS_KEY_UNAVAILABLE security violation. First, let me give some background on our authentication approach. With all of the test cases we have for going offline, then connecting again, we frequently run into authentication issues that we have to catch and recover from. We've been able to detect and recover from such issues by responding to the securityViolationOccurred callback which tells us about various auth failures. Our approach for each violation below is: We make a method call on the endpoint we received the violation from to attempt to resolve any authentication issues: * ER_BUS_MESSAGE_DECRYPTION_FAILED - we often see this after devices reconnect, then one side can't receive a signal. This violation occurs. Making a method call back on the remote bus endpoint will usually resolve any issues. * ER_BUS_DESTINATION_NOT_AUTHENTICATED - Usually we run into this issue under the same circumstances as above. * ER_AUTH_FAIL - Who knows, this one is not very informative. * ER_BUS_NOT_AUTHORIZED - This one isn't very informative either, we did enable security on the bus, and we have authenticated interfaces and objects. So I ran into a new one today, and it is not recovering. The my interpretation of the logs + steps are below, along with our actual logs below that: 1. PC and iOS devices lose each other's sessions due to link timeout. 2. They both attempt to ping each other's bus names to see if the other is there. This fails although they are still both online. 3. I manually announce from the iOS client, to see if they can recover. The PC gets the announcement just fine, and joins session with the iOS device. 4. The iOS device joins session back with the PC. 5. At this point, both clients are coded up to call a remote method on the other in order to authenticate. 6. This is when the logs start filling up with ER_BUS_MESSAGE_DECRYPTION_FAILED on the PC side. This triggers the PC to queue up more method calls to iOS in order to fix authentication. 7. iOS receives two Authentication Successful callbacks for SRP_KEYX 8. PC receives ER_AUTH_FAIL, and ER_BUS_KEY_UNAVAILABLE and never recovers authentication. It is now in a broken state. Starting with receiving the MESSAGE_DECRYPTION_FAILED: 07-22-16 15:05:33 9544(6912) DEBUG - BusAttachmentFeatures::RequestCredentials - RequestCredentials called: AuthMechanism: ALLJOYN_SRP_KEYX, AuthPeer::kirj8z85.2, count: 1, userId: 07-22-16 15:05:33 9544(6912) DEBUG - BusAttachmentFeatures::RequestCredentials - Matched ALLJOYN_SRP_KEYX 07-22-16 15:05:33 9544(6912) DEBUG - BusAttachmentFeatures::RequestCredentials - RequestCredentials CredentialMask uses CRED_PASSWORD 07-22-16 15:05:33 9544(6912) DEBUG - BusAttachmentFeatures::RequestCredentials - RequestCredentials Done, sent 71F59CCE-E950-4BB9-9926-B21604FCFDF9 07-22-16 15:05:33 9544(12292) DEBUG - BusAttachmentFeatures::SecurityViolation - SecurityViolation: ER_BUS_MESSAGE_DECRYPTION_FAILED 07-22-16 15:05:33 9544(12292) DEBUG - BusAttachmentFeatures::SecurityViolation - Resyncing due to SecurityViolation: ER_BUS_MESSAGE_DECRYPTION_FAILED 07-22-16 15:05:33 9544(12292) DEBUG - BusObjectCanvas::doSyncAsync - Making a method call on the violating peer's bus 07-22-16 15:05:33 9544(12292) DEBUG - BusObjectCanvas::doSyncAsync - Increasing the sync thread count to: 3 07-22-16 15:05:33 9544(12292) DEBUG - BusObjectCanvas::doSyncAsync - Decreasing the sync thread count to: 2 07-22-16 15:05:33 9544(6912) DEBUG - BusAttachmentGlideBase::AuthenticationComplete - AuthenticationComplete: AuthMechanism: ALLJOYN_SRP_KEYX, AuthPeer: :kirj8z85.2, Success: 0 07-22-16 15:05:33 9544(4236) DEBUG - BusAttachmentFeatures::SecurityViolation - SecurityViolation: ER_AUTH_FAIL 07-22-16 15:05:33 9544(6912) DEBUG - BusAttachmentFeatures::SecurityViolation - SecurityViolation: ER_BUS_KEY_UNAVAILABLE Any ideas? In Retrospect: Our teams could not have pulled off authenticated communication without responding to the numerous securityViolation callbacks. We get these all the time in disconnect/reconnect scenarios, and it often results in failed authenticated signals between the clients, or communication that never recovers My recommendation would be to document these violations and how to remedy them on a per-violation basis. I can't imagine we're the first ones to have this much trouble with authentication. Thanks for any help! -Jeff
_______________________________________________ Allseen-core mailing list [email protected] https://lists.allseenalliance.org/mailman/listinfo/allseen-core
