[Bluez-devel] Remote name delay

[Bluez-devel] Remote name delay

[Claudio Takahasi]

Hi,

I am developing a standalone application to perform real D-Bus
services tests. The main features are:
1. Running all the time in the systray
2. Handle PIN Request
3. Local adapter configuration
4. Basic operations: Inquiry, Remote name, ...

However I am facing a problem in the RemoteName service when a lot of
inquiry replies is received. My app stores the inquired devices in a
hash table and when the InquiryCompleted signal is received the app
request the name for each device. The "hci_send_req" function is
returning an Input/Output error. Looking the hcidump result, the
"Command Disallowed" error is displayed :(

HCIDUMP:
> HCI Event: Command Status (0x0f) plen 4
    Remote Name Request (0x01|0x0019) status 0x0c ncmd 1
    Error: Command Disallowed
 <<<<<Indicates that the controller is in a state where it can process
this command at this time.>>>>

I noticed the same problem using the hcitool with "--flush" option and
removing the cached device information stored in the directory
"/var/lib/bluetooth".

Trying to fix this problem I did some changes in the hcid dbus
RemoteName using the clock offset and page scan repetition mode.
However I didn't reach significant improvements.
* InquiryResult signal Changes
   - Added clock offset
   - Added pscan_rep_mode
* RemoteName Changes
   - Added clock offset
   - Added pscan_rep_mode

I know that I can retrieve some entries from the file "names" in the
storage directory. But without consider this, how can I reduce the
remote name request time?

Regards,
Claudio
--
---------------------------------------------------------
Claudio Takahasi
Instituto Nokia de Tecnologia - INdT


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Remote name delay

[Marcel Holtmann]

Hi Claudio,

> I am developing a standalone application to perform real D-Bus
> services tests. The main features are:
> 1. Running all the time in the systray
> 2. Handle PIN Request
> 3. Local adapter configuration
> 4. Basic operations: Inquiry, Remote name, ...

cool idea. We really need something like this.

> However I am facing a problem in the RemoteName service when a lot of
> inquiry replies is received. My app stores the inquired devices in a
> hash table and when the InquiryCompleted signal is received the app
> request the name for each device. The "hci_send_req" function is
> returning an Input/Output error. Looking the hcidump result, the
> "Command Disallowed" error is displayed :(
> 
> HCIDUMP:
> > HCI Event: Command Status (0x0f) plen 4
>     Remote Name Request (0x01|0x0019) status 0x0c ncmd 1
>     Error: Command Disallowed
>  <<<<<Indicates that the controller is in a state where it can process
> this command at this time.>>>>
> 
> I noticed the same problem using the hcitool with "--flush" option and
> removing the cached device information stored in the directory
> "/var/lib/bluetooth".

What kind of chip is in your dongle? Do you wait until the remote name
complete event before asking for the next name? Every name request needs
at least a partial baseband connection.

Regards

Marcel




-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Remote name delay

[Claudio Takahasi]

Hi Marcel,

On 12/1/05, Marcel Holtmann <marcel@holtmann.org> wrote:
> Hi Claudio,
>
> > I am developing a standalone application to perform real D-Bus
> > services tests. The main features are:
> > 1. Running all the time in the systray
> > 2. Handle PIN Request
> > 3. Local adapter configuration
> > 4. Basic operations: Inquiry, Remote name, ...
>
> cool idea. We really need something like this.
[Claudio Takahasi]
I am not a good UI developer, but this application can be the start
point for other developers to improve it. I will sent the first
prototype to the list as soon as I get better icons :)

>
> > However I am facing a problem in the RemoteName service when a lot of
> > inquiry replies is received. My app stores the inquired devices in a
> > hash table and when the InquiryCompleted signal is received the app
> > request the name for each device. The "hci_send_req" function is
> > returning an Input/Output error. Looking the hcidump result, the
> > "Command Disallowed" error is displayed :(
> >
> > HCIDUMP:
> > > HCI Event: Command Status (0x0f) plen 4
> >     Remote Name Request (0x01|0x0019) status 0x0c ncmd 1
> >     Error: Command Disallowed
> >  <<<<<Indicates that the controller is in a state where it can process
> > this command at this time.>>>>
> >
> > I noticed the same problem using the hcitool with "--flush" option and
> > removing the cached device information stored in the directory
> > "/var/lib/bluetooth".
>
> What kind of chip is in your dongle? Do you wait until the remote name
> complete event before asking for the next name? Every name request needs
> at least a partial baseband connection.
[Claudio Takahasi]
Dongle - D-Link DBT-122
        Class: 0x3e0100
        Service Classes: Networking, Rendering, Capturing
        Device Class: Computer, Uncategorized
        HCI Ver: 1.2 (0x2) HCI Rev: 0x0 LMP Ver: 1.2 (0x2) LMP Subver: 0x30=
9
        Manufacturer: Broadcom Corporation (15)

Yes, I am waiting for the RemoteNameComplete signal, for this case it
works fine. But I am testing simultaneous request. BlueZ D-Bus client
developers should not care about listen for RemoteNameComplete event
before send another request. We can try define a queue for
simultaneous request.  What do you think? What are the other
operations that we will find the same problem?

I will submit a patch to improve the remote name in order to consider
the clock offset and page scan parameters.

Regards,
Claudio.

>
> Regards
>
> Marcel
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log fi=
les
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_id=3D7637&alloc_id=3D16865&op=3Dclick
> _______________________________________________
> Bluez-devel mailing list
> Bluez-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
>


--
---------------------------------------------------------
Claudio Takahasi
Instituto Nokia de Tecnologia - INdT


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Remote name delay

[Marcel Holtmann]

Hi Claudio,

> > > I am developing a standalone application to perform real D-Bus
> > > services tests. The main features are:
> > > 1. Running all the time in the systray
> > > 2. Handle PIN Request
> > > 3. Local adapter configuration
> > > 4. Basic operations: Inquiry, Remote name, ...
> >
> > cool idea. We really need something like this.
> 
> I am not a good UI developer, but this application can be the start
> point for other developers to improve it. I will sent the first
> prototype to the list as soon as I get better icons :)

is this for Gnome and in C? I like to create a bluez-gnome repository
and then make a pre-release really soon.

> > > However I am facing a problem in the RemoteName service when a lot of
> > > inquiry replies is received. My app stores the inquired devices in a
> > > hash table and when the InquiryCompleted signal is received the app
> > > request the name for each device. The "hci_send_req" function is
> > > returning an Input/Output error. Looking the hcidump result, the
> > > "Command Disallowed" error is displayed :(
> > >
> > > HCIDUMP:
> > > > HCI Event: Command Status (0x0f) plen 4
> > >     Remote Name Request (0x01|0x0019) status 0x0c ncmd 1
> > >     Error: Command Disallowed
> > >  <<<<<Indicates that the controller is in a state where it can process
> > > this command at this time.>>>>
> > >
> > > I noticed the same problem using the hcitool with "--flush" option and
> > > removing the cached device information stored in the directory
> > > "/var/lib/bluetooth".
> >
> > What kind of chip is in your dongle? Do you wait until the remote name
> > complete event before asking for the next name? Every name request needs
> > at least a partial baseband connection.
> 
> Dongle - D-Link DBT-122
>         Class: 0x3e0100
>         Service Classes: Networking, Rendering, Capturing
>         Device Class: Computer, Uncategorized
>         HCI Ver: 1.2 (0x2) HCI Rev: 0x0 LMP Ver: 1.2 (0x2) LMP Subver: 0x309
>         Manufacturer: Broadcom Corporation (15)
> 
> Yes, I am waiting for the RemoteNameComplete signal, for this case it
> works fine. But I am testing simultaneous request. BlueZ D-Bus client
> developers should not care about listen for RemoteNameComplete event
> before send another request. We can try define a queue for
> simultaneous request.  What do you think? What are the other
> operations that we will find the same problem?

You will always see this problem if the establishment of baseband
connection is needed, meaning if you create an ACL link.

The good thing is that extended inquiry will solve this almost, but for
older devices the only possibility is to retrieve the name from a cache
or queue the commands.

> I will submit a patch to improve the remote name in order to consider
> the clock offset and page scan parameters.

Don't expose these commands over the D-Bus interface. We don't wanna
deal with them there, because they should be internal only.

Regards

Marcel




-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Remote name delay

[Claudio Takahasi]

Hi Marcel,

On 12/2/05, Marcel Holtmann <marcel@holtmann.org> wrote:
> Hi Claudio,
>
> > > > I am developing a standalone application to perform real D-Bus
> > > > services tests. The main features are:
> > > > 1. Running all the time in the systray
> > > > 2. Handle PIN Request
> > > > 3. Local adapter configuration
> > > > 4. Basic operations: Inquiry, Remote name, ...
> > >
> > > cool idea. We really need something like this.
> >
> > I am not a good UI developer, but this application can be the start
> > point for other developers to improve it. I will sent the first
> > prototype to the list as soon as I get better icons :)
>
> is this for Gnome and in C? I like to create a bluez-gnome repository
> and then make a pre-release really soon.
[Claudio Takahasi]
Yes. I am using GladeXML object to load the widgets inside a XML file
description.
There are soem screenshot available at:
http://www.cin.ufpe.br/~ckt/gbluezconf/

>
> > > > However I am facing a problem in the RemoteName service when a lot =
of
> > > > inquiry replies is received. My app stores the inquired devices in =
a
> > > > hash table and when the InquiryCompleted signal is received the app
> > > > request the name for each device. The "hci_send_req" function is
> > > > returning an Input/Output error. Looking the hcidump result, the
> > > > "Command Disallowed" error is displayed :(
> > > >
> > > > HCIDUMP:
> > > > > HCI Event: Command Status (0x0f) plen 4
> > > >     Remote Name Request (0x01|0x0019) status 0x0c ncmd 1
> > > >     Error: Command Disallowed
> > > >  <<<<<Indicates that the controller is in a state where it can proc=
ess
> > > > this command at this time.>>>>
> > > >
> > > > I noticed the same problem using the hcitool with "--flush" option =
and
> > > > removing the cached device information stored in the directory
> > > > "/var/lib/bluetooth".
> > >
> > > What kind of chip is in your dongle? Do you wait until the remote nam=
e
> > > complete event before asking for the next name? Every name request ne=
eds
> > > at least a partial baseband connection.
> >
> > Dongle - D-Link DBT-122
> >         Class: 0x3e0100
> >         Service Classes: Networking, Rendering, Capturing
> >         Device Class: Computer, Uncategorized
> >         HCI Ver: 1.2 (0x2) HCI Rev: 0x0 LMP Ver: 1.2 (0x2) LMP Subver: =
0x309
> >         Manufacturer: Broadcom Corporation (15)
> >
> > Yes, I am waiting for the RemoteNameComplete signal, for this case it
> > works fine. But I am testing simultaneous request. BlueZ D-Bus client
> > developers should not care about listen for RemoteNameComplete event
> > before send another request. We can try define a queue for
> > simultaneous request.  What do you think? What are the other
> > operations that we will find the same problem?
>
> You will always see this problem if the establishment of baseband
> connection is needed, meaning if you create an ACL link.
>
> The good thing is that extended inquiry will solve this almost, but for
> older devices the only possibility is to retrieve the name from a cache
> or queue the commands.
[Claudio Takahasi]
I know that the cache is available at:
/var/lib/bluetooth/AA:BB:CC:DD:EE:FF/names

I will analize this issue better in order to try improve the D-Bus
request name.
>
> > I will submit a patch to improve the remote name in order to consider
> > the clock offset and page scan parameters.
>
> Don't expose these commands over the D-Bus interface. We don't wanna
> deal with them there, because they should be internal only.
[Claudio Takahasi]
Is there a way to retrieve the clock offset and the page scan
parameters inside the hcid?
ps: the inquiry result(clock offset and page scan parameters) is not
being cached before send the D-Bus signals.
Do you have any idea of how expensive is request the name without
consider the clock offset and page scan parameters?

Regards,
Claudio.

>
> Regards
>
> Marcel
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log fi=
les
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_id=3D7637&alloc_id=3D16865&op=3Dclick
> _______________________________________________
> Bluez-devel mailing list
> Bluez-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
>


--
---------------------------------------------------------
Claudio Takahasi
Instituto Nokia de Tecnologia - INdT


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Remote name delay

[Bastien Nocera]

On Fri, 2005-12-02 at 14:33 -0200, Claudio Takahasi wrote:
> Hi Marcel,
> 
> On 12/2/05, Marcel Holtmann <marcel@holtmann.org> wrote:
> > Hi Claudio,
> >
> > > > > I am developing a standalone application to perform real D-Bus
> > > > > services tests. The main features are:
> > > > > 1. Running all the time in the systray
> > > > > 2. Handle PIN Request
> > > > > 3. Local adapter configuration
> > > > > 4. Basic operations: Inquiry, Remote name, ...
> > > >
> > > > cool idea. We really need something like this.
> > >
> > > I am not a good UI developer, but this application can be the start
> > > point for other developers to improve it. I will sent the first
> > > prototype to the list as soon as I get better icons :)
> >
> > is this for Gnome and in C? I like to create a bluez-gnome repository
> > and then make a pre-release really soon.
> [Claudio Takahasi]
> Yes. I am using GladeXML object to load the widgets inside a XML file
> description.
> There are soem screenshot available at:
> http://www.cin.ufpe.br/~ckt/gbluezconf/

Most of the backend stuff could be merged in libbtctl, and the GUI stuff
in gnome-bluetooth (we're working on removing the python gnome-
bluetooth-manager).

Are you interested in working on those, rather than creating another
module/UI/etc.?

---
Bastien Nocera <hadess@hadess.net> 
"Don't send me flowers when I'm dead. If you like me, send them while
I'm alive" - Brian Clough, after the liver transplant which saved his
life.



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Remote name delay

[Marcel Holtmann]

Hi Bastien,

> > Yes. I am using GladeXML object to load the widgets inside a XML file
> > description.
> > There are soem screenshot available at:
> > http://www.cin.ufpe.br/~ckt/gbluezconf/
> 
> Most of the backend stuff could be merged in libbtctl, and the GUI stuff
> in gnome-bluetooth (we're working on removing the python gnome-
> bluetooth-manager).

actually I don't think so, because the GUI should never use the BlueZ
library directly. The goal is to do everything over D-Bus and you don't
need another library in between. The D-Bus interface itself is the
abstraction from the lower level task.

Regards

Marcel




-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Remote name delay

[Claudio Takahasi]

Hi Bastien,

My initial plan was just develop a test interface to be used as a
reference to other developers. My focus now will be continue develop
BlueZ D-Bus services.

I am not a good linux UI developer. My background is mobile
platforms(BREW, J2ME, Motorola proprietary UIs) and windows :) I
checked the gnome-bluetooth code, but at the momment I don't fell
confortable on changing your code, there are a lot of coding that I
have no idea how it works. However we can reconsider in the future.

If you need more infos about BlueZ D-Bus services, feel free to send emails=
.

Regards,
Claudio

On 12/2/05, Marcel Holtmann <marcel@holtmann.org> wrote:
> Hi Bastien,
>
> > > Yes. I am using GladeXML object to load the widgets inside a XML file
> > > description.
> > > There are soem screenshot available at:
> > > http://www.cin.ufpe.br/~ckt/gbluezconf/
> >
> > Most of the backend stuff could be merged in libbtctl, and the GUI stuf=
f
> > in gnome-bluetooth (we're working on removing the python gnome-
> > bluetooth-manager).
>
> actually I don't think so, because the GUI should never use the BlueZ
> library directly. The goal is to do everything over D-Bus and you don't
> need another library in between. The D-Bus interface itself is the
> abstraction from the lower level task.
>
> Regards
>
> Marcel
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log fi=
les
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_id=3D7637&alloc_id=3D16865&op=3Dclick
> _______________________________________________
> Bluez-devel mailing list
> Bluez-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
>


--
---------------------------------------------------------
Claudio Takahasi
Instituto Nokia de Tecnologia - INdT


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Remote name delay

[Marcel Holtmann]

Hi Claudio,

> > > > > I am developing a standalone application to perform real D-Bus
> > > > > services tests. The main features are:
> > > > > 1. Running all the time in the systray
> > > > > 2. Handle PIN Request
> > > > > 3. Local adapter configuration
> > > > > 4. Basic operations: Inquiry, Remote name, ...
> > > >
> > > > cool idea. We really need something like this.
> > >
> > > I am not a good UI developer, but this application can be the start
> > > point for other developers to improve it. I will sent the first
> > > prototype to the list as soon as I get better icons :)
> >
> > is this for Gnome and in C? I like to create a bluez-gnome repository
> > and then make a pre-release really soon.
> 
> Yes. I am using GladeXML object to load the widgets inside a XML file
> description.
> There are soem screenshot available at:
> http://www.cin.ufpe.br/~ckt/gbluezconf/

looks very nice. Once you think it is ready for public review, drop me a
note and I create a new repository for it.

> > > > > However I am facing a problem in the RemoteName service when a lot of
> > > > > inquiry replies is received. My app stores the inquired devices in a
> > > > > hash table and when the InquiryCompleted signal is received the app
> > > > > request the name for each device. The "hci_send_req" function is
> > > > > returning an Input/Output error. Looking the hcidump result, the
> > > > > "Command Disallowed" error is displayed :(
> > > > >
> > > > > HCIDUMP:
> > > > > > HCI Event: Command Status (0x0f) plen 4
> > > > >     Remote Name Request (0x01|0x0019) status 0x0c ncmd 1
> > > > >     Error: Command Disallowed
> > > > >  <<<<<Indicates that the controller is in a state where it can process
> > > > > this command at this time.>>>>
> > > > >
> > > > > I noticed the same problem using the hcitool with "--flush" option and
> > > > > removing the cached device information stored in the directory
> > > > > "/var/lib/bluetooth".
> > > >
> > > > What kind of chip is in your dongle? Do you wait until the remote name
> > > > complete event before asking for the next name? Every name request needs
> > > > at least a partial baseband connection.
> > >
> > > Dongle - D-Link DBT-122
> > >         Class: 0x3e0100
> > >         Service Classes: Networking, Rendering, Capturing
> > >         Device Class: Computer, Uncategorized
> > >         HCI Ver: 1.2 (0x2) HCI Rev: 0x0 LMP Ver: 1.2 (0x2) LMP Subver: 0x309
> > >         Manufacturer: Broadcom Corporation (15)
> > >
> > > Yes, I am waiting for the RemoteNameComplete signal, for this case it
> > > works fine. But I am testing simultaneous request. BlueZ D-Bus client
> > > developers should not care about listen for RemoteNameComplete event
> > > before send another request. We can try define a queue for
> > > simultaneous request.  What do you think? What are the other
> > > operations that we will find the same problem?
> >
> > You will always see this problem if the establishment of baseband
> > connection is needed, meaning if you create an ACL link.
> >
> > The good thing is that extended inquiry will solve this almost, but for
> > older devices the only possibility is to retrieve the name from a cache
> > or queue the commands.
> 
> I know that the cache is available at:
> /var/lib/bluetooth/AA:BB:CC:DD:EE:FF/names
> 
> I will analize this issue better in order to try improve the D-Bus
> request name.

It is not worth it. This is a limitation we have to live with.

> > > I will submit a patch to improve the remote name in order to consider
> > > the clock offset and page scan parameters.
> >
> > Don't expose these commands over the D-Bus interface. We don't wanna
> > deal with them there, because they should be internal only.
> 
> Is there a way to retrieve the clock offset and the page scan
> parameters inside the hcid?

You can cache the inquiry results like the kernel is doing it.

> ps: the inquiry result(clock offset and page scan parameters) is not
> being cached before send the D-Bus signals.
> Do you have any idea of how expensive is request the name without
> consider the clock offset and page scan parameters?

This depends on the firmware inside the chip. I still think that newer
CSR firmwares are caching these values and replacing them internally
when needed. However this is only speculation.

Regards

Marcel




-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Remote name delay

[Claudio Takahasi]

Hi Marcel,

There are some device properties I would like show in the adapter
configuration dialog.
http://www.cin.ufpe.br/~ckt/gbluezconf/config.gif

Do you agree provide D-Bus services to retrieve Manufacturer and
firmware details? We can extend the GetProperty to support get these
infos.

Currently I am solving some D-Bus signals filters and multiple dialogs
issues. When it become stable I will send the first prototype. I have
to send until next monday because I have vacations :)

Regards,
Claudio.


On 12/2/05, Marcel Holtmann <marcel@holtmann.org> wrote:
> Hi Claudio,
>
> > > > > > I am developing a standalone application to perform real D-Bus
> > > > > > services tests. The main features are:
> > > > > > 1. Running all the time in the systray
> > > > > > 2. Handle PIN Request
> > > > > > 3. Local adapter configuration
> > > > > > 4. Basic operations: Inquiry, Remote name, ...
> > > > >
> > > > > cool idea. We really need something like this.
> > > >
> > > > I am not a good UI developer, but this application can be the start
> > > > point for other developers to improve it. I will sent the first
> > > > prototype to the list as soon as I get better icons :)
> > >
> > > is this for Gnome and in C? I like to create a bluez-gnome repository
> > > and then make a pre-release really soon.
> >
> > Yes. I am using GladeXML object to load the widgets inside a XML file
> > description.
> > There are soem screenshot available at:
> > http://www.cin.ufpe.br/~ckt/gbluezconf/
>
> looks very nice. Once you think it is ready for public review, drop me a
> note and I create a new repository for it.
>
> > > > > > However I am facing a problem in the RemoteName service when a =
lot of
> > > > > > inquiry replies is received. My app stores the inquired devices=
 in a
> > > > > > hash table and when the InquiryCompleted signal is received the=
 app
> > > > > > request the name for each device. The "hci_send_req" function i=
s
> > > > > > returning an Input/Output error. Looking the hcidump result, th=
e
> > > > > > "Command Disallowed" error is displayed :(
> > > > > >
> > > > > > HCIDUMP:
> > > > > > > HCI Event: Command Status (0x0f) plen 4
> > > > > >     Remote Name Request (0x01|0x0019) status 0x0c ncmd 1
> > > > > >     Error: Command Disallowed
> > > > > >  <<<<<Indicates that the controller is in a state where it can =
process
> > > > > > this command at this time.>>>>
> > > > > >
> > > > > > I noticed the same problem using the hcitool with "--flush" opt=
ion and
> > > > > > removing the cached device information stored in the directory
> > > > > > "/var/lib/bluetooth".
> > > > >
> > > > > What kind of chip is in your dongle? Do you wait until the remote=
 name
> > > > > complete event before asking for the next name? Every name reques=
t needs
> > > > > at least a partial baseband connection.
> > > >
> > > > Dongle - D-Link DBT-122
> > > >         Class: 0x3e0100
> > > >         Service Classes: Networking, Rendering, Capturing
> > > >         Device Class: Computer, Uncategorized
> > > >         HCI Ver: 1.2 (0x2) HCI Rev: 0x0 LMP Ver: 1.2 (0x2) LMP Subv=
er: 0x309
> > > >         Manufacturer: Broadcom Corporation (15)
> > > >
> > > > Yes, I am waiting for the RemoteNameComplete signal, for this case =
it
> > > > works fine. But I am testing simultaneous request. BlueZ D-Bus clie=
nt
> > > > developers should not care about listen for RemoteNameComplete even=
t
> > > > before send another request. We can try define a queue for
> > > > simultaneous request.  What do you think? What are the other
> > > > operations that we will find the same problem?
> > >
> > > You will always see this problem if the establishment of baseband
> > > connection is needed, meaning if you create an ACL link.
> > >
> > > The good thing is that extended inquiry will solve this almost, but f=
or
> > > older devices the only possibility is to retrieve the name from a cac=
he
> > > or queue the commands.
> >
> > I know that the cache is available at:
> > /var/lib/bluetooth/AA:BB:CC:DD:EE:FF/names
> >
> > I will analize this issue better in order to try improve the D-Bus
> > request name.
>
> It is not worth it. This is a limitation we have to live with.
>
> > > > I will submit a patch to improve the remote name in order to consid=
er
> > > > the clock offset and page scan parameters.
> > >
> > > Don't expose these commands over the D-Bus interface. We don't wanna
> > > deal with them there, because they should be internal only.
> >
> > Is there a way to retrieve the clock offset and the page scan
> > parameters inside the hcid?
>
> You can cache the inquiry results like the kernel is doing it.
>
> > ps: the inquiry result(clock offset and page scan parameters) is not
> > being cached before send the D-Bus signals.
> > Do you have any idea of how expensive is request the name without
> > consider the clock offset and page scan parameters?
>
> This depends on the firmware inside the chip. I still think that newer
> CSR firmwares are caching these values and replacing them internally
> when needed. However this is only speculation.
>
> Regards
>
> Marcel
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log fi=
les
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_id=3D7637&alloc_id=3D16865&op=3Dclick
> _______________________________________________
> Bluez-devel mailing list
> Bluez-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
>


--
---------------------------------------------------------
Claudio Takahasi
Instituto Nokia de Tecnologia - INdT


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Remote name delay

[Marcel Holtmann]

Hi Claudio,

> There are some device properties I would like show in the adapter
> configuration dialog.
> http://www.cin.ufpe.br/~ckt/gbluezconf/config.gif
> 
> Do you agree provide D-Bus services to retrieve Manufacturer and
> firmware details? We can extend the GetProperty to support get these
> infos.

feel free to do it. That's fine with me.

> Currently I am solving some D-Bus signals filters and multiple dialogs
> issues. When it become stable I will send the first prototype. I have
> to send until next monday because I have vacations :)

Can't wait to give it a shoot. Will create a bluez-gnome CVS repository
then.

Regards

Marcel




-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Remote name delay

[Claudio Takahasi]

Hi Marcel,

ok. We will extend the GetProperty(string:info) returning the
following arguments:
- MAC Address: String
- Device Status: String(UP/DOWN)
- Manufacturer: String
- HCI Version: String
- HCI Revision: String
- LMP Version: String
- LMP Sub Version: String

The firmware revision was removed from the dialog because it's not
possible get this info.


Regards,
Claudio

On 12/13/05, Marcel Holtmann <marcel@holtmann.org> wrote:
> Hi Claudio,
>
> > There are some device properties I would like show in the adapter
> > configuration dialog.
> > http://www.cin.ufpe.br/~ckt/gbluezconf/config.gif
> >
> > Do you agree provide D-Bus services to retrieve Manufacturer and
> > firmware details? We can extend the GetProperty to support get these
> > infos.
>
> feel free to do it. That's fine with me.
>
> > Currently I am solving some D-Bus signals filters and multiple dialogs
> > issues. When it become stable I will send the first prototype. I have
> > to send until next monday because I have vacations :)
>
> Can't wait to give it a shoot. Will create a bluez-gnome CVS repository
> then.
>
> Regards
>
> Marcel
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log fi=
les
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_id=3D7637&alloc_id=3D16865&op=3Dclick
> _______________________________________________
> Bluez-devel mailing list
> Bluez-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
>


--
---------------------------------------------------------
Claudio Takahasi
Instituto Nokia de Tecnologia - INdT


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Remote name delay

[Marcel Holtmann]

Hi Claudio,

> ok. We will extend the GetProperty(string:info) returning the
> following arguments:
> - MAC Address: String
> - Device Status: String(UP/DOWN)
> - Manufacturer: String
> - HCI Version: String
> - HCI Revision: String
> - LMP Version: String
> - LMP Sub Version: String
> 
> The firmware revision was removed from the dialog because it's not
> possible get this info.

why do you wanna remove this. We only need to implement the same logic
from hciconfig into hcid. I don't have a problem with it.

Regards

Marcel




-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Remote name delay

[Claudio Takahasi]

Hi Marcel,

Sorry, It was a mistake. I checked the hciconfig code and figure out
that the firmware revision is based on HCI and LMP version/revision.

Eduardo will start fun with GetProperty(string:info) when he finishes
the scan enable/disable  service.

Regards,
Claudio.

On 12/14/05, Marcel Holtmann <marcel@holtmann.org> wrote:
> Hi Claudio,
>
> > ok. We will extend the GetProperty(string:info) returning the
> > following arguments:
> > - MAC Address: String
> > - Device Status: String(UP/DOWN)
> > - Manufacturer: String
> > - HCI Version: String
> > - HCI Revision: String
> > - LMP Version: String
> > - LMP Sub Version: String
> >
> > The firmware revision was removed from the dialog because it's not
> > possible get this info.
>
> why do you wanna remove this. We only need to implement the same logic
> from hciconfig into hcid. I don't have a problem with it.
>
> Regards
>
> Marcel
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log fi=
les
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_id=3D7637&alloc_id=3D16865&op=3Dclick
> _______________________________________________
> Bluez-devel mailing list
> Bluez-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
>


--
---------------------------------------------------------
Claudio Takahasi
Instituto Nokia de Tecnologia - INdT


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Remote name delay

[Johan Hedberg]

Hi Claudio,

On Wed, Dec 14, 2005, Claudio Takahasi wrote:
> ok. We will extend the GetProperty(string:info) returning the
> following arguments:
> - MAC Address: String
> - Device Status: String(UP/DOWN)
> - Manufacturer: String
> - HCI Version: String
> - HCI Revision: String
> - LMP Version: String
> - LMP Sub Version: String

Currently we have three different property types: string, boolean and
byte. Are you proposing that the above information be bundled to one
"info" property? That would create a fourth property type which, in my
opinion, would complicate the code unecessarely. Maybe those pieces of
information should be split into one property each (or maybe that's what
you're suggesting, sorry if I misunderstood)? If there still exists a
complelling reason to bundle all that info into one property, then I'd
suggest creating a new property with the type DBUS_TYPE_STRUCT in order
to maintain consistency with the parameters of the property signal and
methods.

Also, all of the above pieces of information, excluding the device
status, are of a read-only nature so the SetProperty method and
PropertyChanged signal don't really apply to them. Therefore the
question should be asked whether the "properties" feature is the right
one to use for them (I'm not saying it isn't, just that it should be
questioned). E.g. you would need to think about what error should be
returned if SetProperty is called for one of them.

Thirdly, the device status information can already changed using the Up
and Down methods and its changes can be tracked using the Up and Down
signals, so adding it to the set of properties is probably not the right
thing to do (or then the Up/Down signals and methods should be removed).

Johan


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Remote name delay

[Marcel Holtmann]

Hi Johan,

> > ok. We will extend the GetProperty(string:info) returning the
> > following arguments:
> > - MAC Address: String
> > - Device Status: String(UP/DOWN)
> > - Manufacturer: String
> > - HCI Version: String
> > - HCI Revision: String
> > - LMP Version: String
> > - LMP Sub Version: String
> 
> Currently we have three different property types: string, boolean and
> byte. Are you proposing that the above information be bundled to one
> "info" property? That would create a fourth property type which, in my
> opinion, would complicate the code unecessarely. Maybe those pieces of
> information should be split into one property each (or maybe that's what
> you're suggesting, sorry if I misunderstood)? If there still exists a
> complelling reason to bundle all that info into one property, then I'd
> suggest creating a new property with the type DBUS_TYPE_STRUCT in order
> to maintain consistency with the parameters of the property signal and
> methods.

from the first looking at it, I would say that it should be an info
structure, but I agree that this will make the code to complex. On the
other hand, I don't like to have too many properties only for some
device information.

Do you think anyone will parse them ever? I think they will only be
displayed by the user interface, right? So maybe something like

	Address:	"00:09:DD:xx:xx:xx"
	Manufacturer:	"Cambridge Silicon Radio"
	HCI Version:	"2.0 (revision 0xa3e)"
	LMP Version:	"2.0 (subversion 0xa3e)"

will do for now. But we maybe need to have the integer values and the
strings available. I don't wanna force the need for any integer-string
conversion tables in the user applications.

And btw it would be also good to present the feature bits.

> Also, all of the above pieces of information, excluding the device
> status, are of a read-only nature so the SetProperty method and
> PropertyChanged signal don't really apply to them. Therefore the
> question should be asked whether the "properties" feature is the right
> one to use for them (I'm not saying it isn't, just that it should be
> questioned). E.g. you would need to think about what error should be
> returned if SetProperty is called for one of them.

Let's leave out the device status for now.

Regards

Marcel




-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Remote name delay

[Claudio Takahasi]

Hi,

After your feedbacks, I think it's better remove the
"GetProperty('info')" in order to avoid confusion. We can create a new
method called "Info(void)" to retrieve read-only properties returning:
Address: String
Manufacturer: String
HCI Version: String, format TBD
LMP Version: String, format TBD

We don't need a fild to retrieve the device status. The device
status(UP/DOWN) signal can be tracked all the time. Keep in mind that,
for multiple adapter scenarios will be more difficult  track the
UP/DOWN signals. Currently, it's possible recover the device status
using the DevList, but it's little bit expensive request/parsing all
arguments. When the adapter is DOWN, change the adapter property will
fail(Probably due a operation timeout), for this case get the device
status is useful. These are the reasons why I would like receive the
status in the "Info(void)" reply message.

The final decision is yours! :) If we consider it necessary we can add
it in the future without problems.


For Read/Write properties:
- auth
- connectable
- discoverable
- encrypt
- name
- inqmode
We can keep the the same signature for GetProperty/SetProperty.
Eg:
SetProperty("name", "new name"), request signature: String, String
GetProperty("name"), reply signature: String

SetProperty("encrypt", TRUE), request signature: String, Boolean
GetProperty("encrypt"), reply signature: Boolean


Regards.
Claudio.




On 12/15/05, Marcel Holtmann <marcel@holtmann.org> wrote:
> Hi Johan,
>
> > > ok. We will extend the GetProperty(string:info) returning the
> > > following arguments:
> > > - MAC Address: String
> > > - Device Status: String(UP/DOWN)
> > > - Manufacturer: String
> > > - HCI Version: String
> > > - HCI Revision: String
> > > - LMP Version: String
> > > - LMP Sub Version: String
> >
> > Currently we have three different property types: string, boolean and
> > byte. Are you proposing that the above information be bundled to one
> > "info" property? That would create a fourth property type which, in my
> > opinion, would complicate the code unecessarely. Maybe those pieces of
> > information should be split into one property each (or maybe that's wha=
t
> > you're suggesting, sorry if I misunderstood)? If there still exists a
> > complelling reason to bundle all that info into one property, then I'd
> > suggest creating a new property with the type DBUS_TYPE_STRUCT in order
> > to maintain consistency with the parameters of the property signal and
> > methods.
>
> from the first looking at it, I would say that it should be an info
> structure, but I agree that this will make the code to complex. On the
> other hand, I don't like to have too many properties only for some
> device information.
>
> Do you think anyone will parse them ever? I think they will only be
> displayed by the user interface, right? So maybe something like
>
>         Address:        "00:09:DD:xx:xx:xx"
>         Manufacturer:   "Cambridge Silicon Radio"
>         HCI Version:    "2.0 (revision 0xa3e)"
>         LMP Version:    "2.0 (subversion 0xa3e)"
>
> will do for now. But we maybe need to have the integer values and the
> strings available. I don't wanna force the need for any integer-string
> conversion tables in the user applications.
>
> And btw it would be also good to present the feature bits.
>
> > Also, all of the above pieces of information, excluding the device
> > status, are of a read-only nature so the SetProperty method and
> > PropertyChanged signal don't really apply to them. Therefore the
> > question should be asked whether the "properties" feature is the right
> > one to use for them (I'm not saying it isn't, just that it should be
> > questioned). E.g. you would need to think about what error should be
> > returned if SetProperty is called for one of them.
>
> Let's leave out the device status for now.
>
> Regards
>
> Marcel
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log fi=
les
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_id=3D7637&alloc_id=3D16865&op=3Dclick
> _______________________________________________
> Bluez-devel mailing list
> Bluez-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
>


--
---------------------------------------------------------
Claudio Takahasi
Instituto Nokia de Tecnologia - INdT


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Remote name delay

[Johan Hedberg]

Hi Claudio,

On Thu, Dec 15, 2005, Claudio Takahasi wrote:
> After your feedbacks, I think it's better remove the
> "GetProperty('info')" in order to avoid confusion. We can create a new
> method called "Info(void)" to retrieve read-only properties returning:
> Address: String
> Manufacturer: String
> HCI Version: String, format TBD
> LMP Version: String, format TBD

Sounds like a good idea.

Johan


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Remote name delay

[Marcel Holtmann]

Hi Claudio,

> After your feedbacks, I think it's better remove the
> "GetProperty('info')" in order to avoid confusion. We can create a new
> method called "Info(void)" to retrieve read-only properties returning:
> Address: String
> Manufacturer: String
> HCI Version: String, format TBD
> LMP Version: String, format TBD
> 
> We don't need a fild to retrieve the device status. The device
> status(UP/DOWN) signal can be tracked all the time. Keep in mind that,
> for multiple adapter scenarios will be more difficult  track the
> UP/DOWN signals. Currently, it's possible recover the device status
> using the DevList, but it's little bit expensive request/parsing all
> arguments. When the adapter is DOWN, change the adapter property will
> fail(Probably due a operation timeout), for this case get the device
> status is useful. These are the reasons why I would like receive the
> status in the "Info(void)" reply message.
> 
> The final decision is yours! :) If we consider it necessary we can add
> it in the future without problems.

at the moment I don't have any favor in any direction. Implement one and
then we see how it goes.

> For Read/Write properties:
> - auth
> - connectable
> - discoverable
> - encrypt
> - name
> - inqmode

Remove "auth" and "encrypt" from this list. I am not going to support
Security Mode 3 settings over D-Bus. They are crap anyway and hopefully
at somepoint I can convince everybody that Security Mode 3 alone makes
no sense at all.

I also don't see any need for the inquiry mode setting. Since it is all
transparent, the hcid should simply set the highest available inquiry
mode on startup and then send inquiry result signals as usual.

Regards

Marcel




-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel