Hi Johannes, --snip --snap > > We seem to have another problem here. Could you try to explain in more > > detail what goes wrong? > > 1. What do you expect to happen? > > 2. What happens? > > 1. I expect that when I register an Application as a client with GattProfile1 objects > and lists of services that bluetoothd accepts connections only form devices > providing this profiles/services. > That makes sense since otherwise data are sent but not handled by an application > and therefor the data get lost. > > 2. What happens is that as soon as I register my Application with an arbitrary > GattProfile1 all connections from paired devices are accepted. E.g. I registered a > Weight Scale service but also a connection from a blood pressure device gets > accepted even no service is registerted and no application is existing which is able > to handle this data. > > Does that make it more clear I think this might be the problem. Registering only affects the auto-connect behavior (according to code and doku). The BLE central role (your client) completely defines the BLE communication by issuing commands (connect, read characteristic, write characteristic, subscribe to notifications..). The only way for a peripheral to send data to a client without the central actively asking is via notifications. But also in this case a client would need to subscribe to the notifications first. Unhandled data is thus not an issue. Assuming an implementation following the blocking behavior you described/expected: This would lead to severe problems as soon as you have multiple applications talking to bluez and registering different profiles, wouldn't it? --> The RegisterProfile behavior is simply not what you expected it to be. Cheers, Markus -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
