Heya,
I've been wondering why my devices weren't showing up in
nautilus-sendto, and it looks like DiscoverDevices doesn't work. Here's
the snippet of code:
dbus_g_proxy_call (object, "DiscoverDevices", &e,
G_TYPE_INVALID, G_TYPE_INVALID);
if (e != NULL) {
g_warning ("Couldn't start discovery: %s: %s",
dbus_g_error_get_name (e), e->message);
g_error_free (e);
}
I do a list ListBondings before that on the same object, so I know that
it works. But I still get that error:
Couldn't start discovery: org.bluez.Error.Failed: Device or resource busy
I'm using bluez-utils 3.9
Cheers
--
Bastien Nocera <[email protected]>
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Mayank,
> > > I hope there's at least some way to get it working. I'd
> > > rather not have
> > > to have another dongle just because hcid doesn't like it :)
> >
> > the problem is that the baseband is busy with the remote name request.
> > It has to page the remote device for getting the name and in that case
> > you simply can't run an inquiry. All currently available
> > Bluetooth chips have this limitation.
> >
> > Main question is why we have the remote name request just before you
> > wanna start the inquiry. What D-Bus methods are you actually calling
> in
> > what order? I think you constructed a use case that we never tested.
>
> But actually, the sequence of HCI commands issued is correct. First, a
> remote
> name request is issued. Then, since an inquiry is required, the remote
> name
> request is cancelled. Thus, paging should stop and inquiry should be
> possible.
> I think this use case should work with BT1.2 devices and above.
>
> But you are right, maybe some workaround should be present in order to
> be
> compatible with BT1.1 devices as well.
we need a workaround for Bluetooth 1.1 devices. However I have no idea
what we can actually do to make this work.
My idea is to not actively request names when not in discovery mode.
That would actually fix this cases.
Regards
Marcel
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Bastien,
> > > Shouldn't it return org.bluez.Error.InProgress instead in that case?
> >
> > it is a different operation that is in progress.
>
> Ha. The documentation could do with a bit of rewording for that error
> (it's not clear that InProgress is when the *same* operation that one
> tried to perform is already running).
I agree. That needs a little bit better wording. In some cases we might
even have some bugs in the code.
> > > > You can wait for the completed RemoteNameUpdated or RemoteNameFailed
> > > > signals before actually starting the DiscoverDevices procedure. However
> > > > in case of devices out of range this might not be a good idea.
> > >
> > > The problem is that I don't know for which devices hcid will try to go
> > > and fetch the names for.
> > >
> > > Also, the doc for ListRemoteDevices should mention the fact that it
> > > might perform remote operations, as it's not really clear from the doc
> > > right now.
> >
> > Actually ListRemoteDevices is not doing it. It happens when you call
> > GetRemoteName while you are adding it to your list.
>
> Oh, my mistake. I'll fix my code then :)
Not your mistake. This should actually work. However we added a
GetRemoteInfo method lately that allows you to retrieve all known
information about a device as a dictionary.
Regards
Marcel
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On Thu, 2007-03-29 at 14:20 +0200, Marcel Holtmann wrote:
> Hi Bastien,
<snip>
> > Shouldn't it return org.bluez.Error.InProgress instead in that case?
>
> it is a different operation that is in progress.
Ha. The documentation could do with a bit of rewording for that error
(it's not clear that InProgress is when the *same* operation that one
tried to perform is already running).
> > > You can wait for the completed RemoteNameUpdated or RemoteNameFailed
> > > signals before actually starting the DiscoverDevices procedure. However
> > > in case of devices out of range this might not be a good idea.
> >
> > The problem is that I don't know for which devices hcid will try to go
> > and fetch the names for.
> >
> > Also, the doc for ListRemoteDevices should mention the fact that it
> > might perform remote operations, as it's not really clear from the doc
> > right now.
>
> Actually ListRemoteDevices is not doing it. It happens when you call
> GetRemoteName while you are adding it to your list.
Oh, my mistake. I'll fix my code then :)
--
Bastien Nocera <[email protected]>
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Bastien,
> > > > the problem is that the baseband is busy with the remote name request.
> > > > It has to page the remote device for getting the name and in that case
> > > > you simply can't run an inquiry. All currently available Bluetooth chips
> > > > have this limitation.
> > > >
> > > > Main question is why we have the remote name request just before you
> > > > wanna start the inquiry. What D-Bus methods are you actually calling in
> > > > what order? I think you constructed a use case that we never tested.
> > >
> > > The code is fairly straight forward. See:
> > > http://svn.gnome.org/viewcvs/nautilus-sendto/trunk/src/plugins/bluetooth.c?view=markup
> > >
> > > The code first does a ListRemoteDevices (to list all the known, visible,
> > > etc.) devices in add_known_devices_to_list(), and then runs an discovery
> > > using DiscoverDevices in start_device_scanning().
> > >
> > > Nothing mind blowing. I want to show all the known devices first (ie.
> > > the ones in the databases), and then add the devices
> > > visible/discoverable when the application is launched.
> > >
> > > Is ListRemoteDevices actually doing anything on the HCI? I was under the
> > > impression that it should only pull items from the disk...
> >
> > I almost guessed it. The ListRemoteDevices is not the problem the
> > GetRemoteName is the tricky part here. If the name is not in the cache
> > it tries to resolve it and this causes the baseband page which will
> > block the inquiry call.
>
> Shouldn't it return org.bluez.Error.InProgress instead in that case?
it is a different operation that is in progress.
> > You can wait for the completed RemoteNameUpdated or RemoteNameFailed
> > signals before actually starting the DiscoverDevices procedure. However
> > in case of devices out of range this might not be a good idea.
>
> The problem is that I don't know for which devices hcid will try to go
> and fetch the names for.
>
> Also, the doc for ListRemoteDevices should mention the fact that it
> might perform remote operations, as it's not really clear from the doc
> right now.
Actually ListRemoteDevices is not doing it. It happens when you call
GetRemoteName while you are adding it to your list.
Regards
Marcel
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On Wed, 2007-03-28 at 15:20 +0200, Marcel Holtmann wrote:
> Hi Bastien,
>
> > > the problem is that the baseband is busy with the remote name request.
> > > It has to page the remote device for getting the name and in that case
> > > you simply can't run an inquiry. All currently available Bluetooth chips
> > > have this limitation.
> > >
> > > Main question is why we have the remote name request just before you
> > > wanna start the inquiry. What D-Bus methods are you actually calling in
> > > what order? I think you constructed a use case that we never tested.
> >
> > The code is fairly straight forward. See:
> > http://svn.gnome.org/viewcvs/nautilus-sendto/trunk/src/plugins/bluetooth.c?view=markup
> >
> > The code first does a ListRemoteDevices (to list all the known, visible,
> > etc.) devices in add_known_devices_to_list(), and then runs an discovery
> > using DiscoverDevices in start_device_scanning().
> >
> > Nothing mind blowing. I want to show all the known devices first (ie.
> > the ones in the databases), and then add the devices
> > visible/discoverable when the application is launched.
> >
> > Is ListRemoteDevices actually doing anything on the HCI? I was under the
> > impression that it should only pull items from the disk...
>
> I almost guessed it. The ListRemoteDevices is not the problem the
> GetRemoteName is the tricky part here. If the name is not in the cache
> it tries to resolve it and this causes the baseband page which will
> block the inquiry call.
Shouldn't it return org.bluez.Error.InProgress instead in that case?
> You can wait for the completed RemoteNameUpdated or RemoteNameFailed
> signals before actually starting the DiscoverDevices procedure. However
> in case of devices out of range this might not be a good idea.
The problem is that I don't know for which devices hcid will try to go
and fetch the names for.
Also, the doc for ListRemoteDevices should mention the fact that it
might perform remote operations, as it's not really clear from the doc
right now.
> Let me discuss this through with the others. Feel free to hop onto
> #bluez at Freenode.
Cheers
--
Bastien Nocera <[email protected]>
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Marcel,
> > > > > HCI Event: Command Status (0x0f) plen 4
> > > > > Remote Name Request Cancel (0x01|0x001a) status
> 0x01 ncmd 1
> > > > > Error: Unknown HCI Command
> > > >
> > > > Looks like a BT1.1 dongle to me since Remote Name
> > > > Request Cancel was
> > > > introduced after that.
> > > > And since the device is not yet finished paging during
> > > > the remote name
> > > > request, it disallows the Inquiry Command.
> > > >
> > > > Solution: Get yourself a dongle > BT1.1 !
> > >
> > > actually it was the Create Connection Cancel that was
> > > introduced with
> > > Bluetooth 1.2. The Remote Name Request Cancel was always
> > > present, but it
> > > seems we have a chip that doesn't support it.
> > >
> > > Bastien, what does "hciconfig hci0 version" tells you?
> >
> > Same device, different machine (the dongle followed me to
> > the office):
> >
> > $ hciconfig hci0 version
> > hci0: Type: USB
> > BD Address: 00:08:F4:00:43:8D ACL MTU: 192:8 SCO MTU: 64:8
> > HCI Ver: 1.1 (0x1) HCI Rev: 0x20d LMP Ver: 1.1
> > (0x1) LMP Subver:
> > 0x20d
> > Manufacturer: Cambridge Silicon Radio (10)
> >
So, this confirms that it is indeed a BT1.1 device and hence does not
recognize the Remote Name Request Cancel command.
> > I hope there's at least some way to get it working. I'd
> > rather not have
> > to have another dongle just because hcid doesn't like it :)
>
> the problem is that the baseband is busy with the remote name request.
> It has to page the remote device for getting the name and in that case
> you simply can't run an inquiry. All currently available
> Bluetooth chips have this limitation.
>
> Main question is why we have the remote name request just before you
> wanna start the inquiry. What D-Bus methods are you actually calling
in
> what order? I think you constructed a use case that we never tested.
But actually, the sequence of HCI commands issued is correct. First, a
remote
name request is issued. Then, since an inquiry is required, the remote
name
request is cancelled. Thus, paging should stop and inquiry should be
possible.
I think this use case should work with BT1.2 devices and above.
But you are right, maybe some workaround should be present in order to
be
compatible with BT1.1 devices as well.
Best Regards,
Mayank
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
I am sure if this issue has been discussed before or
not.
Is it necessary to the set the struct sock->err value
to ECONNRESET when l2cap disconnect request is
received from remote device ?
l2cap_disconnect_req function sets the error value in
sock structure by calling l2cap_chan_del(sk,
ECONNRESET) every time l2cap connection is
disconnected.
This might lead to some loss of data at receiver side
in case of fast sender and slow receiver.
The sender will send l2cap packets and disconnects.
The receiver side will read the packets, but once
l2cap disconnect is received, even though there is
data in sk_buff, the bt_sock_recvmsg will return 0 as
skb_recv_datagram will return NULL.
Can we set the value to ECONNRESET only in case of
error condition and for the normal disconnect set it
to 0 by calling l2cap_chan_del(sk,0) from
l2cap_disconnect_req ?
So if error field is not set in sock structure,
bt_sock_recvmsg will return data bytes till sk_buff is
empty and which case 0 will be returned. This will
prevent any data loss.
Also if the user wants to know when socket
disconnected, POLLHUP will be set for sock fd so after
disconnect happens and there is data to be read both
POLLHUP and POLLIN will set.
If we set sock err field then user will not be able to
retrieve data from sk_buff, even if POLLLIN is set.
I am using 2.6 kernel.
Thanks,
Aarti.
> _______________________________________________
> Bluez-devel mailing list
> [email protected]
>
https://lists.sourceforge.net/lists/listinfo/bluez-devel
>
____________________________________________________________________________________
No need to miss a message. Get email on-the-go
with Yahoo! Mail for Mobile. Get started.
http://mobile.yahoo.com/mail
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Bastien,
> > the problem is that the baseband is busy with the remote name request.
> > It has to page the remote device for getting the name and in that case
> > you simply can't run an inquiry. All currently available Bluetooth chips
> > have this limitation.
> >
> > Main question is why we have the remote name request just before you
> > wanna start the inquiry. What D-Bus methods are you actually calling in
> > what order? I think you constructed a use case that we never tested.
>
> The code is fairly straight forward. See:
> http://svn.gnome.org/viewcvs/nautilus-sendto/trunk/src/plugins/bluetooth.c?view=markup
>
> The code first does a ListRemoteDevices (to list all the known, visible,
> etc.) devices in add_known_devices_to_list(), and then runs an discovery
> using DiscoverDevices in start_device_scanning().
>
> Nothing mind blowing. I want to show all the known devices first (ie.
> the ones in the databases), and then add the devices
> visible/discoverable when the application is launched.
>
> Is ListRemoteDevices actually doing anything on the HCI? I was under the
> impression that it should only pull items from the disk...
I almost guessed it. The ListRemoteDevices is not the problem the
GetRemoteName is the tricky part here. If the name is not in the cache
it tries to resolve it and this causes the baseband page which will
block the inquiry call.
You can wait for the completed RemoteNameUpdated or RemoteNameFailed
signals before actually starting the DiscoverDevices procedure. However
in case of devices out of range this might not be a good idea.
Let me discuss this through with the others. Feel free to hop onto
#bluez at Freenode.
Regards
Marcel
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hey Marcel,
On Wed, 2007-03-28 at 14:47 +0200, Marcel Holtmann wrote:
<snip>
> the problem is that the baseband is busy with the remote name request.
> It has to page the remote device for getting the name and in that case
> you simply can't run an inquiry. All currently available Bluetooth chips
> have this limitation.
>
> Main question is why we have the remote name request just before you
> wanna start the inquiry. What D-Bus methods are you actually calling in
> what order? I think you constructed a use case that we never tested.
The code is fairly straight forward. See:
http://svn.gnome.org/viewcvs/nautilus-sendto/trunk/src/plugins/bluetooth.c?view=markup
The code first does a ListRemoteDevices (to list all the known, visible,
etc.) devices in add_known_devices_to_list(), and then runs an discovery
using DiscoverDevices in start_device_scanning().
Nothing mind blowing. I want to show all the known devices first (ie.
the ones in the databases), and then add the devices
visible/discoverable when the application is launched.
Is ListRemoteDevices actually doing anything on the HCI? I was under the
impression that it should only pull items from the disk...
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Bastien,
> > > > HCI Event: Command Status (0x0f) plen 4
> > > > Remote Name Request Cancel (0x01|0x001a) status 0x01 ncmd 1
> > > > Error: Unknown HCI Command
> > >
> > > Looks like a BT1.1 dongle to me since Remote Name Request Cancel was
> > > introduced after that.
> > > And since the device is not yet finished paging during the remote name
> > > request, it disallows the Inquiry Command.
> > >
> > > Solution: Get yourself a dongle > BT1.1 !
> >
> > actually it was the Create Connection Cancel that was introduced with
> > Bluetooth 1.2. The Remote Name Request Cancel was always present, but it
> > seems we have a chip that doesn't support it.
> >
> > Bastien, what does "hciconfig hci0 version" tells you?
>
> Same device, different machine (the dongle followed me to the office):
>
> $ hciconfig hci0 version
> hci0: Type: USB
> BD Address: 00:08:F4:00:43:8D ACL MTU: 192:8 SCO MTU: 64:8
> HCI Ver: 1.1 (0x1) HCI Rev: 0x20d LMP Ver: 1.1 (0x1) LMP Subver:
> 0x20d
> Manufacturer: Cambridge Silicon Radio (10)
>
> I hope there's at least some way to get it working. I'd rather not have
> to have another dongle just because hcid doesn't like it :)
the problem is that the baseband is busy with the remote name request.
It has to page the remote device for getting the name and in that case
you simply can't run an inquiry. All currently available Bluetooth chips
have this limitation.
Main question is why we have the remote name request just before you
wanna start the inquiry. What D-Bus methods are you actually calling in
what order? I think you constructed a use case that we never tested.
Regards
Marcel
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On Wed, 2007-03-28 at 12:18 +0200, Marcel Holtmann wrote:
<snip>
> > > HCI Event: Command Status (0x0f) plen 4
> > > Remote Name Request Cancel (0x01|0x001a) status 0x01 ncmd 1
> > > Error: Unknown HCI Command
> >
> > Looks like a BT1.1 dongle to me since Remote Name Request Cancel was
> > introduced after that.
> > And since the device is not yet finished paging during the remote name
> > request, it disallows the Inquiry Command.
> >
> > Solution: Get yourself a dongle > BT1.1 !
>
> actually it was the Create Connection Cancel that was introduced with
> Bluetooth 1.2. The Remote Name Request Cancel was always present, but it
> seems we have a chip that doesn't support it.
>
> Bastien, what does "hciconfig hci0 version" tells you?
Same device, different machine (the dongle followed me to the office):
$ hciconfig hci0 version
hci0: Type: USB
BD Address: 00:08:F4:00:43:8D ACL MTU: 192:8 SCO MTU: 64:8
HCI Ver: 1.1 (0x1) HCI Rev: 0x20d LMP Ver: 1.1 (0x1) LMP Subver:
0x20d
Manufacturer: Cambridge Silicon Radio (10)
I hope there's at least some way to get it working. I'd rather not have
to have another dongle just because hcid doesn't like it :)
Cheers
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Mayank,
> > > > HCI Event: Command Status (0x0f) plen 4
> > > > Remote Name Request Cancel (0x01|0x001a) status 0x01 ncmd 1
> > > > Error: Unknown HCI Command
> > >
> > > Looks like a BT1.1 dongle to me since Remote Name Request Cancel was
> > > introduced after that.
> > > And since the device is not yet finished paging during the
> > remote name
> > > request, it disallows the Inquiry Command.
> > >
> > > Solution: Get yourself a dongle > BT1.1 !
> >
> > actually it was the Create Connection Cancel that was introduced with
> > Bluetooth 1.2. The Remote Name Request Cancel was always
> > present, but it
> > seems we have a chip that doesn't support it.
>
> You are right as well as wrong. Both Remote Name Request Cancel and
> Create Connection Cancel were introduced in BT1.2. Please check (I've
> done that already!).
I don't have the Bluetooth 1.1 specification at hand. I was pretty sure
that the Remote Name Request Cancel was always present since I only
added a dependency against Bluetooth 1.2 for the Create Connection
Cancel support I added to the kernel lately.
> And since this is not an optional command it is impossible to have a
> BT1.2 chip which doesn't support this command.
You wish. I have seen chips where the set of supported HCI commands is
limited. Remember there is no real HCI qualification.
Regards
Marcel
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Marcel,
> > > HCI Event: Command Status (0x0f) plen 4
> > > Remote Name Request Cancel (0x01|0x001a) status 0x01 ncmd 1
> > > Error: Unknown HCI Command
> >
> > Looks like a BT1.1 dongle to me since Remote Name Request Cancel was
> > introduced after that.
> > And since the device is not yet finished paging during the
> remote name
> > request, it disallows the Inquiry Command.
> >
> > Solution: Get yourself a dongle > BT1.1 !
>
> actually it was the Create Connection Cancel that was introduced with
> Bluetooth 1.2. The Remote Name Request Cancel was always
> present, but it
> seems we have a chip that doesn't support it.
You are right as well as wrong. Both Remote Name Request Cancel and
Create Connection Cancel were introduced in BT1.2. Please check (I've
done that already!).
And since this is not an optional command it is impossible to have a
BT1.2 chip which doesn't support this command.
Best Regards,
Mayank
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Mayank,
> > > > I've been wondering why my devices weren't showing up in
> > > > nautilus-sendto, and it looks like DiscoverDevices
> > doesn't work. Here's
> > > > the snippet of code:
> > > >
> > > > dbus_g_proxy_call (object, "DiscoverDevices", &e,
> > > > G_TYPE_INVALID, G_TYPE_INVALID);
> > > > if (e != NULL) {
> > > > g_warning ("Couldn't start discovery: %s: %s",
> > > > dbus_g_error_get_name (e), e->message);
> > > > g_error_free (e);
> > > > }
> > > >
> > > > I do a list ListBondings before that on the same object,
> > so I know that
> > > > it works. But I still get that error:
> > > > Couldn't start discovery: org.bluez.Error.Failed: Device
> > or resource busy
> > >
> > > please run "hcidump -X -V" to see what happens on the HCI
> > layer. Do you
> > > have running anything else at the same time.
> >
> > Nope, not doing anything else, apart from having the applet
> > running, let
> > me attach the hcidump output.
>
> [...]
>
> > HCI Event: Command Status (0x0f) plen 4
> > Remote Name Request Cancel (0x01|0x001a) status 0x01 ncmd 1
> > Error: Unknown HCI Command
>
> Looks like a BT1.1 dongle to me since Remote Name Request Cancel was
> introduced after that.
> And since the device is not yet finished paging during the remote name
> request, it disallows the Inquiry Command.
>
> Solution: Get yourself a dongle > BT1.1 !
actually it was the Create Connection Cancel that was introduced with
Bluetooth 1.2. The Remote Name Request Cancel was always present, but it
seems we have a chip that doesn't support it.
Bastien, what does "hciconfig hci0 version" tells you?
Regards
Marcel
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
> > > I've been wondering why my devices weren't showing up in
> > > nautilus-sendto, and it looks like DiscoverDevices
> doesn't work. Here's
> > > the snippet of code:
> > >
> > > dbus_g_proxy_call (object, "DiscoverDevices", &e,
> > > G_TYPE_INVALID, G_TYPE_INVALID);
> > > if (e != NULL) {
> > > g_warning ("Couldn't start discovery: %s: %s",
> > > dbus_g_error_get_name (e), e->message);
> > > g_error_free (e);
> > > }
> > >
> > > I do a list ListBondings before that on the same object,
> so I know that
> > > it works. But I still get that error:
> > > Couldn't start discovery: org.bluez.Error.Failed: Device
> or resource busy
> >
> > please run "hcidump -X -V" to see what happens on the HCI
> layer. Do you
> > have running anything else at the same time.
>
> Nope, not doing anything else, apart from having the applet
> running, let
> me attach the hcidump output.
[...]
> HCI Event: Command Status (0x0f) plen 4
> Remote Name Request Cancel (0x01|0x001a) status 0x01 ncmd 1
> Error: Unknown HCI Command
Looks like a BT1.1 dongle to me since Remote Name Request Cancel was
introduced after that.
And since the device is not yet finished paging during the remote name
request, it disallows the Inquiry Command.
Solution: Get yourself a dongle > BT1.1 !
Best Regards,
Mayank
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Bastien,
> I've been wondering why my devices weren't showing up in
> nautilus-sendto, and it looks like DiscoverDevices doesn't work. Here's
> the snippet of code:
>
> dbus_g_proxy_call (object, "DiscoverDevices", &e,
> G_TYPE_INVALID, G_TYPE_INVALID);
> if (e != NULL) {
> g_warning ("Couldn't start discovery: %s: %s",
> dbus_g_error_get_name (e), e->message);
> g_error_free (e);
> }
>
> I do a list ListBondings before that on the same object, so I know that
> it works. But I still get that error:
> Couldn't start discovery: org.bluez.Error.Failed: Device or resource busy
please run "hcidump -X -V" to see what happens on the HCI layer. Do you
have running anything else at the same time.
Regards
Marcel
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel