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.
Thanks!
--
-Jeff
Marcel,
I understand that you just pointed out that it was a design mistake to be
able to access HCI
functions directly (even I avoided it for a time assuming they were
'locked-out' due to my experience
with other API's, however, the only function that I use is
hci_read_remote_name_with_clock_offset.
so that I can use the clock offsets, and they seemed to lead to a
performance increase in the
reply-time of name replies. Thanks for the point-out though. If the other
method works fine then I see
no need to post a patch as what I'm doing is a little bit more custom than
the average usage as
we're using them as part of a research project.
Regarding the dbus-based API:
Are you referring to the hci_remote_name() function instead? Also, another
problem that I seem
to be encountering has nothing to do with the name resolution, but rather
that after a time the hcid
will start to accumulate CPU time. Looking at just the TIME and COMMAND
fields of a 'ps aux' call,
0:41 /usr/bin/dbus-daemon --system
2:26 /usr/sbin/hcid
I noticed that whenever my program had super-high CPU time in the
double-digits (e.g. 47:21), that
the hcid usually had high CPU time as well, and it seems the dbus-daemon's
CPU time accumulates
as well.
I was wondering what could cause this to happen? Sometimes the CPU time
accumulates so fast that after
barely 4 hours of use (we're using it as a 4-dongle scanner with 1 inquiring
and 3 name-querying dongles as
part of a research project at UCSD) the dongles stop doing anything
altogether and freeze, and the only way I
can get them to respond quickly again is to kill my program, and sometimes,
to restart hcid as well. In this case,
dbus-daemon also sometimes accumulates in CPU usage. The only thing that my
program does HCI-wise
is continuously inquire on 1 dongle (reset list flag set), continuously
name-query on each other dongle from a queue
filled by the results of the 1st (it resets the dongle if a
hci_read_remote_name_with_clock_offset() call fails).
Again thanks in advance, but any suggestions and/or recommendations
regarding this issue would be
much-appreciated
On 8/24/07, Marcel Holtmann <[email protected]> wrote:
>
>
> 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.
>
>
--
-Jeff
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users