kevincar/bless

GATT Server name no longer advertising correctly

Avstn1 opened this issue · 7 comments

Avstn1 commented

The problem
After updating to macOS Monterey 12.3.1 with an iPhone running iOS 15.4.2, the specified GATT Server name is no longer advertising and I'm given a default name of "Mac" whenever starting the Bless server. I've confirmed that it's advertising my data, it's just that the name is incorrect.

Reproduction

my_service_name = "server-test"
server = BlessServer(name=my_service_name, loop=loop)

Expected behavior
The server would advertise as "server-test".

Screenshots
Screen Shot 2022-04-21 at 4 10 02 PM

Desktop (please complete the following information):

  • OS: macOS Monterey 12.3.1
Crudough commented

@kevincar I am also seeing this after updating to Monterey. @Avstn1 have you been able to find any solution?

Thanks!

kevincar commented

Thanks @Crudough and @Avstn1, I'll try to take a look this weekend. Pull requests are certainly welcome if a solution is found in the interim.

  • 👍1
Crudough commented

I'l continue investigating as well -- thanks @kevincar appreciate the response!

kevincar commented

This seems to be an issue with the pyobjc library. Just submitted an issue there. Will continue to tease apart the issue.

I'll see if I can supply a temporary workaround that will need to rely on compiled code.

kevincar commented

@Crudough, @Avstn1

Can you confirm that you were seeing the local device name prior to Monterey? The backend of bless utilizes the CoreBluetooth framework which has a limit on the amount of data that is advertised. Since bless, advertises the primary service UUID by default, it may limit the size of the local name field.

I'm assuming this wasn't a problem in the past given that you've created this issue but want to see if you can still see the local name if you shorten it to a name with < 10 bytes in length.

kevincar commented

Tested this issue again using Objective-C and found that MacOS Mojave allows long local names to be advertised, but no longer in Monterey. This behavior seems to be a result of how apple has coded the CoreBluetooth framework.

I've currently implemented a "work around" in which service UUIDs are dropped from the advertisement when the local name is longer than 10 bytes.

If there are other possible implementations to be suggested, please reopen this issue with those suggestions, ideas, or references.

Crudough commented

@kevincar thank you for getting back to this. I can confirm that the local name I was using was never more than 10-bytes. I will check the workaround that you implemented but have also just changed some other tooling to expect the default name that is being advertised.

Thank you again!

  • 👍1