Feature request: expose peer address from ECMA-419 GATTServerConnection

[stc1988]

I'm trying to porting the Apple Media Service (AMS) client flow from the legacy BLE API to the ECMA-419 BLE APIs:

The legacy AMS implementation uses this flow:

class AMSAuthenticator extends BLEServer {
	onConnected(device) {
		this.device = device;
		this.stopAdvertising();
	}

	onAuthenticated() {
		this.client.onAuthenticated(this.device);
	}
}

class AMSClient extends BLEClient {
	constructor(device) {
		super();
		this.device = device;
	}

	onSecurityParameters() {
		this.connect(this.device);
	}
}

In other words, the accessory advertises the AMS solicitation UUID, iOS connects to the accessory, and after authentication the client side connects to the same peer device to discover the AMS service.

With the ECMA-419 APIs, GATTServer.onConnect(connection) receives a GATTServerConnection, but it does not appear to expose the peer address. GATTClient, however, requires an address option:

new GATTClient({ address, ... })

This makes it difficult to reproduce the legacy AMS flow, because the peripheral-side connection cannot be used to identify the peer for the central-side GATTClient.

Could GATTServerConnection expose the connected peer address, for example:

connection.address

[phoddie]

Nice to see that you are working on migrating that to ECMA-419. I forgot how complicated AMS is.//

What you describe sounds analogous to the remoteAddress property of the TCP socket. Here is would be a property of a GATT Server Connection. That sounds reasonable. BLE stacks are inconsistent about the information they provide, so maybe some stacks won't provide this, in which case the value would be undefined.

Does that accurately capture what you have in mind?

[stc1988]

Nice to see that you are working on migrating that to ECMA-419.

BLE HID devices such as keyboards are already working.

Does that accurately capture what you have in mind?

Yes, that matches my understanding.

[phoddie]

There are two different addresses associated with the connection provided by NimBLE. I believe the one we want here is the peer_id. I did a quick implementation. Maybe you can try it to see if it works for you with AMS?

In $MODDABLE/modules/io/ble/server/esp32/bleserver.js add this line to the GATTServerConnection:

	get remoteAddress() {return native("xs_gattserverconnection_get_remoteAddress") }

Then add this function to the corresponding bleserver.c:

void xs_gattserverconnection_get_remoteAddress(xsMachine *the)
{
	BLEGATTServerConnection connection = xsmcGetHostDataValidate(xsThis, xs_gattserverconnection_destructor);

	struct ble_gap_conn_desc desc;
	if (0 != ble_gap_conn_find(connection->conn_handle, &desc))
		return;

	char address[24];
	snprintf(address, sizeof(address), "%02X:%02X:%02X:%02X:%02X:%02X/%02X",
         desc.peer_id_addr.val[5], desc.peer_id_addr.val[4], desc.peer_id_addr.val[3],
         desc.peer_id_addr.val[2], desc.peer_id_addr.val[1], desc.peer_id_addr.val[0],
         desc.peer_id_addr.type);
	xsmcSetString(xsResult, address);
}

[stc1988]

Since I was troubleshooting step by step, I hadn’t implemented the full AMS functionality yet, but I confirmed that the GattClient can connect to iOS using remoteAddress.

By the way, I modified remoteAddress as follows:

get remoteAddress() { return native("xs_gattserverconnection_get_remoteAddress").call(this); }

[phoddie]

Since I was troubleshooting step by step, I hadn’t implemented the full AMS functionality yet, but I confirmed that the GattClient can connect to iOS using remoteAddress.

That was quick! Thank for confirming that. I'll get that committed and put it on the agenda for the next TC53 teleconference .

By the way, I modified remoteAddress as follows:

Oops. Thank you.