bluetooth: Add flag to force device name to appear in AD data

[nordicjm]

This adds a new flag, BT_LE_ADV_OPT_FORCE_NAME_IN_AD, which can be used to
force the Bluetooth GAP device name to appear in the advertising data rather
than the scan response data of an advert with scan response data.

Signed-off-by: Jamie McCrae jamie.mccrae@lairdconnect.com

I looked into adding a test but it seems the only way to do that is using babblesim which isn't supported on windows so I'm open to suggestions on how to create such a test and actually test it.

[jhedberg]

I guess this is alright, although I'm not sure why requiring users to manually do this if they need to have it in the ad is so bad (since that would encourage them to use the scan response data, which is the recommended option).

[Thalley]

@lairdjm What is the use case for this?

Sounds like the only reason to do this, is that you want to advertise while keeping scan data exclusively for something else, otherwise you could just disable scanable to achieve the same result.

[nordicjm]

Users should be given the option. The need for this comes from a bad piece of code in an old design that scans for a device with a particular name instead of doing the correct thing and searching for the services it's advertising, but it's too late to fix that software now. You cannot disable being scannable and remaining connectable because of this code in subsys/bluetooth/host/adv.c:

	if (param->options & BT_LE_ADV_OPT_CONNECTABLE) {
		scannable = true;

The device that does the scanning does a passive scan, not an active scan, so there is no scan response data to view.

[Thalley]

Users should be given the option. The need for this comes from a bad piece of code in an old design that scans for a device with a particular name instead of doing the correct thing and searching for the services it's advertising, but it's too late to fix that software now. You cannot disable being scannable and remaining connectable because of this code in subsys/bluetooth/host/adv.c:

	if (param->options & BT_LE_ADV_OPT_CONNECTABLE) {
		scannable = true;

The device that does the scanning does a passive scan, not an active scan, so there is no scan response data to view.

Hmm, right, for legacy advertising that's not possible. Good point. And I suppose that the old design also doesn't do scan requests for the name, but only looks for the advertising data?

[Thalley]

If what @jhedberg says that this is not the recommended way of doing it, I think it's worth mentioning here.

[nordicjm]

I wouldn't say it's not the recommended way of doing it, it's very much down to the application. If you've got a single service and want to advertise that with the device name and it all fits into the advertising data, it should go there, it doesn't actually make any sense in that scenario to put it in the scan response nor does it make any sense to have any scan response data at all as all that would do is waste battery life if it's a sensor. However, if you're advertising multiple 128-bit UUID services then that will use a lot of advert space and it would be more important to see what services were being advertised rather than the device name.

[joerchan]

We have have had this discussion a few times already, and the last agreement was to document how the application can do this themselves instead.
It is documented below.

Last issue here: #27692 (comment)

@jhedberg @Thalley Do we wish to revert this decision then, it keeps getting requested so makes sense to listen to it.

But then I think we should remove the below statement again.

[Thalley]

It's a very good question. If it indeed does get keep requested, that's a good indication that the API can be improved (e.g. by the result of this PR).

I am a bit reluctant to add this, as it is already fairly easy for the application. We even have:

	 *  The application can set the device name itself by including the
	 *  following in the advertising data.
	 *  @code
	 *  BT_DATA(BT_DATA_NAME_COMPLETE, name, strlen(name))
	 *  @endcode

In the documentation for BT_LE_ADV_OPT_USE_NAME (which I also originally missed), which is even being used in the beacon and peripheral_ots samples. Maybe there's a way we can make that even clearer somehow?

@lairdjm Given this, are you still in favor of adding this option from your PR?

[nordicjm]

I am in favor of having my PR accepted, I prefer the option so that it can be supplied like this.

[joerchan]

I looked into adding a test but it seems the only way to do that is using babblesim which isn't supported on windows so I'm open to suggestions on how to create such a test and actually test it.

@lairdjm Simplest would be to update the shell and do a simple test there subsys/bluetooth/shell/bt.c, you can use tests/bluetooth/shell for this. But let's first decide if this is an enhancement that we want. We have discussed this before and not added this then. The application can do this itself, and the OPT_USE_NAME is simply just for convenience sake.

Awaiting future response from Joakim

[joerchan]

Awaiting future response from Joakim

I'm OK with adding it, but I would like @jhedberg to agree since he was against this change previously.

[Thalley]

Awaiting future response from Joakim

I'm OK with adding it, but I would like @jhedberg to agree since he was against this change previously.

I guess he was just reluctant, like me, of adding an option bit that doesn't add any functionality, but rather add a new way of doing the same as was possible before. However, the option bit to set the name in the scan data can isn't any different, so I guess this is just as good as the name option bit :)

[jhedberg]

I'm OK with adding it, but I would like @jhedberg to agree since he was against this change previously.

I guess he was just reluctant, like me, of adding an option bit that doesn't add any functionality, but rather add a new way of doing the same as was possible before.

That would indeed be an accurate assessment of how I feel about this :)

IIRC we added the original flag so that the stack could auto-manage and update the advertised name in case the GAP name characteristic is writable. However I see what we could have avoided quite a bit of complexity if we had just left this up to the application to sort out and do manually.