Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Get Manufacturer Data from Scan Response #491

Closed
skuhtic opened this issue Dec 28, 2022 · 4 comments · Fixed by #506
Closed

Get Manufacturer Data from Scan Response #491

skuhtic opened this issue Dec 28, 2022 · 4 comments · Fixed by #506

Comments

@skuhtic
Copy link

skuhtic commented Dec 28, 2022

Great effort with this great library. I have device that have different Manufacturer Data (MD) in both advertised packet (passive scan) and scan response packet (active scan). Packet are traced with PC and there are different MD data in both packets, but can't trace if EPS32 gets scan response for active scan (it should).
It seems that calling getManufacturerData gives data from advertised packet even for active scan. I can't confirm that by looking at source code.
This is ok when data is not duplicated or have equal data in both packets, but as tested there is different/more useful data in scan response packet.

Is there a way to get data from scan response packet? Like forcing the scan response packet as source or to choose source packet?

@h2zero
Copy link
Owner

h2zero commented Dec 29, 2022

This is not yet possible with the current API. I'll look to add an index parameter to the function like is done with service data.

@skuhtic
Copy link
Author

skuhtic commented Jan 10, 2023

Adding an index parameter would be great for flexibility and cover all sorts of use cases.
In the meantime I did try standard BLE library and it returns MD from scan response packet in case of active scan. But that brings other quirks that makes this library preferred.

If compatibility is wanted it would be also good idea that shared API behaves the same. That would bring less logic issues when migrating libraries. Maybe adding flag in nimconfig.h is good idea if current behavior is needed for upgrade compatibility.

In this case it would even resolve the issue because not both MD are strictly needed. In this case MD from advertised packet could be discarded and functionality could be achieved only with MD from scan response.
Thanks for your effort.

@skuhtic
Copy link
Author

skuhtic commented Feb 6, 2023

Following the code, the easiest and quickest way to be compatible with the standard library would be to change m_payload.end() to m_payload.begin() in the line: https://github.com/h2zero/NimBLE-Arduino/blob/core-update/src/NimBLEAdvertisedDevice.cpp#L790

That way scan response would be parsed before advertising data and fields present in both payloads would prioritize the scan response. Currently, it's the other way around.

@h2zero
Copy link
Owner

h2zero commented Feb 20, 2023

@skuhtic I have created PR #506 to address this, for your use case you could call getManufacturerData(1); to get the data from the scan response instead. I have not tested this code yet so if you would like to try it and let me know if it works for you I would greatly appreciate the feedback.

@h2zero h2zero linked a pull request Mar 26, 2023 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants