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
http://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. http://www.ostg.com
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
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. http://www.ostg.com
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
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" <[email protected]>
To: "Dave Dev" <[email protected]>
Copy (Cc): "BlueZ Mailing List" <[email protected]>
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
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. http://www.ostg.com
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
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 <[email protected]>
Sent by: [email protected]
08/05/2004 03:28 PM
Please respond to
Dave Dev <[email protected]>
To
[email protected]
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
http://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. http://www.ostg.com
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users