Re: [Bluez-users] hci_read_remote_name() simultaneously on multiple dongles question

[Marcel Holtmann <marcel@holtmann.org>]

Hi Jeffrey,

> I apologize for yet another e-mail about this, but as the last one was
> too wordy I have narrowed down the problem to a much simpler issue.
> 
> As my changes to hci.c didn't do anything towards resolving the name
> mixup, I was wondering how the hci_read_remote_name() ensures that the
> packet that comes in isn't a packet response to another
> hci_read_remote_name() request.  It seems that everytime that I do
> multiple hci_read_remote_name() requests at the same time, that the
> name request replies indiscriminately choose whichever dongle to
> enter, and at the hci.c level, there is no way to verify the btaddr
> that that name request came from, which is rather frustrating.
> 
> As some background for what "fixes" that I tried to do to hci.c were,
> I simply compared the bdaddr const variable with rn.bdaddr near the
> end of hci_read_remote_name_with_clock_offset() to see if it didn't
> match, and to reject it if so and return -1, and to allow the name to
> be copied to the name pointer otherwise.
> 
> If anyone out there has experienced similar problems with multiple
> dongles and hci_read_remote_name(), any help would be appreciated if
> any solutions to this have been found. 

feel free to post a patch, but honestly this is broken for quite some
time now. The kernel and the new D-Bus based API have no problems with
it and that should be the main way to retrieve remote names. So I am not
really keen to fix this since direct HCI access for userspace apps was a
design mistake.

Regards

Marcel



-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users