On Wed, 2009-07-29 at 02:08 +0100, Zhao, Forrest wrote:
Ohly, Patrick wrote:
> On Tue, 2009-07-28 at 10:31 +0100, Zhao, Forrest wrote:
> No, not quite. I'm looking for whatever corresponds to the IP address
> in a TCP connect(), or at a lower level the MAC. In case that it
> makes a difference, this is from a user space perspective, not inside
> the kernel.
This is done by rfcomm_connect() in obexd. The declaration is
static int rfcomm_connect(const bdaddr_t *src, const bdaddr_t *dst, uint8_t channel,
GIOFunc function, gpointer user_data);
src is source BT MAC address; dst is destination BT MAC address, channel is the service
channel (e.g. PBAP server channel is 15).
>
> So for initiating an OBEX connection, how do I find the available
> devices and choose one of them?
To find the available BT devices, please use command 'hcitool scan';
to find the services supported by a BT device, please use command
'sdptool browse BT-MAC-address'.
>
> If I was contacted via obexd and Bluetooth, can I find that device
> again when it reconnects via USB, without establishing a connection
> and exchanging some data?
Sorry, I have not experienced such case.
Marcel,
Could you help to answer this question?
What you described above looks very much Bluetooth specific. I fear that
the other transports will likely also have their own addressing scheme,
like USB bus number or device node.
The bottom line line of the discussion is that the information required
to re-establish an incoming connection is depending on the transport.
The same applies to connections originating from a server. My suggestion
is to keep this separate from the D-Bus API discussion and (as I said
earlier) not implement it immediately for OBEX.
I'll write down a D-Bus API proposal now...
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.