We currently use sdp_connect and sdp_service_search_attr_req to
determine the RFCOMM channel associated with a service on a remote
device.
Does the D-Bus API provide an equivalent way to discover this information?
Thanks,
Mark
Hi Mark,
On Tue, Sep 29, 2015, Mark Spruiell wrote:
> Thanks for the reply.
No problem, but please don't top-post on this mailing list. Use in-line
quoting instead.
> I understand how a server can use RegisterProfile to advertise its
> UUID & RFCOMM channel with SDP (as demonstrated in test-profile).
>
> It's still not clear to me how a client can use D-Bus to establish an
> RFCOMM socket connection given a device address & UUID. Can you point
> me in the right direction?
The same interface can be used for both client and server role. Take a
look at the "Role" option for RegisterProfile (with test-profile you'd
pass -c to it). This basically tells bluetoothd that your application is
capable of supporting the client role of a certain profile.
To actually connect to the profile (which should cause a NewConnection
call to your application, giving it the socket) you'd use the usual
ConnectProfile or Connect methods on the Device1 interface (see
doc/device-api.txt, you can play with these e.g. using the "connect"
command in bluetoothctl (with no parameters it maps to Device1.Connect
and with one parameter (the UUID) to Device1.ConnectProfile).
The ConnectProfile call should always work, whereas for your profile to
be included in the set of profiles connected using Connnect you'd need
to set the AutoConnect option to true when registering your profile.
Johan
Hi Johan,
Thanks for the reply.
I understand how a server can use RegisterProfile to advertise its
UUID & RFCOMM channel with SDP (as demonstrated in test-profile).
It's still not clear to me how a client can use D-Bus to establish an
RFCOMM socket connection given a device address & UUID. Can you point
me in the right direction?
Regards,
Mark
On Mon, Sep 28, 2015 at 11:49 PM, Johan Hedberg <[email protected]> wrote:
> Hi Mark,
>
> On Mon, Sep 28, 2015, Mark Spruiell wrote:
>> We currently use sdp_connect and sdp_service_search_attr_req to
>> determine the RFCOMM channel associated with a service on a remote
>> device.
>>
>> Does the D-Bus API provide an equivalent way to discover this information?
>
> Not directly, but there's a more convenient & higher level API available
> if you look at doc/profile-api.txt and test/test-profile. This will not
> only look up the RFCOMM channel for you, but also go ahead and connect
> to the service and then give you back the connected RFCOMM socket over
> D-Bus.
>
> Johan
Hi Mark,
On Mon, Sep 28, 2015, Mark Spruiell wrote:
> We currently use sdp_connect and sdp_service_search_attr_req to
> determine the RFCOMM channel associated with a service on a remote
> device.
>
> Does the D-Bus API provide an equivalent way to discover this information?
Not directly, but there's a more convenient & higher level API available
if you look at doc/profile-api.txt and test/test-profile. This will not
only look up the RFCOMM channel for you, but also go ahead and connect
to the service and then give you back the connected RFCOMM socket over
D-Bus.
Johan
Hi,
On Tue, Sep 29, 2015 at 9:34 PM, Johan Hedberg <[email protected]> wrote:
> Hi Mark,
>
> On Tue, Sep 29, 2015, Mark Spruiell wrote:
>> Thanks for the reply.
>
> No problem, but please don't top-post on this mailing list. Use in-line
> quoting instead.
Got it.
>> I understand how a server can use RegisterProfile to advertise its
>> UUID & RFCOMM channel with SDP (as demonstrated in test-profile).
>>
>> It's still not clear to me how a client can use D-Bus to establish an
>> RFCOMM socket connection given a device address & UUID. Can you point
>> me in the right direction?
>
> The same interface can be used for both client and server role. Take a
> look at the "Role" option for RegisterProfile (with test-profile you'd
> pass -c to it). This basically tells bluetoothd that your application is
> capable of supporting the client role of a certain profile.
>
> To actually connect to the profile (which should cause a NewConnection
> call to your application, giving it the socket) you'd use the usual
> ConnectProfile or Connect methods on the Device1 interface (see
> doc/device-api.txt, you can play with these e.g. using the "connect"
> command in bluetoothctl (with no parameters it maps to Device1.Connect
> and with one parameter (the UUID) to Device1.ConnectProfile).
>
> The ConnectProfile call should always work, whereas for your profile to
> be included in the set of profiles connected using Connnect you'd need
> to set the AutoConnect option to true when registering your profile.
Thanks, that helped a lot.
On a related note, I noticed that a server can specify a value of 0
for its RFCOMM channel when calling RegisterProfile and bluetoothd
seems to select an available channel. Is there any way for the server
to discover which RFCOMM channel was selected, aside from waiting for
the first incoming connection?
Mark