I am using bluez-libs-2.25 on 2.6.11-mh2 to develop BlueZ support for
a multithreaded process. My BlueZ contribution opens a non-blocking
RFCOMM socket in one thread, and blocking SDP query in another. So
far, I have RFCOMM support working, and I have also integrated
Bluetooth inquiry and SDP queries.
When I set RFCOMM to nonblocking, the sdp_connect returns an error,
with errno set to EALREADY. Why does one thread affect the other?
This same SDP query worked fine before I change the RFCOMM to nonblocking.
I can provide hcidump or source code if needed.
Thanks,
Jeff
-------------------------------------------------------------------------
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-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
No, I'm not directly creating HCI connections. I use
socket(...,BTPROTO_RFCOMM) and then use that fd with read()/write()
On a hunch, I rebuilt my bluez-lib from the 2.25 tgz, re-installed,
then restarted hcid, sdpd, etc. I can now use sdptool without error.
I guess libbluetooth got corrupted by a power-interruption reset?
Thanks for the feedback. Sorry for the noise.
Best regards,
Jeff
On 8/3/06, Marcel Holtmann <[email protected]> wrote:
> Hi Jeff,
>
> > Never mind on the example program, no need to create one, I can
> > reproduce the problem with sdptool v2.25:
> >
> > `sdptool browse <remote-addr>`
> >
> > Failed to connect to SDP server on <remote-addr>: Operation already in progress
> >
> > local hcidump -X -V
> >
> > HCI sniffer - Bluetooth packet analyzer ver 1.30
> > device: hci0 snap_len: 1028 filter: 0xffffffff
> > < HCI Command: Create Connection (0x01|0x0005) plen 13
> > bdaddr remote-addr ptype 0xcc18 rswitch 0x01 clkoffset 0x0000
> > Packet type: DM1 DM3 DM5 DH1 DH3 DH5
> > > HCI Event: Command Status (0x0f) plen 4
> > Create Connection (0x01|0x0005) status 0x0b ncmd 1
> > Error: ACL Connection Already Exists
>
> can you test it with latest 2.6.17-mh5 kernel?
>
> This error indicates that an ACL already exists. Are you playing with
> HCI connection creation from userspace? If you do so, then don't.
>
> 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-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/bluez-users
>
-------------------------------------------------------------------------
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-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
Hi Jeff,
> Never mind on the example program, no need to create one, I can
> reproduce the problem with sdptool v2.25:
>
> `sdptool browse <remote-addr>`
>
> Failed to connect to SDP server on <remote-addr>: Operation already in progress
>
> local hcidump -X -V
>
> HCI sniffer - Bluetooth packet analyzer ver 1.30
> device: hci0 snap_len: 1028 filter: 0xffffffff
> < HCI Command: Create Connection (0x01|0x0005) plen 13
> bdaddr remote-addr ptype 0xcc18 rswitch 0x01 clkoffset 0x0000
> Packet type: DM1 DM3 DM5 DH1 DH3 DH5
> > HCI Event: Command Status (0x0f) plen 4
> Create Connection (0x01|0x0005) status 0x0b ncmd 1
> Error: ACL Connection Already Exists
can you test it with latest 2.6.17-mh5 kernel?
This error indicates that an ACL already exists. Are you playing with
HCI connection creation from userspace? If you do so, then don't.
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-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
Never mind on the example program, no need to create one, I can
reproduce the problem with sdptool v2.25:
`sdptool browse <remote-addr>`
Failed to connect to SDP server on <remote-addr>: Operation already in progress
local hcidump -X -V
HCI sniffer - Bluetooth packet analyzer ver 1.30
device: hci0 snap_len: 1028 filter: 0xffffffff
< HCI Command: Create Connection (0x01|0x0005) plen 13
bdaddr remote-addr ptype 0xcc18 rswitch 0x01 clkoffset 0x0000
Packet type: DM1 DM3 DM5 DH1 DH3 DH5
> HCI Event: Command Status (0x0f) plen 4
Create Connection (0x01|0x0005) status 0x0b ncmd 1
Error: ACL Connection Already Exists
remote hcidump -X -V
(nothing)
Any ideas? I have rebooted the client since this started up. Thanks
for your time.
Regards,
Jeff
On 8/3/06, Jeff Wilson <[email protected]> wrote:
> I will put together an example and post it in the next day or two. As
> to "why nonblocking?" it's to service multiple sockets with a single
> thread (event-based approach).
>
> Thanks,
> Jeff
>
> On 8/3/06, Marcel Holtmann <[email protected]> wrote:
> > Hi Jeff,
> >
> > > I am using bluez-libs-2.25 on 2.6.11-mh2 to develop BlueZ support for
> > > a multithreaded process. My BlueZ contribution opens a non-blocking
> > > RFCOMM socket in one thread, and blocking SDP query in another. So
> > > far, I have RFCOMM support working, and I have also integrated
> > > Bluetooth inquiry and SDP queries.
> > >
> > > When I set RFCOMM to nonblocking, the sdp_connect returns an error,
> > > with errno set to EALREADY. Why does one thread affect the other?
> > >
> > > This same SDP query worked fine before I change the RFCOMM to nonblocking.
> >
> > can you provide a simple test program for this? It sounds like a strange
> > bug with threading. However why do you need a non-blocking socket when
> > you are using threading?
> >
> > 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-users mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/bluez-users
> >
>
-------------------------------------------------------------------------
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-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
I will put together an example and post it in the next day or two. As
to "why nonblocking?" it's to service multiple sockets with a single
thread (event-based approach).
Thanks,
Jeff
On 8/3/06, Marcel Holtmann <[email protected]> wrote:
> Hi Jeff,
>
> > I am using bluez-libs-2.25 on 2.6.11-mh2 to develop BlueZ support for
> > a multithreaded process. My BlueZ contribution opens a non-blocking
> > RFCOMM socket in one thread, and blocking SDP query in another. So
> > far, I have RFCOMM support working, and I have also integrated
> > Bluetooth inquiry and SDP queries.
> >
> > When I set RFCOMM to nonblocking, the sdp_connect returns an error,
> > with errno set to EALREADY. Why does one thread affect the other?
> >
> > This same SDP query worked fine before I change the RFCOMM to nonblocking.
>
> can you provide a simple test program for this? It sounds like a strange
> bug with threading. However why do you need a non-blocking socket when
> you are using threading?
>
> 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-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/bluez-users
>
-------------------------------------------------------------------------
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-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
Hi Jeff,
> I am using bluez-libs-2.25 on 2.6.11-mh2 to develop BlueZ support for
> a multithreaded process. My BlueZ contribution opens a non-blocking
> RFCOMM socket in one thread, and blocking SDP query in another. So
> far, I have RFCOMM support working, and I have also integrated
> Bluetooth inquiry and SDP queries.
>
> When I set RFCOMM to nonblocking, the sdp_connect returns an error,
> with errno set to EALREADY. Why does one thread affect the other?
>
> This same SDP query worked fine before I change the RFCOMM to nonblocking.
can you provide a simple test program for this? It sounds like a strange
bug with threading. However why do you need a non-blocking socket when
you are using threading?
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-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users