[Bluez-users] Multi-Thread Problem with BlueZ

[Bluez-users] Multi-Thread Problem with BlueZ

[Dave Dev]

Marcel:

Just dropping a line to say that BlueZ (seemingly) has the same problem=
 we had before -- we cannot connect two devices at once to the stack --=
 when BT is sending information (say, 10 - 100kb), we can't even discov=
er the device it's sending over .... Have you tested it with mutliple s=
ocket connections?

If you think it should work, have any ideas why it might not be working=
?  Don't think it's the Rococo stack ...

Best,

D.
____________________________________________________________
Letn=ED akce na televizory Panasonic! 150.000 prvni tyden
www.VIDEOEXPERT.cz
Vychutnejte si Olympi=E1du ve velk=E9m stylu!
http://ad.seznam.cz/clickthru?spotId=3D76186


-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com
_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

Re: [Bluez-users] Multi-Thread Problem with BlueZ

[scott.meesseman]

[-- Attachment #1: Type: text/plain, Size: 1727 bytes --]

Hello all,

Haven't quite followed this conversation and I dont have any suggestion 
per say, but I do have a multi-threaded application that uses BlueZ stack 
and I connect up to 3 sockets at the same time, so it definitely is 
possible...






Dave Dev <alwaysgone@seznam.cz> 
Sent by: bluez-users-admin@lists.sourceforge.net
08/05/2004 03:28 PM
Please respond to
Dave Dev <alwaysgone@seznam.cz>


To
bluez-users@lists.sourceforge.net
cc

Subject
[Bluez-users] Multi-Thread Problem with BlueZ






Marcel:

Just dropping a line to say that BlueZ (seemingly) has the same problem we 
had before -- we cannot connect two devices at once to the stack -- when 
BT is sending information (say, 10 - 100kb), we can't even discover the 
device it's sending over .... Have you tested it with mutliple socket 
connections?

If you think it should work, have any ideas why it might not be working? 
Don't think it's the Rococo stack ...

Best,

D.
____________________________________________________________
Letní akce na televizory Panasonic! 150.000 prvni tyden
www.VIDEOEXPERT.cz
Vychutnejte si Olympiádu ve velkém stylu!
http://ad.seznam.cz/clickthru?spotId=76186


-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com
_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users


[-- Attachment #2: Type: text/html, Size: 2786 bytes --]

Re: [Bluez-users] Multi-Thread Problem with BlueZ

[Marcel Holtmann]

Hi Dave,

> Just dropping a line to say that BlueZ (seemingly) has the same problem we had before -- we cannot connect two devices at once to the stack -- when BT is sending information (say, 10 - 100kb), we can't even discover the device it's sending over .... Have you tested it with mutliple socket connections?

I don't have any clue what you are talking about. Be more specific.

Regards

Marcel




-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com
_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

Re: [Bluez-users] Multi-Thread Problem with BlueZ

[Dave Dev]

Hey Marcel!

To refresh your memory:

We have a Server side Java application that utilizes Rococo's Bluetooth=
 stack to connect to the underlining Bluez stack.  This server has diff=
erent services that are used by clients side devices (at this time only=
 symbian phones- Nokia, Siemens, etc.).
 
The problem seems to appear when server/RFCOMMservice (SERVICE register=
ed as a service to SDPD.) is trying to send data ( size  more then  10k=
 ) to client1 and then another client -- client2 -- tries to connect to=
 it at the same time (while client1 is connected), all this using RFCOM=
M layer. (Note:  If only one phone is connected, it works perfectly)

When two phones try to connect at the same time, sometimes it completly=
 frezes or phone-client2 is not even able to --> discover <-- the Serve=
r while the Server is sending data to client1.  For both clients, I'm h=
andling them by using separates threads and just use the API from Rococ=
o to send data to the connected clients...
 
Not really sure how to test this and find out what the problem might be=
.  Rococo says they dont use anything else, they just call BlueZ layer =
-- and the last time we asked you, you said it works without problems. =
 But when i am not even able to discover the Server when it's busy, the=
n it cant be on the application layer nor Rococo. (USB hardware?  We ha=
ve tried many different ones!)
 
We were previously trying to solve this before, but have been unlucky t=
hus far.  By using hcidump we found that the Server doesnt act like a m=
aster as it should, but it switches between slave and master modes. And=
 Symbian phones don't want to switch themself into slave while they're =
connected to the Server. So when sending data to a phone, during that t=
ime those two device switch between master and slave, fighing who will =
be master.
 
Bluez is set up as follow :
 
device {
        # Local device name
        #   %d - device id
        #   %h - host name
        name "Jellingspot";

        # Local device class
        class 0x100;

        # Default packet type
        pkt_type DM5;  *****************  We have tried all packet type=
s, others just crash -- this is the most stable one...

        # Inquiry and Page scan
        iscan enable; pscan enable;

        # Default link mode
        #   none   - no specific policy 
        #   accept - always accept incoming connections
        #   master - become master on incoming connections,
        #            deny role switch on outgoing connections
        #
        #lm accept,master;
        #
        lm accept;          ************** CANT do master otherwise it =
wont work with symbian phones..

        # Default link policy
        #   none    - no specific policy
        #   rswitch - allow role switch
        #   hold    - allow hold mode
        #   sniff   - allow sniff mode
        #   park    - allow park mode
        #
        #lp hold,sniff;
        #
        lp hold,sniff,park;

        # Authentication and Encryption
        #auth enable;
        #encrypt enable;

 
Does that help?





=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Original message =3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
From: "Marcel Holtmann" <marcel@holtmann.org>
To: "Dave Dev" <alwaysgone@seznam.cz>
Copy (Cc): "BlueZ Mailing List" <bluez-users@lists.sourceforge.net>
Subject: Re: [Bluez-users] Multi-Thread Problem with BlueZ
Date: 5. 8. 2004 22:40
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D

< Hi Dave,
< 
< > Just dropping a line to say that BlueZ (seemingly) has the same pro=
blem we had before -- we cannot connect two devices at once to the stac=
k -- when BT is sending information (say, 10 - 100kb), we can't even di=
scover the device it's sending over .... Have you tested it with mutlip=
le socket connections?
< 
< I don't have any clue what you are talking about. Be more specific.
< 
< Regards
< 
< Marcel
< 
< 

____________________________________________________________
Anonymn=ED p=F8ipojen=ED k internetu od Seznamu
http://ad.seznam.cz/clickthru?spotId=3D74638

Re: [Bluez-users] Multi-Thread Problem with BlueZ

[Marcel Holtmann]

Hi Dave,

> To refresh your memory:

sorry for that ;)

> We have a Server side Java application that utilizes Rococo's Bluetooth stack to connect to the underlining Bluez stack.  This server has different services that are used by clients side devices (at this time only symbian phones- Nokia, Siemens, etc.).
>  
> The problem seems to appear when server/RFCOMMservice (SERVICE registered as a service to SDPD.) is trying to send data ( size  more then  10k ) to client1 and then another client -- client2 -- tries to connect to it at the same time (while client1 is connected), all this using RFCOMM layer. (Note:  If only one phone is connected, it works perfectly)
> 
> When two phones try to connect at the same time, sometimes it completly frezes or phone-client2 is not even able to --> discover <-- the Server while the Server is sending data to client1.  For both clients, I'm handling them by using separates threads and just use the API from Rococo to send data to the connected clients...
>  
> Not really sure how to test this and find out what the problem might be.  Rococo says they dont use anything else, they just call BlueZ layer -- and the last time we asked you, you said it works without problems.  But when i am not even able to discover the Server when it's busy, then it cant be on the application layer nor Rococo. (USB hardware?  We have tried many different ones!)
>  
> We were previously trying to solve this before, but have been unlucky thus far.  By using hcidump we found that the Server doesnt act like a master as it should, but it switches between slave and master modes. And Symbian phones don't want to switch themself into slave while they're connected to the Server. So when sending data to a phone, during that time those two device switch between master and slave, fighing who will be master.
>  
> Bluez is set up as follow :
>  
> device {
>         # Local device name
>         #   %d - device id
>         #   %h - host name
>         name "Jellingspot";
> 
>         # Local device class
>         class 0x100;
> 
>         # Default packet type
>         pkt_type DM5;  *****************  We have tried all packet types, others just crash -- this is the most stable one...

Please don't do this, because the link manager must be able to choose
the best packet type and so enabling every packet type should be fine.

>         # Default link mode
>         #   none   - no specific policy 
>         #   accept - always accept incoming connections
>         #   master - become master on incoming connections,
>         #            deny role switch on outgoing connections
>         #
>         #lm accept,master;
>         #
>         lm accept;          ************** CANT do master otherwise it wont work with symbian phones..

If you don't enable rswitch below, the master setting can't work.

>         # Default link policy
>         #   none    - no specific policy
>         #   rswitch - allow role switch
>         #   hold    - allow hold mode
>         #   sniff   - allow sniff mode
>         #   park    - allow park mode
>         #
>         #lp hold,sniff;
>         #
>         lp hold,sniff,park;

Why don't you activate the rswitch option to allow the role switch?

What kind of USB Bluetooth dongles did you tried? Actually a CSR based
with at least HCI 16.4 or HCI 16.14 firmware should work fine. This is
not about the RFCOMM connections. This is about the ACL links and the
problems with scatternets. Check with "hcitool info" the features of
your mobile phones. If they don't support hold or rswitch that can be of
course troubles.

Regards

Marcel




-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com
_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

Re: [Bluez-users] Multi-Thread Problem with BlueZ

[Marcel Holtmann]

Hi Dave,

> < What kind of USB Bluetooth dongles did you tried? Actually a CSR based
> < with at least HCI 16.4 or HCI 16.14 firmware should work fine. This is
> < not about the RFCOMM connections. This is about the ACL links and the
> < problems with scatternets. Check with "hcitool info" the features of
> < your mobile phones. If they don't support hold or rswitch that can be of
> < course troubles.
> 
> We used first the TDK USB BT -- upgraded firmware to 16.4 ... things improved, but still didn't work.  Now have one of those i-tecs that we sent to you and some older Epox -- I guess we need to get some new TDKs (they're deployed in a live environment now) ... any other USB devices work well and let you upgrade firmware?  Most other USB dongles suck....

I can't think of any disadvantage with the BlueCore01b based TDK dongle,
but maybe there are some. The Anycom USB-100 is BC02 based and there
exists an update to HCI 16.14. I haven't checked the differences between
these two firmware version, but as I know they are the only two official
releases from the HCI 16.x branch.

The Broadcom based dongles were always problematic if it comes to
scatternet and role switch support. Don't even try to get there any
further unless you have a protocol analyser at hand and a good contact
to Broadcom.

The D-Link DBT-120 Rev. B3 can be updated with the firmware file from
Apple to HCI 18.1 which then is also Bluetooth 1.2 capable. However I
think the latest official firmware release from CSR is HCI 18.2, but
actually I haven't seen any dongles so far.

> Will let you know the results ... thanks -- if we can get this working on your advice, you'll get some Czech beer ;-)

:)

Regards

Marcel




-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com
_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users