Hi everybody,
I sent this post several days ago and I haven't received any response so
far. I think I didn't explain
it clearly so in this new message I'll try to do my best to explain
again the problem.
I have attached a simple drawing explaining the idea. The proposed
system consists of a mini PC with several
Bluetooth dongles (D1...DN). Dongle number 1 is exclusively dedicated to
detect nearby mobile devices by means
of SDAP. Once some devices have been detected, the system carries some
Bluetooth operations over them. For that, the system dispatches these
operations
making use of dongles (D2..DN). Note that some operations require the
pairing between the device and the system. What I want to achieve is
that
each device is *paired exactly once* against the system despite the
dongle D2-DN that finally treats the operation.
The solution I thought of was using bdaddr tool for assigning the same
MAC address to all D2 ... DN dongles, in that way that every one uses
the same
linkeys to save paired devices. The problem I have with this approach
(I checked I with hcidump tool) is that if every dongle has the same MAC
address, all operations finally make over the same dongle (D2). So if I
don't missing the point, Bluez internally uses MAC address instead of
HCI in order to
select the dongle. In that case, ¿would be feasible to modify Bluez to
take this into account?
Sorry for my insistence but I need to make a decision on this ASAP.
Thank you very much for your help,
Regards,
Germán.
El mar, 17-11-2009 a las 11:31 +0100, German Pedrosa Loureiro escribió:
>
> Hi guys,
>
> I am involved in the developing of a Java project that uses Bluecove
> and Bluez. This project makes use of several Bluetooth dongles, one of
> them is dedicated to the task of scanning and the rest of them are
> focused on carrying other Bluetooth operations over mobile devices.
>
> Some of these operations need the pairing between the mobile device
> and the dongle that executes the operation. One of the project
> objectives is to avoid that the same user has to pair more than once
> against the system. In order to tackle with this issue, I thought of
> assigning the same MAC address to every dongle by means of "bdaddr"
> tool, so as to when the user pairs with a dongle he automatically
> pairs with all of them. Once I have implemented this I have jumped
> into a problem: At the end all the operations physically executes over
> the same dongle. My questions are, ¿Does Bluez use MAC address instead
> of HCI in order to select the dongle? If so, ¿would be feasible to
> modify Bluez to take this into account?
>
> Any thoughts on this would be very appreciated,
>
> Best wishes,
>
> Germán.
>
>
On Wed, 25 Nov 2009, Germa Pedrosa wrote:
I apologise this was a while ago I didn't have anything to say at the time
but it came back to me while I was thinking about something else..
> What I want to achieve is that each device is *paired exactly once*
> against the system despite the dongle D2-DN that finally treats the
> operation.
I think you will get trouble with this approach. As you have found,
pairing is between two dongles and depends on the bdaddr at each end.
> The solution I thought of was using bdaddr tool for assigning the same
> MAC address to all D2 ... DN dongles, in that way that every one uses
> the same linkeys to save paired devices.
Perhaps it will work and perhaps not but I think there will be long term
problems in overlapping areas of coverage using devices with the same
bdaddr. The frequency hopping in the piconet depends also on the master
device clock so at least the devices are likely to be out of sync but
collisions may occur causing intermittent problems, I don't really know.
I think you would probably be better to have the security aspect on a
separate level. ie, you create a token that the higher level stack can
present to authenticate itself upon connecting to the service, leaving the
baseband connection to be unauthenticated.
for example, the OBEX specification contains a means for a device to
authenticate (this is designed so that just plugging in a cable is not
enough to access contents on a device) though I don't think that openobex
supports this so none of the open source OBEX applications would handle
it. Also, higher layer authentication is discussed in the PAN profile
document, like running a VPN over an open wireless point.
regards,
iain