nearby: iOS connection error when advertising
Project
Nearby Connections
Language
Swift
OS Platform
Apple
What happened?
When using an iOS device as an advertiser, the connection fails after being accepted (via code automatically or using the iOS Example provided in the repository) due to a parsing error in the secure message.
What did you expect to happen?
I expected the connection to be accepted. When using the iOS device as a discoverer, I do not encounter any problems when connecting to an Android device that is advertising.
How can we reproduce it (as minimally and precisely as possible)?
I have run multiple scenarios, all resulting in the same output:
Devices:
iPhone running iOS 16.5 iPad running iOS 16.5 Steps:
(using cluster/star strategy)
- Start advertising on the iPad.
- Start discovering on the iPhone.
- The connection request is automatically sent and accepted.
- An error occurs, preventing the message from being sent, and the connection is rejected by the advertiser’s side.
I have also tried other scenarios using the iOS device as an advertiser and tested the iOS Example provided in the repository. In all cases, the same error occurred. Occasionally, the connection was approved, but I was unable to determine the reason why.
How often does this bug happen?
Often
Standalone code to reproduce the issue
The error was able to be produce with the iOS example, let me know if you are not being able to reproduce it.
Relevant log output
<PATH>/SourcePackages/checkouts/nearby/third_party/protobuf/src/google/protobuf/message_lite.cc:134] Can't parse message of type "securemessage.SecureMessage" because it is missing required fields: (cannot determine missing fields for lite message)
[ERROR] VerifyDecryptPayload: error parsing SecureMessage.
[ERROR] DecodeMessageFromPeer: Failed to verify message.
Anything else we need to know?
- Using a star strategy with the android as a advertiser and iOS devices with discovery worked perfectly.
- When using breakpoints in the didReceiveConnectionRequestFrom and didReceive methods, with hardcoded values set to true, the connection process proceeds without any issues.
About this issue
- Original URL
- State: closed
- Created a year ago
- Reactions: 1
- Comments: 15
Commits related to this issue
- Fix `EXC_BAD_ACCESS` crash when calling payload delegate methods. Objective-C objects cannot be captured by reference in C++ lambdas and must always be captured by value. This also takes a copy of t... — committed to google/nearby by bourdakos1 a year ago
- Fix `EXC_BAD_ACCESS` crash when calling payload delegate methods. Objective-C objects cannot be captured by reference in C++ lambdas and must always be captured by value. This also takes a copy of t... — committed to google/nearby by bourdakos1 a year ago
- Fix `EXC_BAD_ACCESS` crash when calling payload delegate methods. Objective-C objects cannot be captured by reference in C++ lambdas and must always be captured by value. This also takes a copy of t... — committed to google/nearby by bourdakos1 a year ago
@bourdakos1 This is the code that im using, I also tried to use the code for the example enforcing the connection always to be accepted and failed. I also tried using the hash of the following commit and this did work. Im not sure if its something with a change in the library or something related to the direct accept
@bourdakos1 thanks a lot! This solves the issue
Yes looks like that fixes the issue thanks!
Do you mind trying #1703 and see if that resolves the issue?
@IgVelasco and @DonatoJP thanks for reporting! I am able to reproduce the issue and I’m looking into a fix
Hey!
I am also having problems related to this. But, in my case, it also happens when both devices are configured to follow a “Point to Point” strategy. It seems that it does not depend on the connection strategy selected.
Following the same scenario that @IgVelasco described above, I ALWAYS receive the “libprotobuf ERROR” on the advertiser’s side.
I can also see this, just behind the relevant log described above:
And, in terms of the UI from the example, the advertiser shows the buttons to “Send bytes”, but the discoverer device shows the “Accept/Reject” buttons in a disabled state.