[Bluez-users] problem in making multiple connections using single bluetooth adapter using bluez

[Bluez-users] problem in making multiple connections using single bluetooth adapter using bluez

[siddhant tewari]

[-- Attachment #1.1: Type: text/plain, Size: 815 bytes --]

hi,
    I am trying to open multiple connections by connecting to OBEX push
servers on different mobiles using single blue tooth adapter. The steps that
i am taking right now are as follows:-

i) Detecting bluetooth devices.
ii) Sending data to any detected device through a different process (i do a
fork in the main program). This new process first sets up  a RFCOMM channel
to the devices OBEX push server and then sends data to it through using open
obex API.

But the above scheme  is not working correctly. Can someone tell me the
mistake i am making and how should i correct it. Please help me as i find
my  self quite clueless abt to how to proceed now. Also it would be great
help if anyone can even give me a direction in which i should proceed now.

Eagerly waiting for reply.Thanks in advance.

bye bye

[-- Attachment #1.2: Type: text/html, Size: 882 bytes --]

[-- Attachment #2: Type: text/plain, Size: 347 bytes --]

-------------------------------------------------------------------------
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

[-- Attachment #3: Type: text/plain, Size: 164 bytes --]

_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

Re: [Bluez-users] problem in making multiple connections using single bluetooth adapter using bluez

[Marcel Holtmann]

Hi,

>     I am trying to open multiple connections by connecting to OBEX
> push servers on different mobiles using single blue tooth adapter. The
> steps that i am taking right now are as follows:-
> 
> i) Detecting bluetooth devices. 
> ii) Sending data to any detected device through a different process (i
> do a fork in the main program). This new process first sets up  a
> RFCOMM channel to the devices OBEX push server and then sends data to
> it through using open obex API. 
> 
> But the above scheme  is not working correctly. Can someone tell me
> the mistake i am making and how should i correct it. Please help me as
> i find my  self quite clueless abt to how to proceed now. Also it
> would be great help if anyone can even give me a direction in which i
> should proceed now. 

you should start using "hcidump -X -V" as root to see what actually
happens. And without seeing the code, we can't tell you anything.

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
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

Re: [Bluez-users] problem in making multiple connections using single bluetooth adapter using bluez

[siddhant tewari]

[-- Attachment #1.1: Type: text/plain, Size: 1933 bytes --]

hi,
   Honest thanks to u for ur reply. Just a small question:
    what i am trying is technically possible???
    I dont have any problem in sending the code but it would be great pain
for others to understand my code and some effort for me as well in making it
more understandable for others.

  Again thanking u for the advise.

regards
siddhant

On 1/2/07, Marcel Holtmann <marcel@holtmann.org> wrote:
>
> Hi,
>
> >     I am trying to open multiple connections by connecting to OBEX
> > push servers on different mobiles using single blue tooth adapter. The
> > steps that i am taking right now are as follows:-
> >
> > i) Detecting bluetooth devices.
> > ii) Sending data to any detected device through a different process (i
> > do a fork in the main program). This new process first sets up  a
> > RFCOMM channel to the devices OBEX push server and then sends data to
> > it through using open obex API.
> >
> > But the above scheme  is not working correctly. Can someone tell me
> > the mistake i am making and how should i correct it. Please help me as
> > i find my  self quite clueless abt to how to proceed now. Also it
> > would be great help if anyone can even give me a direction in which i
> > should proceed now.
>
> you should start using "hcidump -X -V" as root to see what actually
> happens. And without seeing the code, we can't tell you anything.
>
> 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
> Bluez-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bluez-users
>

[-- Attachment #1.2: Type: text/html, Size: 2675 bytes --]

[-- Attachment #2: Type: text/plain, Size: 347 bytes --]

-------------------------------------------------------------------------
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

[-- Attachment #3: Type: text/plain, Size: 164 bytes --]

_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

Re: [Bluez-users] problem in making multiple connections using single bluetooth adapter using bluez

[Marcel Holtmann]

Hi,

>    Honest thanks to u for ur reply. Just a small question:
>     what i am trying is technically possible???

start with "hcidump -X -V" and look out for any error messages from the
HCI layer.

>     I dont have any problem in sending the code but it would be great
> pain for others to understand my code and some effort for me as well
> in making it more understandable for others. 

That is your choice, but without the code it is kinda hard to actually
fully understand what you are trying to achieve and how.

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
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

Re: [Bluez-users] problem in making multiple connections using single bluetooth adapter using bluez

[siddhant tewari]

[-- Attachment #1.1: Type: text/plain, Size: 1271 bytes --]

hi,
   I will try my best and in case i am not able move anything i will post
the code.

thanks
siddhant

On 1/2/07, Marcel Holtmann <marcel@holtmann.org> wrote:
>
> Hi,
>
> >    Honest thanks to u for ur reply. Just a small question:
> >     what i am trying is technically possible???
>
> start with "hcidump -X -V" and look out for any error messages from the
> HCI layer.
>
> >     I dont have any problem in sending the code but it would be great
> > pain for others to understand my code and some effort for me as well
> > in making it more understandable for others.
>
> That is your choice, but without the code it is kinda hard to actually
> fully understand what you are trying to achieve and how.
>
> 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
> Bluez-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bluez-users
>

[-- Attachment #1.2: Type: text/html, Size: 1935 bytes --]

[-- Attachment #2: Type: text/plain, Size: 347 bytes --]

-------------------------------------------------------------------------
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

[-- Attachment #3: Type: text/plain, Size: 164 bytes --]

_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

Re: [Bluez-users] problem in making multiple connections using single bluetooth adapter using bluez

[Cris]

On Tue, 2 Jan 2007 13:46:08 +0530
"siddhant tewari" <siddhant.tewari@gmail.com> wrote:

> hi,
>    Honest thanks to u for ur reply. Just a small question:
>     what i am trying is technically possible???
>     I dont have any problem in sending the code but it would be great pain
> for others to understand my code and some effort for me as well in making it
> more understandable for others.

Hi Siddhant,

If the question, whether it is technically possible, refers to the
specifications of bluetooth, the answer is yes. Being a master (i.e.,
the device initiating the connections) you can connect to up to 7
other different bluetooth devices. But if the question refers to
BlueZ, I can't tell you for sure. A few months ago I tested this and
it failed not too gracefully. This is one of the reasons why I don't
use libbluetooth anymore.

However, there is a simple way to test it. Obex push and obex ftp are
different profiles, but technically they use exactly the same methods
(hci, l2cap, rfcomm, obex). Thus if one works, the other will work as
well and vice verse. But the usage of obex ftp is much easier. Obex
ftp uses BlueZ to set up a connection the `BlueZ' way. If you prepare
two sessions of obex ftp to different peers but with the same file,
and launch them as fast as you can at the same time, they must arrive
approximately at the time. Just make sure that the peers have similar
hardware and transmission conditions. In any case, obexftp does show
you activity, which must be visible for both at the same time. If one
is waiting until the other is done, you've still got the original, sad
blues behaviour. As there is no bit of code you wrote to do so, there
is also no bit of a chance that you committed any error. So, there is
no need to publish your code.

I'd be curious to know the result.

-------------------------------------------------------------------------
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
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

Re: [Bluez-users] problem in making multiple connections using single bluetooth adapter using bluez

[siddhant tewari]

[-- Attachment #1.1: Type: text/plain, Size: 3236 bytes --]

hi cris,
           I tried similar thing using OBEX push client and the thing that
happened is exactly what u apprehended ...
    ->  One thread waited for the other to get completed .... sad blues
behavior.....this is exactly what is creating trouble in my application ...
i will be doing more r n d based on ur suggestion and will definitely  mail
the results ... really nice to see someone taking interest in the problem
..... also can u tell me what part of the bluez code i should look for to
make such thing supported or what do u think where the problem can be (any
intutive insight will be helpful as i am just a starter) ... i am ready to
put lot of efforts to solve this problem if its possible for me to do so ...
thanks for the reply

regards
siddhant

On 1/2/07, Cris <ml133@netpole.com.br> wrote:
>
> On Tue, 2 Jan 2007 13:46:08 +0530
> "siddhant tewari" <siddhant.tewari@gmail.com> wrote:
>
> > hi,
> >    Honest thanks to u for ur reply. Just a small question:
> >     what i am trying is technically possible???
> >     I dont have any problem in sending the code but it would be great
> pain
> > for others to understand my code and some effort for me as well in
> making it
> > more understandable for others.
>
> Hi Siddhant,
>
> If the question, whether it is technically possible, refers to the
> specifications of bluetooth, the answer is yes. Being a master (i.e.,
> the device initiating the connections) you can connect to up to 7
> other different bluetooth devices. But if the question refers to
> BlueZ, I can't tell you for sure. A few months ago I tested this and
> it failed not too gracefully. This is one of the reasons why I don't
> use libbluetooth anymore.
>
> However, there is a simple way to test it. Obex push and obex ftp are
> different profiles, but technically they use exactly the same methods
> (hci, l2cap, rfcomm, obex). Thus if one works, the other will work as
> well and vice verse. But the usage of obex ftp is much easier. Obex
> ftp uses BlueZ to set up a connection the `BlueZ' way. If you prepare
> two sessions of obex ftp to different peers but with the same file,
> and launch them as fast as you can at the same time, they must arrive
> approximately at the time. Just make sure that the peers have similar
> hardware and transmission conditions. In any case, obexftp does show
> you activity, which must be visible for both at the same time. If one
> is waiting until the other is done, you've still got the original, sad
> blues behaviour. As there is no bit of code you wrote to do so, there
> is also no bit of a chance that you committed any error. So, there is
> no need to publish your code.
>
> I'd be curious to know the result.
>
> -------------------------------------------------------------------------
> 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
> Bluez-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bluez-users
>

[-- Attachment #1.2: Type: text/html, Size: 4064 bytes --]

[-- Attachment #2: Type: text/plain, Size: 347 bytes --]

-------------------------------------------------------------------------
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

[-- Attachment #3: Type: text/plain, Size: 164 bytes --]

_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

Re: [Bluez-users] problem in making multiple connections using single bluetooth adapter using bluez

[Cris]

On Tue, 2 Jan 2007 15:59:19 +0530
"siddhant tewari" <siddhant.tewari@gmail.com> wrote:

> hi cris,
>            I tried similar thing using OBEX push client and the thing that
> happened is exactly what u apprehended ...
>     ->  One thread waited for the other to get completed .... sad blues
> behavior.....this is exactly what is creating trouble in my application ...

Obviously, BlueZ didn't learn to deal with more than one connection at
the same time yet. They are still thinking that everybody has a
desktop computer with KDE (or Windows, as dbus being a derivate from
gtk, is specially designed to be platform independent) and just a
single cellphone or PDA at home. Of course, large companies like Nokia
are not really affected by these problems, as a cellphone is so small
that it can't deal with much more than one thing at the same time
anyway. But this may change in some future.

So your only choice is to not use libbluetooth. Marcel is right when
he says that this implies a lot of work, as you will have to implement
each protocol layer yourself. But as these are quite badly designed in
BlueZ, there is really no fix for it. If the BlueZ developers had a
different way of dealing with users (just look at their answers) the
many thousands of hours of work we are doing each one on his own could
go into this project. So, we are alone here. Your choices like mine or
anybody else's who is trying to serious work with bluetooth, is either
to give up or to do the work.

But be aware, that re-writing the protocol stack may not be
enough. I've done so and am having bad troubles because BlueZ
developers think that an exclusive usage over a socket can be
implemented by the concept of a raw socket. This is not true. Even
using raw sockets the kernel will interfere in your programming,
meaning that it is quite possible that we will have to replace also
the kernel modules, which would make 100% of BlueZ code unusable. Not
regulating mutually interfering accesses to one and the same ressource
is pure Windows philosophy, where each program, starting with
kernel.dll thinks it owns the complete device. Raw sockets allow to do
low leve things, but they don't guarantee that someone else wont undo
what ever my program has done a second earlier. Even if this someone
else is the kernel herself.

I've suggested the use of an exclusive flag with the HCI sockets, when
Marcel answered, that the kernel does NOT interfere when I open that
socket in raw. This is just not true. Marcel (who should know as he
wrote this monster) asked what exactly happens. Here it is:

If your program is already active and you plug in an USB bluetooth
dongle, the kernel issues several informational queries to the
device. It needs to do so, as a raw socket doesn't imply that there
couldn't be more than one processes accessing the same device (there
is no exclusivity), while a second process might want to use a cooked
socket. In my case, I know that there will be no other process,
specially not hcid or dbus, but the kernel doesn't, and still issues
these commands. Thus, I need to expect anything to happen, just for
the USB dongle having been plugged in. This raises the level of
complexity of my program by a power of magnitud. Also, Marcel himself
said, that whenever a major version number is increased, we can not
trust that the behaviour wont change incompatibly with the previous
version (besides the use of dbus and apparently the inability to
multitask). Did anybody see any reasoning why dbus is defended so
stiff neckedly? Or why nobody cares to work on a design which actually
matches what bluetooth specifications persue?

Much worse is what happens if you create a connection. Until you get
the connection complete event, everything is fine. But then, the
kernel will issue several commands, ignoring any commands of yours
until it's done. Among those is HCI_Write_Link_Policy_Settings. At
this point it seems to be impossible to achieve for instance a role
switch. Also, the kernel has no way to know what my program is trying
to do, and thus can not know which is the link policy I need.

You see, everybody doing things like you and me (and I've seen more
than just a few more out there) is just out of luck. The best would be
somebody starting to fork the full development of Bluetooth support in
Linux, but this time with a well thought design based on a thorough
understanding of bluetooth and it's protocols.

-------------------------------------------------------------------------
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
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

Re: [Bluez-users] problem in making multiple connections using single bluetooth adapter using bluez

[siddhant tewari]

[-- Attachment #1.1: Type: text/plain, Size: 6116 bytes --]

hi Cris,

    With linux being one of the major players in embedded domain and bluez
being an official protocol of linux there is definitely a great need for
multi connection support. You have suggested that somebody with a thorough
understanding of bluetooth and its protocol should start to fork the full
development of bluetooth support in linux , but that somebody cannot be at
least me at this instance as i am just a starter and it took some effort
from my side to even get the idea of what u wrote ... i think it should be
someone like you who has such a clear picture of the problem or to be more
precise really understands the problem well , who can initiate such
development... all i can say is that i am ready to work if somebody  can
guide me ....

Please tell me what are the other options parallel to bluez and is it really
advisable to  use them .

I am stuck at this problem and i dont like leaving it as such.

regards
siddhant

On 1/2
 /07, Cris <ml133@netpole.com.br> wrote:
>
> On Tue, 2 Jan 2007 15:59:19 +0530
> "siddhant tewari" <siddhant.tewari@gmail.com> wrote:
>
> > hi cris,
> >            I tried similar thing using OBEX push client and the thing
> that
> > happened is exactly what u apprehended ...
> >     ->  One thread waited for the other to get completed .... sad blues
> > behavior.....this is exactly what is creating trouble in my application
> ...
>
> Obviously, BlueZ didn't learn to deal with more than one connection at
> the same time yet. They are still thinking that everybody has a
> desktop computer with KDE (or Windows, as dbus being a derivate from
> gtk, is specially designed to be platform independent) and just a
> single cellphone or PDA at home. Of course, large companies like Nokia
> are not really affected by these problems, as a cellphone is so small
> that it can't deal with much more than one thing at the same time
> anyway. But this may change in some future.
>
> So your only choice is to not use libbluetooth. Marcel is right when
> he says that this implies a lot of work, as you will have to implement
> each protocol layer yourself. But as these are quite badly designed in
> BlueZ, there is really no fix for it. If the BlueZ developers had a
> different way of dealing with users (just look at their answers) the
> many thousands of hours of work we are doing each one on his own could
> go into this project. So, we are alone here. Your choices like mine or
> anybody else's who is trying to serious work with bluetooth, is either
> to give up or to do the work.
>
> But be aware, that re-writing the protocol stack may not be
> enough. I've done so and am having bad troubles because BlueZ
> developers think that an exclusive usage over a socket can be
> implemented by the concept of a raw socket. This is not true. Even
> using raw sockets the kernel will interfere in your programming,
> meaning that it is quite possible that we will have to replace also
> the kernel modules, which would make 100% of BlueZ code unusable. Not
> regulating mutually interfering accesses to one and the same ressource
> is pure Windows philosophy, where each program, starting with
> kernel.dll thinks it owns the complete device. Raw sockets allow to do
> low leve things, but they don't guarantee that someone else wont undo
> what ever my program has done a second earlier. Even if this someone
> else is the kernel herself.
>
> I've suggested the use of an exclusive flag with the HCI sockets, when
> Marcel answered, that the kernel does NOT interfere when I open that
> socket in raw. This is just not true. Marcel (who should know as he
> wrote this monster) asked what exactly happens. Here it is:
>
> If your program is already active and you plug in an USB bluetooth
> dongle, the kernel issues several informational queries to the
> device. It needs to do so, as a raw socket doesn't imply that there
> couldn't be more than one processes accessing the same device (there
> is no exclusivity), while a second process might want to use a cooked
> socket. In my case, I know that there will be no other process,
> specially not hcid or dbus, but the kernel doesn't, and still issues
> these commands. Thus, I need to expect anything to happen, just for
> the USB dongle having been plugged in. This raises the level of
> complexity of my program by a power of magnitud. Also, Marcel himself
> said, that whenever a major version number is increased, we can not
> trust that the behaviour wont change incompatibly with the previous
> version (besides the use of dbus and apparently the inability to
> multitask). Did anybody see any reasoning why dbus is defended so
> stiff neckedly? Or why nobody cares to work on a design which actually
> matches what bluetooth specifications persue?
>
> Much worse is what happens if you create a connection. Until you get
> the connection complete event, everything is fine. But then, the
> kernel will issue several commands, ignoring any commands of yours
> until it's done. Among those is HCI_Write_Link_Policy_Settings. At
> this point it seems to be impossible to achieve for instance a role
> switch. Also, the kernel has no way to know what my program is trying
> to do, and thus can not know which is the link policy I need.
>
> You see, everybody doing things like you and me (and I've seen more
> than just a few more out there) is just out of luck. The best would be
> somebody starting to fork the full development of Bluetooth support in
> Linux, but this time with a well thought design based on a thorough
> understanding of bluetooth and it's protocols.
>
> -------------------------------------------------------------------------
> 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
> Bluez-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bluez-users
>

[-- Attachment #1.2: Type: text/html, Size: 7024 bytes --]

[-- Attachment #2: Type: text/plain, Size: 347 bytes --]

-------------------------------------------------------------------------
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

[-- Attachment #3: Type: text/plain, Size: 164 bytes --]

_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

Re: [Bluez-users] problem in making multiple connections using single bluetooth adapter using bluez

[Marcel Holtmann]

Hi,

>     With linux being one of the major players in embedded domain and
> bluez being an official protocol of linux there is definitely a great
> need for multi connection support. You have suggested that somebody
> with a thorough understanding of bluetooth and its protocol should
> start to fork the full development of bluetooth support in linux , but
> that somebody cannot be at least me at this instance as i am just a
> starter and it took some effort from my side to even get the idea of
> what u wrote ... i think it should be someone like you who has such a
> clear picture of the problem or to be more precise really understands
> the problem well , who can initiate such development... all i can say
> is that i am ready to work if somebody  can guide me .... 

please don't blindly believe everything that is posted on the mailing
list. You don't even have to believe me. BlueZ is fully multi adapter
and multi connection capable. However you need also a chip that supports
it and in some cases even a host stack on the other side that works
correctly. And once again "hcidump -X -V" is your friend in showing what
actually happens on the Bluetooth chip level.

> Please tell me what are the other options parallel to bluez and is it
> really advisable to  use them .

There is no real alternative, but please be my guest and write something
new. At some point you will realize that developing a Bluetooth host
stack is not much fun anymore.

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
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

Re: [Bluez-users] problem in making multiple connections using single bluetooth adapter using bluez

[Paul Gardiner]

Marcel Holtmann wrote:
> And once again "hcidump -X -V" is your friend in showing what
> actually happens on the Bluetooth chip level.

Are there people on this list that might be willing to look over
a posted dump then?  My problem with DUN produced a trace, but
I gave up on it because there was no way I could understand
it. Is it worth my posting a dump?

Cheers,
	Paul.

-------------------------------------------------------------------------
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
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

Re: [Bluez-users] problem in making multiple connections using single bluetooth adapter using bluez

[Marcel Holtmann]

Hi Paul,

> > And once again "hcidump -X -V" is your friend in showing what
> > actually happens on the Bluetooth chip level.
> 
> Are there people on this list that might be willing to look over
> a posted dump then?  My problem with DUN produced a trace, but
> I gave up on it because there was no way I could understand
> it. Is it worth my posting a dump?

depends on what level the problem actually is. If it is hidden somewhere
in the PPP part it is unlikely that you get a fast answer. If it is
something obvious you might get your problem solved very quickly. So it
is always worth posting the hcidump.

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
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

Re: [Bluez-users] problem in making multiple connections using single bluetooth adapter using bluez

[Paul Gardiner]

Marcel Holtmann wrote:
> Hi Paul,
> 
>>> And once again "hcidump -X -V" is your friend in showing what
>>> actually happens on the Bluetooth chip level.
>> Are there people on this list that might be willing to look over
>> a posted dump then?  My problem with DUN produced a trace, but
>> I gave up on it because there was no way I could understand
>> it. Is it worth my posting a dump?
> 
> depends on what level the problem actually is. If it is hidden somewhere
> in the PPP part it is unlikely that you get a fast answer. If it is
> something obvious you might get your problem solved very quickly. So it
> is always worth posting the hcidump.

Great. Thanks for at least having a look.  I think the problem is
early on because I get nothing in my logs from dund.

Here it is:

HCI sniffer - Bluetooth packet analyzer ver 1.33
device: hci0 snap_len: 1028 filter: 0xffffffff
 > HCI Event: Connect Request (0x04) plen 10
     bdaddr 00:09:2D:08:BC:57 class 0x100114 type ACL
< HCI Command: Accept Connection Request (0x01|0x0009) plen 7
     bdaddr 00:09:2D:08:BC:57 role 0x01
     Role: Slave
 > HCI Event: Command Status (0x0f) plen 4
     Accept Connection Request (0x01|0x0009) status 0x00 ncmd 1
 > HCI Event: Connect Complete (0x03) plen 11
     status 0x00 handle 42 bdaddr 00:09:2D:08:BC:57 type ACL encrypt 0x00
< HCI Command: Read Remote Supported Features (0x01|0x001b) plen 2
     handle 42
 > HCI Event: Page Scan Repetition Mode Change (0x20) plen 7
     bdaddr 00:09:2D:08:BC:57 mode 1
 > HCI Event: Command Status (0x0f) plen 4
     Read Remote Supported Features (0x01|0x001b) status 0x00 ncmd 0
 > HCI Event: Max Slots Change (0x1b) plen 3
     handle 42 slots 5
 > ACL data: handle 42 flags 0x02 dlen 12
     L2CAP(s): Connect req: psm 1 scid 0x0200
< ACL data: handle 42 flags 0x02 dlen 16
     L2CAP(s): Connect rsp: dcid 0x0040 scid 0x0200 result 0 status 0
       Connection successful
 > HCI Event: Command Status (0x0f) plen 4
     Unknown (0x00|0x0000) status 0x00 ncmd 1
< HCI Command: Write Link Policy Settings (0x02|0x000d) plen 4
     handle 42 policy 0x0f
     Link policy: RSWITCH HOLD SNIFF PARK
 > HCI Event: Command Complete (0x0e) plen 6
     Write Link Policy Settings (0x02|0x000d) ncmd 1
     status 0x00 handle 42
< HCI Command: Change Connection Packet Type (0x01|0x000f) plen 4
     handle 42 ptype 0xcc18
     Packet type: DM1 DM3 DM5 DH1 DH3 DH5
 > HCI Event: Command Status (0x0f) plen 4
     Change Connection Packet Type (0x01|0x000f) status 0x00 ncmd 1
< HCI Command: Remote Name Request (0x01|0x0019) plen 10
     bdaddr 00:09:2D:08:BC:57 mode 2 clkoffset 0x0000
 > HCI Event: Connection Packet Type Changed (0x1d) plen 5
     status 0x00 handle 42 ptype 0xff1e
     Packet type: DM1 DM3 DM5 DH1 DH3 DH5 2-DH1 2-DH3 2-DH5 3-DH1 3-DH3 
3-DH5
 > HCI Event: Command Status (0x0f) plen 4
     Remote Name Request (0x01|0x0019) status 0x00 ncmd 1
 > HCI Event: Read Remote Supported Features (0x0b) plen 11
     status 0x00 handle 42
     Features: 0xff 0xff 0x0f 0x00 0x00 0x00 0x00 0x00
 > HCI Event: Number of Completed Packets (0x13) plen 5
     handle 42 packets 1
 > ACL data: handle 42 flags 0x02 dlen 16
     L2CAP(s): Config req: dcid 0x0040 flags 0x00 clen 4
       MTU 4096
< ACL data: handle 42 flags 0x02 dlen 14
     L2CAP(s): Config rsp: scid 0x0200 flags 0x00 result 0 clen 0
       Success
< ACL data: handle 42 flags 0x02 dlen 12
     L2CAP(s): Config req: dcid 0x0200 flags 0x00 clen 0
 > HCI Event: Number of Completed Packets (0x13) plen 5
     handle 42 packets 1
 > HCI Event: Remote Name Req Complete (0x07) plen 255
     status 0x00 bdaddr 00:09:2D:08:BC:57 name 'Pocket_PC2'
 > ACL data: handle 42 flags 0x02 dlen 14
     L2CAP(s): Config rsp: scid 0x0040 flags 0x00 result 0 clen 0
       Success
 > HCI Event: Number of Completed Packets (0x13) plen 5
     handle 42 packets 1
 > ACL data: handle 42 flags 0x02 dlen 17
 > ACL data: handle 42 flags 0x01 dlen 17
 > ACL data: handle 42 flags 0x01 dlen 2
     L2CAP(d): cid 0x0040 len 32 [psm 1]
         SDP SSA Req: tid 0x0 len 0x1b
           pat uuid-128 00001103-0000-1000-8000-00805f9b34fb
           max 4088
           aid(s) 0x0004 (ProtocolDescList)
           cont 00
< ACL data: handle 42 flags 0x02 dlen 52
     L2CAP(d): cid 0x0200 len 48 [psm 1]
         SDP SSA Rsp: tid 0x0 len 0x2b
           count 40
           record #0
               aid 0x0004 (ProtocolDescList)
                  < < uuid-16 0x0100 (L2CAP) > <
                  uuid-16 0x0003 (RFCOMM) uint 0x2 > >
           record #1
               aid 0x0004 (ProtocolDescList)
                  < < uuid-16 0x0100 (L2CAP) > <
                  uuid-16 0x0003 (RFCOMM) uint 0x2 > >
           cont 00
 > ACL data: handle 42 flags 0x02 dlen 12
     L2CAP(s): Connect req: psm 3 scid 0x0201
< ACL data: handle 42 flags 0x02 dlen 16
     L2CAP(s): Connect rsp: dcid 0x0041 scid 0x0201 result 0 status 0
       Connection successful
 > HCI Event: Number of Completed Packets (0x13) plen 5
     handle 42 packets 1
 > ACL data: handle 42 flags 0x02 dlen 12
     L2CAP(s): Disconn req: dcid 0x0040 scid 0x0200
< ACL data: handle 42 flags 0x02 dlen 12
     L2CAP(s): Disconn rsp: dcid 0x0040 scid 0x0200
 > HCI Event: Number of Completed Packets (0x13) plen 5
     handle 42 packets 1
 > HCI Event: Number of Completed Packets (0x13) plen 5
     handle 42 packets 1
 > ACL data: handle 42 flags 0x02 dlen 12
     L2CAP(s): Config req: dcid 0x0041 flags 0x00 clen 0
< ACL data: handle 42 flags 0x02 dlen 14
     L2CAP(s): Config rsp: scid 0x0201 flags 0x00 result 0 clen 0
       Success
< ACL data: handle 42 flags 0x02 dlen 16
     L2CAP(s): Config req: dcid 0x0201 flags 0x00 clen 4
       MTU 1013
 > HCI Event: Number of Completed Packets (0x13) plen 5
     handle 42 packets 1
 > ACL data: handle 42 flags 0x02 dlen 14
     L2CAP(s): Config rsp: scid 0x0041 flags 0x00 result 0 clen 0
       Success
 > HCI Event: Number of Completed Packets (0x13) plen 5
     handle 42 packets 1
 > ACL data: handle 42 flags 0x02 dlen 8
     L2CAP(d): cid 0x0041 len 4 [psm 3]
       RFCOMM(s): SABM: cr 1 dlci 0 pf 1 ilen 0 fcs 0x1c
< ACL data: handle 42 flags 0x02 dlen 8
     L2CAP(d): cid 0x0201 len 4 [psm 3]
       RFCOMM(s): UA: cr 1 dlci 0 pf 1 ilen 0 fcs 0xd7
 > HCI Event: Number of Completed Packets (0x13) plen 5
     handle 42 packets 1
 > ACL data: handle 42 flags 0x02 dlen 17
 > ACL data: handle 42 flags 0x01 dlen 1
     L2CAP(d): cid 0x0041 len 14 [psm 3]
       RFCOMM(s): PN CMD: cr 1 dlci 0 pf 0 ilen 10 fcs 0x70 mcc_len 8
       dlci 4 frame_type 0 credit_flow 15 pri 32 ack_timer 0
       frame_size 1024 max_retrans 0 credits 7
< ACL data: handle 42 flags 0x02 dlen 8
     L2CAP(d): cid 0x0201 len 4 [psm 3]
       RFCOMM(s): DM: cr 1 dlci 4 pf 1 ilen 0 fcs 0xbc
 > HCI Event: Number of Completed Packets (0x13) plen 5
     handle 42 packets 1
 > ACL data: handle 42 flags 0x02 dlen 12
     L2CAP(s): Disconn req: dcid 0x0041 scid 0x0201
< ACL data: handle 42 flags 0x02 dlen 12
     L2CAP(s): Disconn rsp: dcid 0x0041 scid 0x0201
 > HCI Event: Number of Completed Packets (0x13) plen 5
     handle 42 packets 1
 > ACL data: handle 42 flags 0x02 dlen 12
     L2CAP(s): Connect req: psm 1 scid 0x0202
< ACL data: handle 42 flags 0x02 dlen 16
     L2CAP(s): Connect rsp: dcid 0x0040 scid 0x0202 result 0 status 0
       Connection successful
 > HCI Event: Number of Completed Packets (0x13) plen 5
     handle 42 packets 1
 > ACL data: handle 42 flags 0x02 dlen 16
     L2CAP(s): Config req: dcid 0x0040 flags 0x00 clen 4
       MTU 4096
< ACL data: handle 42 flags 0x02 dlen 14
     L2CAP(s): Config rsp: scid 0x0202 flags 0x00 result 0 clen 0
       Success
< ACL data: handle 42 flags 0x02 dlen 12
     L2CAP(s): Config req: dcid 0x0202 flags 0x00 clen 0
 > HCI Event: Number of Completed Packets (0x13) plen 5
     handle 42 packets 1
 > ACL data: handle 42 flags 0x02 dlen 14
     L2CAP(s): Config rsp: scid 0x0040 flags 0x00 result 0 clen 0
       Success
 > HCI Event: Number of Completed Packets (0x13) plen 5
     handle 42 packets 1
 > ACL data: handle 42 flags 0x02 dlen 17
 > ACL data: handle 42 flags 0x01 dlen 17
 > ACL data: handle 42 flags 0x01 dlen 2
     L2CAP(d): cid 0x0040 len 32 [psm 1]
         SDP SSA Req: tid 0x0 len 0x1b
           pat uuid-128 00001103-0000-1000-8000-00805f9b34fb
           max 4088
           aid(s) 0x0004 (ProtocolDescList)
           cont 00
< ACL data: handle 42 flags 0x02 dlen 52
     L2CAP(d): cid 0x0202 len 48 [psm 1]
         SDP SSA Rsp: tid 0x0 len 0x2b
           count 40
           record #0
               aid 0x0004 (ProtocolDescList)
                  < < uuid-16 0x0100 (L2CAP) > <
                  uuid-16 0x0003 (RFCOMM) uint 0x2 > >
           record #1
               aid 0x0004 (ProtocolDescList)
                  < < uuid-16 0x0100 (L2CAP) > <
                  uuid-16 0x0003 (RFCOMM) uint 0x2 > >
           cont 00
 > HCI Event: Number of Completed Packets (0x13) plen 5
     handle 42 packets 1
 > ACL data: handle 42 flags 0x02 dlen 12
     L2CAP(s): Connect req: psm 3 scid 0x0203
< ACL data: handle 42 flags 0x02 dlen 16
     L2CAP(s): Connect rsp: dcid 0x0041 scid 0x0203 result 0 status 0
       Connection successful
 > ACL data: handle 42 flags 0x02 dlen 12
     L2CAP(s): Disconn req: dcid 0x0040 scid 0x0202
< ACL data: handle 42 flags 0x02 dlen 12
     L2CAP(s): Disconn rsp: dcid 0x0040 scid 0x0202
 > HCI Event: Number of Completed Packets (0x13) plen 5
     handle 42 packets 1
 > ACL data: handle 42 flags 0x02 dlen 12
     L2CAP(s): Config req: dcid 0x0041 flags 0x00 clen 0
< ACL data: handle 42 flags 0x02 dlen 14
     L2CAP(s): Config rsp: scid 0x0203 flags 0x00 result 0 clen 0
       Success
< ACL data: handle 42 flags 0x02 dlen 16
     L2CAP(s): Config req: dcid 0x0203 flags 0x00 clen 4
       MTU 1013
 > HCI Event: Number of Completed Packets (0x13) plen 5
     handle 42 packets 1
 > HCI Event: Number of Completed Packets (0x13) plen 5
     handle 42 packets 1
 > HCI Event: Number of Completed Packets (0x13) plen 5
     handle 42 packets 1
 > ACL data: handle 42 flags 0x02 dlen 14
     L2CAP(s): Config rsp: scid 0x0041 flags 0x00 result 0 clen 0
       Success
 > ACL data: handle 42 flags 0x02 dlen 8
     L2CAP(d): cid 0x0041 len 4 [psm 3]
       RFCOMM(s): SABM: cr 1 dlci 0 pf 1 ilen 0 fcs 0x1c
< ACL data: handle 42 flags 0x02 dlen 8
     L2CAP(d): cid 0x0203 len 4 [psm 3]
       RFCOMM(s): UA: cr 1 dlci 0 pf 1 ilen 0 fcs 0xd7
 > HCI Event: Number of Completed Packets (0x13) plen 5
     handle 42 packets 1
 > ACL data: handle 42 flags 0x02 dlen 17
 > ACL data: handle 42 flags 0x01 dlen 1
     L2CAP(d): cid 0x0041 len 14 [psm 3]
       RFCOMM(s): PN CMD: cr 1 dlci 0 pf 0 ilen 10 fcs 0x70 mcc_len 8
       dlci 4 frame_type 0 credit_flow 15 pri 32 ack_timer 0
       frame_size 1024 max_retrans 0 credits 7
< ACL data: handle 42 flags 0x02 dlen 8
     L2CAP(d): cid 0x0203 len 4 [psm 3]
       RFCOMM(s): DM: cr 1 dlci 4 pf 1 ilen 0 fcs 0xbc
 > HCI Event: Number of Completed Packets (0x13) plen 5
     handle 42 packets 1
 > ACL data: handle 42 flags 0x02 dlen 12
     L2CAP(s): Disconn req: dcid 0x0041 scid 0x0203
< ACL data: handle 42 flags 0x02 dlen 12
     L2CAP(s): Disconn rsp: dcid 0x0041 scid 0x0203
 > HCI Event: Number of Completed Packets (0x13) plen 5
     handle 42 packets 1
< HCI Command: Disconnect (0x01|0x0006) plen 3
     handle 42 reason 0x13
     Reason: Remote User Terminated Connection
 > HCI Event: Command Status (0x0f) plen 4
     Disconnect (0x01|0x0006) status 0x00 ncmd 1
 > HCI Event: Disconn Complete (0x05) plen 4
     status 0x00 handle 42 reason 0x16
     Reason: Connection Terminated by Local Host


-------------------------------------------------------------------------
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
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

Re: [Bluez-users] problem in making multiple connections using single bluetooth adapter using bluez

[Marcel Holtmann]

Hi Paul,

> >>> And once again "hcidump -X -V" is your friend in showing what
> >>> actually happens on the Bluetooth chip level.
> >> Are there people on this list that might be willing to look over
> >> a posted dump then?  My problem with DUN produced a trace, but
> >> I gave up on it because there was no way I could understand
> >> it. Is it worth my posting a dump?
> > 
> > depends on what level the problem actually is. If it is hidden somewhere
> > in the PPP part it is unlikely that you get a fast answer. If it is
> > something obvious you might get your problem solved very quickly. So it
> > is always worth posting the hcidump.
> 
> Great. Thanks for at least having a look.  I think the problem is
> early on because I get nothing in my logs from dund.

even if some howtos tell you to use sdptool to add a service record.
Simply don't do that. The dund will do it for you when needed and with
the correct attributes.

Check /sys/class/bluetooth/rfcomm that you really have a listening
RFCOMM socket on the right channel after starting dund.

And since you connect from a Windows OS, it might do something crazy or
expect something strange and that could be the reason why it is not
working.

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
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

Re: [Bluez-users] problem in making multiple connections using single bluetooth adapter using bluez

[Paul Gardiner]

Marcel Holtmann wrote:
> Hi Paul,
> 
>>>>> And once again "hcidump -X -V" is your friend in showing what
>>>>> actually happens on the Bluetooth chip level.
>>>> Are there people on this list that might be willing to look over
>>>> a posted dump then?  My problem with DUN produced a trace, but
>>>> I gave up on it because there was no way I could understand
>>>> it. Is it worth my posting a dump?
>>> depends on what level the problem actually is. If it is hidden somewhere
>>> in the PPP part it is unlikely that you get a fast answer. If it is
>>> something obvious you might get your problem solved very quickly. So it
>>> is always worth posting the hcidump.
>> Great. Thanks for at least having a look.  I think the problem is
>> early on because I get nothing in my logs from dund.

Thanks for taking a look.

> even if some howtos tell you to use sdptool to add a service record.
> Simply don't do that. The dund will do it for you when needed and with
> the correct attributes.

As you say, I got that from a howto, but I also had signs it was
needed, in that if I don't issue that command then my S100 wont
consider using the Bluez device as a modem. The device appears
in the S100's list of all bluetooth devices, but when trying to
create a new "Network Connection", Bluez doesn't appear in the
list of bluetooth devices that should be considered for that
use.

That and your statement above would imply that dund is
not seeing fit to add a service record, or it is adding
one with a different set of attributes, which the S100
doesn't like. Any idea why that might be?

> Check /sys/class/bluetooth/rfcomm that you really have a listening
> RFCOMM socket on the right channel after starting dund.

Will do. Thanks.

> And since you connect from a Windows OS, it might do something crazy or
> expect something strange and that could be the reason why it is not
> working.

Yeah I see what you mean, but it can't be insurmountable because all
this was working with the earlier version of Bluez that was shipped
with opensuse 10.1.

Cheers,
	Paul.

-------------------------------------------------------------------------
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
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

Re: [Bluez-users] problem in making multiple connections using single bluetooth adapter using bluez

[Tianlei Zhao]

[-- Attachment #1.1: Type: text/plain, Size: 1566 bytes --]

On 1/3/07, Paul Gardiner <osronline@glidos.net> wrote:

> > ACL data: handle 42 flags 0x02 dlen 8
>     L2CAP(d): cid 0x0041 len 4 [psm 3]
>       RFCOMM(s): SABM: cr 1 dlci 0 pf 1 ilen 0 fcs 0x1c
> < ACL data: handle 42 flags 0x02 dlen 8
>     L2CAP(d): cid 0x0203 len 4 [psm 3]
>       RFCOMM(s): UA: cr 1 dlci 0 pf 1 ilen 0 fcs 0xd7


here we have established the RFCOMM session(control channel).

 > HCI Event: Number of Completed Packets (0x13) plen 5
>     handle 42 packets 1
>  > ACL data: handle 42 flags 0x02 dlen 17
>  > ACL data: handle 42 flags 0x01 dlen 1
>     L2CAP(d): cid 0x0041 len 14 [psm 3]
>       RFCOMM(s): PN CMD: cr 1 dlci 0 pf 0 ilen 10 fcs 0x70 mcc_len 8
>       dlci 4 frame_type 0 credit_flow 15 pri 32 ack_timer 0
>       frame_size 1024 max_retrans 0 credits 7
> < ACL data: handle 42 flags 0x02 dlen 8
>     L2CAP(d): cid 0x0203 len 4 [psm 3]
>       RFCOMM(s): DM: cr 1 dlci 4 pf 1 ilen 0 fcs 0xbc


And why a DM for channel 4 is sent as a response  of  a PN CMD for dlci 0 ?
Should this not happen ? There must be some problem of the command that
was received. Maybe we've got a corrupted command for dlci 4 and that
hcidump
didn't show it up.

 > HCI Event: Number of Completed Packets (0x13) plen 5
>     handle 42 packets 1
>  > ACL data: handle 42 flags 0x02 dlen 12
>     L2CAP(s): Disconn req: dcid 0x0041 scid 0x0203
> < ACL data: handle 42 flags 0x02 dlen 12
>     L2CAP(s): Disconn rsp: dcid 0x0041 scid 0x0203
>  > HCI Event: Number of Completed Packets (0x13) plen 5
>     handle 42 packets 1



This is really strange.

[-- Attachment #1.2: Type: text/html, Size: 2485 bytes --]

[-- Attachment #2: Type: text/plain, Size: 347 bytes --]

-------------------------------------------------------------------------
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

[-- Attachment #3: Type: text/plain, Size: 164 bytes --]

_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

Re: [Bluez-users] problem in making multiple connections using single bluetooth adapter using bluez

[Marcel Holtmann]

Hi,

>          > HCI Event: Number of Completed Packets (0x13) plen 5
>             handle 42 packets 1
>          > ACL data: handle 42 flags 0x02 dlen 17
>          > ACL data: handle 42 flags 0x01 dlen 1
>             L2CAP(d): cid 0x0041 len 14 [psm 3] 
>               RFCOMM(s): PN CMD: cr 1 dlci 0 pf 0 ilen 10 fcs 0x70 mcc_len 8
>               dlci 4 frame_type 0 credit_flow 15 pri 32 ack_timer 0
>               frame_size 1024 max_retrans 0 credits 7
>         < ACL data: handle 42 flags 0x02 dlen 8 
>             L2CAP(d): cid 0x0203 len 4 [psm 3]
>               RFCOMM(s): DM: cr 1 dlci 4 pf 1 ilen 0 fcs 0xbc
> 
> And why a DM for channel 4 is sent as a response  of  a PN CMD for dlci 0 ? 
> Should this not happen ? There must be some problem of the command that 
> was received. Maybe we've got a corrupted command for dlci 4 and that hcidump
> didn't show it up.

actually that is the wrong interpretation. The PN CMD is sent on the
multiplexer DLCI 0 and it is sent for DLCI 4. This means we try to open
RFCOMM channel 2. The following DM is an indication that no service is
listening on RFCOMM channel 2. Hence my request to check the actual
registered listening sockets via /sys/class/bluetooth/rfcomm.

>          > HCI Event: Number of Completed Packets (0x13) plen 5
>             handle 42 packets 1
>          > ACL data: handle 42 flags 0x02 dlen 12
>             L2CAP(s): Disconn req: dcid 0x0041 scid 0x0203
>         < ACL data: handle 42 flags 0x02 dlen 12 
>             L2CAP(s): Disconn rsp: dcid 0x0041 scid 0x0203
>          > HCI Event: Number of Completed Packets (0x13) plen 5
>             handle 42 packets 1
>
> This is really strange. 

No, it is not.

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
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

[Bluez-users] Problems fooling my S100 into using Bluez as a modem

[Paul Gardiner]

Marcel Holtmann wrote:
> Check /sys/class/bluetooth/rfcomm that you really have a listening
> RFCOMM socket on the right channel after starting dund.

How do I check this?  In that directory I have "hci0", which is a soft
link, and three other files "l2cap", "rfcomm", "rfcomm_dlc".  How
do I check they are correct?

Also, I have to own up to something silly: when some of your
statements seemed to imply that most of this should work
without special configuration, I put the original config
files in place, but didn't notice that dund was off by
default.  I'll post some new dumps with that corrected.

Cheers,
	Paul.


-------------------------------------------------------------------------
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
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

Re: [Bluez-users] Problems fooling my S100 into using Bluez as a modem

[Paul Gardiner]

Paul Gardiner wrote:
> Also, I have to own up to something silly: when some of your
> statements seemed to imply that most of this should work
> without special configuration, I put the original config
> files in place, but didn't notice that dund was off by
> default.  I'll post some new dumps with that corrected.

This is the dump of my S100 discovering Bluez. This is
without a preceding call to "sdptool add DUN", and
although the device is discovered, the S100 then
refuses to use it as a modem:

HCI sniffer - Bluetooth packet analyzer ver 1.33
device: hci0 snap_len: 1028 filter: 0xffffffff
 > HCI Event: Connect Request (0x04) plen 10
     bdaddr 00:09:2D:08:BC:57 class 0x100114 type ACL
< HCI Command: Accept Connection Request (0x01|0x0009) plen 7
     bdaddr 00:09:2D:08:BC:57 role 0x01
     Role: Slave
 > HCI Event: Command Status (0x0f) plen 4
     Accept Connection Request (0x01|0x0009) status 0x00 ncmd 1
 > HCI Event: Connect Complete (0x03) plen 11
     status 0x00 handle 42 bdaddr 00:09:2D:08:BC:57 type ACL encrypt 0x00
< HCI Command: Read Remote Supported Features (0x01|0x001b) plen 2
     handle 42
 > HCI Event: Page Scan Repetition Mode Change (0x20) plen 7
     bdaddr 00:09:2D:08:BC:57 mode 1
 > HCI Event: Max Slots Change (0x1b) plen 3
     handle 42 slots 5
 > HCI Event: Command Status (0x0f) plen 4
     Read Remote Supported Features (0x01|0x001b) status 0x00 ncmd 0
 > HCI Event: Command Status (0x0f) plen 4
     Unknown (0x00|0x0000) status 0x00 ncmd 1
< HCI Command: Write Link Policy Settings (0x02|0x000d) plen 4
     handle 42 policy 0x0f
     Link policy: RSWITCH HOLD SNIFF PARK
 > HCI Event: Command Complete (0x0e) plen 6
     Write Link Policy Settings (0x02|0x000d) ncmd 1
     status 0x00 handle 42
< HCI Command: Change Connection Packet Type (0x01|0x000f) plen 4
     handle 42 ptype 0xcc18
     Packet type: DM1 DM3 DM5 DH1 DH3 DH5
 > HCI Event: Command Status (0x0f) plen 4
     Change Connection Packet Type (0x01|0x000f) status 0x00 ncmd 1
< HCI Command: Remote Name Request (0x01|0x0019) plen 10
     bdaddr 00:09:2D:08:BC:57 mode 2 clkoffset 0x0000
 > HCI Event: Connection Packet Type Changed (0x1d) plen 5
     status 0x00 handle 42 ptype 0xff1e
     Packet type: DM1 DM3 DM5 DH1 DH3 DH5 2-DH1 2-DH3 2-DH5 3-DH1 3-DH3 
3-DH5
 > HCI Event: Command Status (0x0f) plen 4
     Remote Name Request (0x01|0x0019) status 0x00 ncmd 1
 > HCI Event: Read Remote Supported Features (0x0b) plen 11
     status 0x00 handle 42
     Features: 0xff 0xff 0x0f 0x00 0x00 0x00 0x00 0x00
 > HCI Event: Remote Name Req Complete (0x07) plen 255
     status 0x00 bdaddr 00:09:2D:08:BC:57 name 'Pocket_PC2'
 > HCI Event: PIN Code Request (0x16) plen 6
     bdaddr 00:09:2D:08:BC:57
< HCI Command: PIN Code Request Reply (0x01|0x000d) plen 23
     bdaddr 00:09:2D:08:BC:57 len 4 pin '6969'
 > HCI Event: Command Complete (0x0e) plen 10
     PIN Code Request Reply (0x01|0x000d) ncmd 1
     status 0x00 bdaddr 00:09:2D:08:BC:57
 > HCI Event: Link Key Notification (0x18) plen 23
     bdaddr 00:09:2D:08:BC:57 key 8293311B9D50705254DBEBA5259F9851 type 0
 > HCI Event: Disconn Complete (0x05) plen 4
     status 0x00 handle 42 reason 0x13
     Reason: Remote User Terminated Connection
 > HCI Event: Connect Request (0x04) plen 10
     bdaddr 00:09:2D:08:BC:57 class 0x100114 type ACL
< HCI Command: Accept Connection Request (0x01|0x0009) plen 7
     bdaddr 00:09:2D:08:BC:57 role 0x01
     Role: Slave
 > HCI Event: Command Status (0x0f) plen 4
     Accept Connection Request (0x01|0x0009) status 0x00 ncmd 1
 > HCI Event: Connect Complete (0x03) plen 11
     status 0x00 handle 43 bdaddr 00:09:2D:08:BC:57 type ACL encrypt 0x00
< HCI Command: Read Remote Supported Features (0x01|0x001b) plen 2
     handle 43
 > HCI Event: Page Scan Repetition Mode Change (0x20) plen 7
     bdaddr 00:09:2D:08:BC:57 mode 1
 > HCI Event: Max Slots Change (0x1b) plen 3
     handle 43 slots 5
 > HCI Event: Command Status (0x0f) plen 4
     Read Remote Supported Features (0x01|0x001b) status 0x00 ncmd 0
 > ACL data: handle 43 flags 0x02 dlen 12
     L2CAP(s): Connect req: psm 1 scid 0x0055
< ACL data: handle 43 flags 0x02 dlen 16
     L2CAP(s): Connect rsp: dcid 0x0040 scid 0x0055 result 0 status 0
       Connection successful
 > HCI Event: Command Status (0x0f) plen 4
     Unknown (0x00|0x0000) status 0x00 ncmd 1
< HCI Command: Write Link Policy Settings (0x02|0x000d) plen 4
     handle 43 policy 0x0f
     Link policy: RSWITCH HOLD SNIFF PARK
 > HCI Event: Command Complete (0x0e) plen 6
     Write Link Policy Settings (0x02|0x000d) ncmd 1
     status 0x00 handle 43
< HCI Command: Change Connection Packet Type (0x01|0x000f) plen 4
     handle 43 ptype 0xcc18
     Packet type: DM1 DM3 DM5 DH1 DH3 DH5
 > HCI Event: Command Status (0x0f) plen 4
     Change Connection Packet Type (0x01|0x000f) status 0x00 ncmd 1
< HCI Command: Remote Name Request (0x01|0x0019) plen 10
     bdaddr 00:09:2D:08:BC:57 mode 2 clkoffset 0x0000
 > HCI Event: Connection Packet Type Changed (0x1d) plen 5
     status 0x00 handle 43 ptype 0xff1e
     Packet type: DM1 DM3 DM5 DH1 DH3 DH5 2-DH1 2-DH3 2-DH5 3-DH1 3-DH3 
3-DH5
 > HCI Event: Command Status (0x0f) plen 4
     Remote Name Request (0x01|0x0019) status 0x00 ncmd 1
 > HCI Event: Read Remote Supported Features (0x0b) plen 11
     status 0x00 handle 43
     Features: 0xff 0xff 0x0f 0x00 0x00 0x00 0x00 0x00
 > HCI Event: Remote Name Req Complete (0x07) plen 255
     status 0x00 bdaddr 00:09:2D:08:BC:57 name 'Pocket_PC2'
 > HCI Event: Number of Completed Packets (0x13) plen 5
     handle 43 packets 1
 > ACL data: handle 43 flags 0x02 dlen 16
     L2CAP(s): Config req: dcid 0x0040 flags 0x00 clen 4
       MTU 4096
< ACL data: handle 43 flags 0x02 dlen 14
     L2CAP(s): Config rsp: scid 0x0055 flags 0x00 result 0 clen 0
       Success
< ACL data: handle 43 flags 0x02 dlen 12
     L2CAP(s): Config req: dcid 0x0055 flags 0x00 clen 0
 > HCI Event: Number of Completed Packets (0x13) plen 5
     handle 43 packets 1
 > HCI Event: Number of Completed Packets (0x13) plen 5
     handle 43 packets 1
 > ACL data: handle 43 flags 0x02 dlen 14
     L2CAP(s): Config rsp: scid 0x0040 flags 0x00 result 0 clen 0
       Success
 > ACL data: handle 43 flags 0x02 dlen 17
 > ACL data: handle 43 flags 0x01 dlen 17
 > ACL data: handle 43 flags 0x01 dlen 4
     L2CAP(d): cid 0x0040 len 34 [psm 1]
         SDP SSA Req: tid 0x0 len 0x1d
           pat uuid-128 00001108-0000-1000-8000-00805f9b34fb
           max 4088
           aid(s) 0x0000 - 0xffff
           cont 00
< ACL data: handle 43 flags 0x02 dlen 14
     L2CAP(d): cid 0x0055 len 10 [psm 1]
         SDP SSA Rsp: tid 0x0 len 0x5
           count 2
           cont 00
 > HCI Event: Number of Completed Packets (0x13) plen 5
     handle 43 packets 1
 > ACL data: handle 43 flags 0x02 dlen 12
     L2CAP(s): Disconn req: dcid 0x0040 scid 0x0055
< ACL data: handle 43 flags 0x02 dlen 12
     L2CAP(s): Disconn rsp: dcid 0x0040 scid 0x0055
 > HCI Event: Number of Completed Packets (0x13) plen 5
     handle 43 packets 1
 > ACL data: handle 43 flags 0x02 dlen 12
     L2CAP(s): Connect req: psm 1 scid 0x0056
< ACL data: handle 43 flags 0x02 dlen 16
     L2CAP(s): Connect rsp: dcid 0x0040 scid 0x0056 result 0 status 0
       Connection successful
 > HCI Event: Number of Completed Packets (0x13) plen 5
     handle 43 packets 1
 > ACL data: handle 43 flags 0x02 dlen 16
     L2CAP(s): Config req: dcid 0x0040 flags 0x00 clen 4
       MTU 4096
< ACL data: handle 43 flags 0x02 dlen 14
     L2CAP(s): Config rsp: scid 0x0056 flags 0x00 result 0 clen 0
       Success
< ACL data: handle 43 flags 0x02 dlen 12
     L2CAP(s): Config req: dcid 0x0056 flags 0x00 clen 0
 > HCI Event: Number of Completed Packets (0x13) plen 5
     handle 43 packets 1
 > HCI Event: Number of Completed Packets (0x13) plen 5
     handle 43 packets 1
 > ACL data: handle 43 flags 0x02 dlen 14
     L2CAP(s): Config rsp: scid 0x0040 flags 0x00 result 0 clen 0
       Success
 > ACL data: handle 43 flags 0x02 dlen 17
 > ACL data: handle 43 flags 0x01 dlen 17
 > ACL data: handle 43 flags 0x01 dlen 4
     L2CAP(d): cid 0x0040 len 34 [psm 1]
         SDP SSA Req: tid 0x0 len 0x1d
           pat uuid-128 0000111e-0000-1000-8000-00805f9b34fb
           max 4088
           aid(s) 0x0000 - 0xffff
           cont 00
< ACL data: handle 43 flags 0x02 dlen 14
     L2CAP(d): cid 0x0056 len 10 [psm 1]
         SDP SSA Rsp: tid 0x0 len 0x5
           count 2
           cont 00
 > HCI Event: Number of Completed Packets (0x13) plen 5
     handle 43 packets 1
 > ACL data: handle 43 flags 0x02 dlen 12
     L2CAP(s): Disconn req: dcid 0x0040 scid 0x0056
< ACL data: handle 43 flags 0x02 dlen 12
     L2CAP(s): Disconn rsp: dcid 0x0040 scid 0x0056
 > HCI Event: Number of Completed Packets (0x13) plen 5
     handle 43 packets 1
 > ACL data: handle 43 flags 0x02 dlen 12
     L2CAP(s): Connect req: psm 1 scid 0x0057
< ACL data: handle 43 flags 0x02 dlen 16
     L2CAP(s): Connect rsp: dcid 0x0040 scid 0x0057 result 0 status 0
       Connection successful
 > HCI Event: Number of Completed Packets (0x13) plen 5
     handle 43 packets 1
 > ACL data: handle 43 flags 0x02 dlen 16
     L2CAP(s): Config req: dcid 0x0040 flags 0x00 clen 4
       MTU 4096
< ACL data: handle 43 flags 0x02 dlen 14
     L2CAP(s): Config rsp: scid 0x0057 flags 0x00 result 0 clen 0
       Success
< ACL data: handle 43 flags 0x02 dlen 12
     L2CAP(s): Config req: dcid 0x0057 flags 0x00 clen 0
 > HCI Event: Number of Completed Packets (0x13) plen 5
     handle 43 packets 1
 > HCI Event: Number of Completed Packets (0x13) plen 5
     handle 43 packets 1
 > ACL data: handle 43 flags 0x02 dlen 14
     L2CAP(s): Config rsp: scid 0x0040 flags 0x00 result 0 clen 0
       Success
 > ACL data: handle 43 flags 0x02 dlen 17
 > ACL data: handle 43 flags 0x01 dlen 17
 > ACL data: handle 43 flags 0x01 dlen 4
     L2CAP(d): cid 0x0040 len 34 [psm 1]
         SDP SSA Req: tid 0x0 len 0x1d
           pat uuid-128 00001103-0000-1000-8000-00805f9b34fb
           max 4088
           aid(s) 0x0000 - 0xffff
           cont 00
< ACL data: handle 43 flags 0x02 dlen 14
     L2CAP(d): cid 0x0057 len 10 [psm 1]
         SDP SSA Rsp: tid 0x0 len 0x5
           count 2
           cont 00
 > ACL data: handle 43 flags 0x02 dlen 12
     L2CAP(s): Disconn req: dcid 0x0040 scid 0x0057
< ACL data: handle 43 flags 0x02 dlen 12
     L2CAP(s): Disconn rsp: dcid 0x0040 scid 0x0057
 > HCI Event: Number of Completed Packets (0x13) plen 5
     handle 43 packets 1
 > ACL data: handle 43 flags 0x02 dlen 12
     L2CAP(s): Connect req: psm 1 scid 0x0058
< ACL data: handle 43 flags 0x02 dlen 16
     L2CAP(s): Connect rsp: dcid 0x0040 scid 0x0058 result 0 status 0
       Connection successful
 > HCI Event: Number of Completed Packets (0x13) plen 5
     handle 43 packets 1
 > HCI Event: Number of Completed Packets (0x13) plen 5
     handle 43 packets 1
 > ACL data: handle 43 flags 0x02 dlen 16
     L2CAP(s): Config req: dcid 0x0040 flags 0x00 clen 4
       MTU 4096
< ACL data: handle 43 flags 0x02 dlen 14
     L2CAP(s): Config rsp: scid 0x0058 flags 0x00 result 0 clen 0
       Success
< ACL data: handle 43 flags 0x02 dlen 12
     L2CAP(s): Config req: dcid 0x0058 flags 0x00 clen 0
 > HCI Event: Number of Completed Packets (0x13) plen 5
     handle 43 packets 1
 > HCI Event: Number of Completed Packets (0x13) plen 5
     handle 43 packets 1
 > ACL data: handle 43 flags 0x02 dlen 14
     L2CAP(s): Config rsp: scid 0x0040 flags 0x00 result 0 clen 0
       Success
 > ACL data: handle 43 flags 0x02 dlen 17
 > ACL data: handle 43 flags 0x01 dlen 17
 > ACL data: handle 43 flags 0x01 dlen 4
     L2CAP(d): cid 0x0040 len 34 [psm 1]
         SDP SSA Req: tid 0x0 len 0x1d
           pat uuid-128 00001101-0000-1000-8000-00805f9b34fb
           max 4088
           aid(s) 0x0000 - 0xffff
           cont 00
< ACL data: handle 43 flags 0x02 dlen 234
     L2CAP(d): cid 0x0058 len 230 [psm 1]
         SDP SSA Rsp: tid 0x0 len 0xe1
           count 222
           record #0
               aid 0x0000 (SrvRecHndl)
                  uint 0x10002
               aid 0x0001 (SrvClassIDList)
                  < uuid-16 0x1101 (SP) >
               aid 0x0004 (ProtocolDescList)
                  < < uuid-16 0x0100 (L2CAP) > <
                  uuid-16 0x0003 (RFCOMM) uint 0x5 > >
               aid 0x0005 (BrwGrpList)
                  < uuid-16 0x1002 (PubBrwsGrp) >
               aid 0x0100 (SrvName)
                  str "KBtSerialChat"
               aid 0x0101 (SrvDesc)
                  str "KDE Bluetooth Serial Chat Service"
           record #1
               aid 0x0000 (SrvRecHndl)
                  uint 0x10003
               aid 0x0001 (SrvClassIDList)
                  < uuid-16 0x1101 (SP) >
               aid 0x0004 (ProtocolDescList)
                  < < uuid-16 0x0100 (L2CAP) > <
                  uuid-16 0x0003 (RFCOMM) uint 0x1b > >
               aid 0x0005 (BrwGrpList)
                  < uuid-16 0x1002 (PubBrwsGrp) >
               aid 0x0100 (SrvName)
                  str "KDE Bemused Server"
               aid 0x0101 (SrvDesc)
                  str "KDE Server for the Bemused remote control protocol"
           cont 00
 > HCI Event: Number of Completed Packets (0x13) plen 5
     handle 43 packets 1
 > ACL data: handle 43 flags 0x02 dlen 12
     L2CAP(s): Disconn req: dcid 0x0040 scid 0x0058
< ACL data: handle 43 flags 0x02 dlen 12
     L2CAP(s): Disconn rsp: dcid 0x0040 scid 0x0058
 > HCI Event: Number of Completed Packets (0x13) plen 5
     handle 43 packets 1
 > ACL data: handle 43 flags 0x02 dlen 12
     L2CAP(s): Connect req: psm 1 scid 0x0059
< ACL data: handle 43 flags 0x02 dlen 16
     L2CAP(s): Connect rsp: dcid 0x0040 scid 0x0059 result 0 status 0
       Connection successful
 > HCI Event: Number of Completed Packets (0x13) plen 5
     handle 43 packets 1
 > ACL data: handle 43 flags 0x02 dlen 16
     L2CAP(s): Config req: dcid 0x0040 flags 0x00 clen 4
       MTU 4096
< ACL data: handle 43 flags 0x02 dlen 14
     L2CAP(s): Config rsp: scid 0x0059 flags 0x00 result 0 clen 0
       Success
< ACL data: handle 43 flags 0x02 dlen 12
     L2CAP(s): Config req: dcid 0x0059 flags 0x00 clen 0
 > HCI Event: Number of Completed Packets (0x13) plen 5
     handle 43 packets 1
 > ACL data: handle 43 flags 0x02 dlen 14
     L2CAP(s): Config rsp: scid 0x0040 flags 0x00 result 0 clen 0
       Success
 > HCI Event: Number of Completed Packets (0x13) plen 5
     handle 43 packets 1
 > ACL data: handle 43 flags 0x02 dlen 17
 > ACL data: handle 43 flags 0x01 dlen 17
 > ACL data: handle 43 flags 0x01 dlen 4
     L2CAP(d): cid 0x0040 len 34 [psm 1]
         SDP SSA Req: tid 0x0 len 0x1d
           pat uuid-128 0350278f-3dca-4e62-831d-a41165ff906c
           max 4088
           aid(s) 0x0000 - 0xffff
           cont 00
< ACL data: handle 43 flags 0x02 dlen 14
     L2CAP(d): cid 0x0059 len 10 [psm 1]
         SDP SSA Rsp: tid 0x0 len 0x5
           count 2
           cont 00
 > ACL data: handle 43 flags 0x02 dlen 12
     L2CAP(s): Disconn req: dcid 0x0040 scid 0x0059
< ACL data: handle 43 flags 0x02 dlen 12
     L2CAP(s): Disconn rsp: dcid 0x0040 scid 0x0059
 > HCI Event: Number of Completed Packets (0x13) plen 5
     handle 43 packets 1
 > HCI Event: Number of Completed Packets (0x13) plen 5
     handle 43 packets 1
< HCI Command: Disconnect (0x01|0x0006) plen 3
     handle 43 reason 0x13
     Reason: Remote User Terminated Connection
 > HCI Event: Command Status (0x0f) plen 4
     Disconnect (0x01|0x0006) status 0x00 ncmd 1
 > HCI Event: Disconn Complete (0x05) plen 4
     status 0x00 handle 43 reason 0x16
     Reason: Connection Terminated by Local Host

-------------------------------------------------------------------------
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
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

Re: [Bluez-users] Problems fooling my S100 into using Bluez as a modem

[Paul Gardiner]

Paul Gardiner wrote:
> Also, I have to own up to something silly: when some of your
> statements seemed to imply that most of this should work
> without special configuration, I put the original config
> files in place, but didn't notice that dund was off by
> default.  I'll post some new dumps with that corrected.

This is a second dump of my S100 discovering Bluez, this
time after issuing the command

sdptool add DUN

After this, the S100 will attempt to use my server as
a modem:

HCI sniffer - Bluetooth packet analyzer ver 1.33
device: hci0 snap_len: 1028 filter: 0xffffffff
< HCI Command: Inquiry (0x01|0x0001) plen 5
     lap 0x9e8b33 len 6 num 0
 > HCI Event: Command Status (0x0f) plen 4
     Inquiry (0x01|0x0001) status 0x00 ncmd 1
 > HCI Event: Inquiry Complete (0x01) plen 1
     status 0x00
 > HCI Event: Connect Request (0x04) plen 10
     bdaddr 00:09:2D:08:BC:57 class 0x100114 type ACL
< HCI Command: Accept Connection Request (0x01|0x0009) plen 7
     bdaddr 00:09:2D:08:BC:57 role 0x01
     Role: Slave
 > HCI Event: Command Status (0x0f) plen 4
     Accept Connection Request (0x01|0x0009) status 0x00 ncmd 1
 > HCI Event: Connect Complete (0x03) plen 11
     status 0x00 handle 42 bdaddr 00:09:2D:08:BC:57 type ACL encrypt 0x00
< HCI Command: Read Remote Supported Features (0x01|0x001b) plen 2
     handle 42
 > HCI Event: Page Scan Repetition Mode Change (0x20) plen 7
     bdaddr 00:09:2D:08:BC:57 mode 1
 > HCI Event: Command Status (0x0f) plen 4
     Read Remote Supported Features (0x01|0x001b) status 0x00 ncmd 0
 > HCI Event: Max Slots Change (0x1b) plen 3
     handle 42 slots 5
 > HCI Event: Command Status (0x0f) plen 4
     Unknown (0x00|0x0000) status 0x00 ncmd 1
< HCI Command: Write Link Policy Settings (0x02|0x000d) plen 4
     handle 42 policy 0x0f
     Link policy: RSWITCH HOLD SNIFF PARK
 > HCI Event: Command Complete (0x0e) plen 6
     Write Link Policy Settings (0x02|0x000d) ncmd 1
     status 0x00 handle 42
< HCI Command: Change Connection Packet Type (0x01|0x000f) plen 4
     handle 42 ptype 0xcc18
     Packet type: DM1 DM3 DM5 DH1 DH3 DH5
 > HCI Event: Read Remote Supported Features (0x0b) plen 11
     status 0x00 handle 42
     Features: 0xff 0xff 0x0f 0x00 0x00 0x00 0x00 0x00
 > HCI Event: Command Status (0x0f) plen 4
     Change Connection Packet Type (0x01|0x000f) status 0x00 ncmd 1
< HCI Command: Remote Name Request (0x01|0x0019) plen 10
     bdaddr 00:09:2D:08:BC:57 mode 2 clkoffset 0x0000
 > HCI Event: Connection Packet Type Changed (0x1d) plen 5
     status 0x00 handle 42 ptype 0xff1e
     Packet type: DM1 DM3 DM5 DH1 DH3 DH5 2-DH1 2-DH3 2-DH5 3-DH1 3-DH3 
3-DH5
 > HCI Event: Command Status (0x0f) plen 4
     Remote Name Request (0x01|0x0019) status 0x00 ncmd 1
 > HCI Event: Remote Name Req Complete (0x07) plen 255
     status 0x00 bdaddr 00:09:2D:08:BC:57 name 'Pocket_PC2'
 > HCI Event: PIN Code Request (0x16) plen 6
     bdaddr 00:09:2D:08:BC:57
< HCI Command: PIN Code Request Reply (0x01|0x000d) plen 23
     bdaddr 00:09:2D:08:BC:57 len 4 pin '6969'
 > HCI Event: Command Complete (0x0e) plen 10
     PIN Code Request Reply (0x01|0x000d) ncmd 1
     status 0x00 bdaddr 00:09:2D:08:BC:57
 > HCI Event: Link Key Notification (0x18) plen 23
     bdaddr 00:09:2D:08:BC:57 key 0B9ACB6B85E27429E31F00CA81593DAA type 0
 > HCI Event: Disconn Complete (0x05) plen 4
     status 0x00 handle 42 reason 0x13
     Reason: Remote User Terminated Connection
 > HCI Event: Connect Request (0x04) plen 10
     bdaddr 00:09:2D:08:BC:57 class 0x100114 type ACL
< HCI Command: Accept Connection Request (0x01|0x0009) plen 7
     bdaddr 00:09:2D:08:BC:57 role 0x01
     Role: Slave
 > HCI Event: Command Status (0x0f) plen 4
     Accept Connection Request (0x01|0x0009) status 0x00 ncmd 1
 > HCI Event: Connect Complete (0x03) plen 11
     status 0x00 handle 43 bdaddr 00:09:2D:08:BC:57 type ACL encrypt 0x00
< HCI Command: Read Remote Supported Features (0x01|0x001b) plen 2
     handle 43
 > HCI Event: Page Scan Repetition Mode Change (0x20) plen 7
     bdaddr 00:09:2D:08:BC:57 mode 1
 > HCI Event: Command Status (0x0f) plen 4
     Read Remote Supported Features (0x01|0x001b) status 0x00 ncmd 0
 > HCI Event: Max Slots Change (0x1b) plen 3
     handle 43 slots 5
 > ACL data: handle 43 flags 0x02 dlen 12
     L2CAP(s): Connect req: psm 1 scid 0x005a
< ACL data: handle 43 flags 0x02 dlen 16
     L2CAP(s): Connect rsp: dcid 0x0040 scid 0x005a result 0 status 0
       Connection successful
 > HCI Event: Command Status (0x0f) plen 4
     Unknown (0x00|0x0000) status 0x00 ncmd 1
< HCI Command: Write Link Policy Settings (0x02|0x000d) plen 4
     handle 43 policy 0x0f
     Link policy: RSWITCH HOLD SNIFF PARK
 > HCI Event: Command Complete (0x0e) plen 6
     Write Link Policy Settings (0x02|0x000d) ncmd 1
     status 0x00 handle 43
< HCI Command: Change Connection Packet Type (0x01|0x000f) plen 4
     handle 43 ptype 0xcc18
     Packet type: DM1 DM3 DM5 DH1 DH3 DH5
 > HCI Event: Command Status (0x0f) plen 4
     Change Connection Packet Type (0x01|0x000f) status 0x00 ncmd 1
< HCI Command: Remote Name Request (0x01|0x0019) plen 10
     bdaddr 00:09:2D:08:BC:57 mode 2 clkoffset 0x0000
 > HCI Event: Connection Packet Type Changed (0x1d) plen 5
     status 0x00 handle 43 ptype 0xff1e
     Packet type: DM1 DM3 DM5 DH1 DH3 DH5 2-DH1 2-DH3 2-DH5 3-DH1 3-DH3 
3-DH5
 > HCI Event: Number of Completed Packets (0x13) plen 5
     handle 43 packets 1
 > ACL data: handle 43 flags 0x02 dlen 16
     L2CAP(s): Config req: dcid 0x0040 flags 0x00 clen 4
       MTU 4096
< ACL data: handle 43 flags 0x02 dlen 14
     L2CAP(s): Config rsp: scid 0x005a flags 0x00 result 0 clen 0
       Success
< ACL data: handle 43 flags 0x02 dlen 12
     L2CAP(s): Config req: dcid 0x005a flags 0x00 clen 0
 > HCI Event: Command Status (0x0f) plen 4
     Remote Name Request (0x01|0x0019) status 0x00 ncmd 1
 > HCI Event: Number of Completed Packets (0x13) plen 5
     handle 43 packets 1
 > HCI Event: Number of Completed Packets (0x13) plen 5
     handle 43 packets 1
 > HCI Event: Read Remote Supported Features (0x0b) plen 11
     status 0x00 handle 43
     Features: 0xff 0xff 0x0f 0x00 0x00 0x00 0x00 0x00
 > ACL data: handle 43 flags 0x02 dlen 14
     L2CAP(s): Config rsp: scid 0x0040 flags 0x00 result 0 clen 0
       Success
 > ACL data: handle 43 flags 0x02 dlen 17
 > ACL data: handle 43 flags 0x01 dlen 17
 > HCI Event: Remote Name Req Complete (0x07) plen 255
     status 0x00 bdaddr 00:09:2D:08:BC:57 name 'Pocket_PC2'
 > ACL data: handle 43 flags 0x01 dlen 4
     L2CAP(d): cid 0x0040 len 34 [psm 1]
         SDP SSA Req: tid 0x0 len 0x1d
           pat uuid-128 00001108-0000-1000-8000-00805f9b34fb
           max 4088
           aid(s) 0x0000 - 0xffff
           cont 00
< ACL data: handle 43 flags 0x02 dlen 14
     L2CAP(d): cid 0x005a len 10 [psm 1]
         SDP SSA Rsp: tid 0x0 len 0x5
           count 2
           cont 00
 > HCI Event: Number of Completed Packets (0x13) plen 5
     handle 43 packets 1
 > ACL data: handle 43 flags 0x02 dlen 12
     L2CAP(s): Disconn req: dcid 0x0040 scid 0x005a
< ACL data: handle 43 flags 0x02 dlen 12
     L2CAP(s): Disconn rsp: dcid 0x0040 scid 0x005a
 > HCI Event: Number of Completed Packets (0x13) plen 5
     handle 43 packets 1
 > ACL data: handle 43 flags 0x02 dlen 12
     L2CAP(s): Connect req: psm 1 scid 0x005b
< ACL data: handle 43 flags 0x02 dlen 16
     L2CAP(s): Connect rsp: dcid 0x0040 scid 0x005b result 0 status 0
       Connection successful
 > ACL data: handle 43 flags 0x02 dlen 16
     L2CAP(s): Config req: dcid 0x0040 flags 0x00 clen 4
       MTU 4096
< ACL data: handle 43 flags 0x02 dlen 14
     L2CAP(s): Config rsp: scid 0x005b flags 0x00 result 0 clen 0
       Success
< ACL data: handle 43 flags 0x02 dlen 12
     L2CAP(s): Config req: dcid 0x005b flags 0x00 clen 0
 > HCI Event: Number of Completed Packets (0x13) plen 5
     handle 43 packets 1
 > HCI Event: Number of Completed Packets (0x13) plen 5
     handle 43 packets 1
 > HCI Event: Number of Completed Packets (0x13) plen 5
     handle 43 packets 1
 > ACL data: handle 43 flags 0x02 dlen 14
     L2CAP(s): Config rsp: scid 0x0040 flags 0x00 result 0 clen 0
       Success
 > ACL data: handle 43 flags 0x02 dlen 17
 > ACL data: handle 43 flags 0x01 dlen 17
 > ACL data: handle 43 flags 0x01 dlen 4
     L2CAP(d): cid 0x0040 len 34 [psm 1]
         SDP SSA Req: tid 0x0 len 0x1d
           pat uuid-128 0000111e-0000-1000-8000-00805f9b34fb
           max 4088
           aid(s) 0x0000 - 0xffff
           cont 00
< ACL data: handle 43 flags 0x02 dlen 14
     L2CAP(d): cid 0x005b len 10 [psm 1]
         SDP SSA Rsp: tid 0x0 len 0x5
           count 2
           cont 00
 > ACL data: handle 43 flags 0x02 dlen 12
     L2CAP(s): Disconn req: dcid 0x0040 scid 0x005b
< ACL data: handle 43 flags 0x02 dlen 12
     L2CAP(s): Disconn rsp: dcid 0x0040 scid 0x005b
 > HCI Event: Number of Completed Packets (0x13) plen 5
     handle 43 packets 1
 > HCI Event: Number of Completed Packets (0x13) plen 5
     handle 43 packets 1
 > ACL data: handle 43 flags 0x02 dlen 12
     L2CAP(s): Connect req: psm 1 scid 0x005c
< ACL data: handle 43 flags 0x02 dlen 16
     L2CAP(s): Connect rsp: dcid 0x0040 scid 0x005c result 0 status 0
       Connection successful
 > HCI Event: Number of Completed Packets (0x13) plen 5
     handle 43 packets 1
 > ACL data: handle 43 flags 0x02 dlen 16
     L2CAP(s): Config req: dcid 0x0040 flags 0x00 clen 4
       MTU 4096
< ACL data: handle 43 flags 0x02 dlen 14
     L2CAP(s): Config rsp: scid 0x005c flags 0x00 result 0 clen 0
       Success
< ACL data: handle 43 flags 0x02 dlen 12
     L2CAP(s): Config req: dcid 0x005c flags 0x00 clen 0
 > HCI Event: Number of Completed Packets (0x13) plen 5
     handle 43 packets 1
 > HCI Event: Number of Completed Packets (0x13) plen 5
     handle 43 packets 1
 > ACL data: handle 43 flags 0x02 dlen 14
     L2CAP(s): Config rsp: scid 0x0040 flags 0x00 result 0 clen 0
       Success
 > ACL data: handle 43 flags 0x02 dlen 17
 > ACL data: handle 43 flags 0x01 dlen 17
 > ACL data: handle 43 flags 0x01 dlen 4
     L2CAP(d): cid 0x0040 len 34 [psm 1]
         SDP SSA Req: tid 0x0 len 0x1d
           pat uuid-128 00001103-0000-1000-8000-00805f9b34fb
           max 4088
           aid(s) 0x0000 - 0xffff
           cont 00
< ACL data: handle 43 flags 0x02 dlen 96
     L2CAP(d): cid 0x005c len 92 [psm 1]
         SDP SSA Rsp: tid 0x0 len 0x57
           count 84
           record #0
               aid 0x0000 (SrvRecHndl)
                  uint 0x10004
               aid 0x0001 (SrvClassIDList)
                  < uuid-16 0x1103 (DUN) uuid-16 0x1201 (Networking) >
               aid 0x0004 (ProtocolDescList)
                  < < uuid-16 0x0100 (L2CAP) > <
                  uuid-16 0x0003 (RFCOMM) uint 0x2 > >
               aid 0x0005 (BrwGrpList)
                  < uuid-16 0x1002 (PubBrwsGrp) >
               aid 0x0009 (BTProfileDescList)
                  < < uuid-16 0x1103 (DUN) uint 0x100 > >
               aid 0x0100 (SrvName)
                  str "Dial-Up Networking"
           cont 00
 > HCI Event: Number of Completed Packets (0x13) plen 5
     handle 43 packets 1
 > ACL data: handle 43 flags 0x02 dlen 12
     L2CAP(s): Disconn req: dcid 0x0040 scid 0x005c
< ACL data: handle 43 flags 0x02 dlen 12
     L2CAP(s): Disconn rsp: dcid 0x0040 scid 0x005c
 > HCI Event: Number of Completed Packets (0x13) plen 5
     handle 43 packets 1
 > ACL data: handle 43 flags 0x02 dlen 12
     L2CAP(s): Connect req: psm 1 scid 0x005d
< ACL data: handle 43 flags 0x02 dlen 16
     L2CAP(s): Connect rsp: dcid 0x0040 scid 0x005d result 0 status 0
       Connection successful
 > ACL data: handle 43 flags 0x02 dlen 16
     L2CAP(s): Config req: dcid 0x0040 flags 0x00 clen 4
       MTU 4096
< ACL data: handle 43 flags 0x02 dlen 14
     L2CAP(s): Config rsp: scid 0x005d flags 0x00 result 0 clen 0
       Success
< ACL data: handle 43 flags 0x02 dlen 12
     L2CAP(s): Config req: dcid 0x005d flags 0x00 clen 0
 > HCI Event: Number of Completed Packets (0x13) plen 5
     handle 43 packets 1
 > HCI Event: Number of Completed Packets (0x13) plen 5
     handle 43 packets 1
 > HCI Event: Number of Completed Packets (0x13) plen 5
     handle 43 packets 1
 > ACL data: handle 43 flags 0x02 dlen 14
     L2CAP(s): Config rsp: scid 0x0040 flags 0x00 result 0 clen 0
       Success
 > ACL data: handle 43 flags 0x02 dlen 17
 > ACL data: handle 43 flags 0x01 dlen 17
 > ACL data: handle 43 flags 0x01 dlen 4
     L2CAP(d): cid 0x0040 len 34 [psm 1]
         SDP SSA Req: tid 0x0 len 0x1d
           pat uuid-128 00001101-0000-1000-8000-00805f9b34fb
           max 4088
           aid(s) 0x0000 - 0xffff
           cont 00
< ACL data: handle 43 flags 0x02 dlen 234
     L2CAP(d): cid 0x005d len 230 [psm 1]
         SDP SSA Rsp: tid 0x0 len 0xe1
           count 222
           record #0
               aid 0x0000 (SrvRecHndl)
                  uint 0x10002
               aid 0x0001 (SrvClassIDList)
                  < uuid-16 0x1101 (SP) >
               aid 0x0004 (ProtocolDescList)
                  < < uuid-16 0x0100 (L2CAP) > <
                  uuid-16 0x0003 (RFCOMM) uint 0x5 > >
               aid 0x0005 (BrwGrpList)
                  < uuid-16 0x1002 (PubBrwsGrp) >
               aid 0x0100 (SrvName)
                  str "KBtSerialChat"
               aid 0x0101 (SrvDesc)
                  str "KDE Bluetooth Serial Chat Service"
           record #1
               aid 0x0000 (SrvRecHndl)
                  uint 0x10003
               aid 0x0001 (SrvClassIDList)
                  < uuid-16 0x1101 (SP) >
               aid 0x0004 (ProtocolDescList)
                  < < uuid-16 0x0100 (L2CAP) > <
                  uuid-16 0x0003 (RFCOMM) uint 0x1b > >
               aid 0x0005 (BrwGrpList)
                  < uuid-16 0x1002 (PubBrwsGrp) >
               aid 0x0100 (SrvName)
                  str "KDE Bemused Server"
               aid 0x0101 (SrvDesc)
                  str "KDE Server for the Bemused remote control protocol"
           cont 00
 > HCI Event: Number of Completed Packets (0x13) plen 5
     handle 43 packets 1
 > ACL data: handle 43 flags 0x02 dlen 12
     L2CAP(s): Disconn req: dcid 0x0040 scid 0x005d
< ACL data: handle 43 flags 0x02 dlen 12
     L2CAP(s): Disconn rsp: dcid 0x0040 scid 0x005d
 > HCI Event: Number of Completed Packets (0x13) plen 5
     handle 43 packets 1
 > ACL data: handle 43 flags 0x02 dlen 12
     L2CAP(s): Connect req: psm 1 scid 0x005e
< ACL data: handle 43 flags 0x02 dlen 16
     L2CAP(s): Connect rsp: dcid 0x0040 scid 0x005e result 0 status 0
       Connection successful
 > HCI Event: Number of Completed Packets (0x13) plen 5
     handle 43 packets 1
 > ACL data: handle 43 flags 0x02 dlen 16
     L2CAP(s): Config req: dcid 0x0040 flags 0x00 clen 4
       MTU 4096
< ACL data: handle 43 flags 0x02 dlen 14
     L2CAP(s): Config rsp: scid 0x005e flags 0x00 result 0 clen 0
       Success
< ACL data: handle 43 flags 0x02 dlen 12
     L2CAP(s): Config req: dcid 0x005e flags 0x00 clen 0
 > HCI Event: Number of Completed Packets (0x13) plen 5
     handle 43 packets 1
 > HCI Event: Number of Completed Packets (0x13) plen 5
     handle 43 packets 1
 > ACL data: handle 43 flags 0x02 dlen 14
     L2CAP(s): Config rsp: scid 0x0040 flags 0x00 result 0 clen 0
       Success
 > ACL data: handle 43 flags 0x02 dlen 17
 > ACL data: handle 43 flags 0x01 dlen 17
 > ACL data: handle 43 flags 0x01 dlen 4
     L2CAP(d): cid 0x0040 len 34 [psm 1]
         SDP SSA Req: tid 0x0 len 0x1d
           pat uuid-128 0350278f-3dca-4e62-831d-a41165ff906c
           max 4088
           aid(s) 0x0000 - 0xffff
           cont 00
< ACL data: handle 43 flags 0x02 dlen 14
     L2CAP(d): cid 0x005e len 10 [psm 1]
         SDP SSA Rsp: tid 0x0 len 0x5
           count 2
           cont 00
 > ACL data: handle 43 flags 0x02 dlen 12
     L2CAP(s): Disconn req: dcid 0x0040 scid 0x005e
< ACL data: handle 43 flags 0x02 dlen 12
     L2CAP(s): Disconn rsp: dcid 0x0040 scid 0x005e
 > HCI Event: Number of Completed Packets (0x13) plen 5
     handle 43 packets 1
 > HCI Event: Number of Completed Packets (0x13) plen 5
     handle 43 packets 1
< HCI Command: Disconnect (0x01|0x0006) plen 3
     handle 43 reason 0x13
     Reason: Remote User Terminated Connection
 > HCI Event: Command Status (0x0f) plen 4
     Disconnect (0x01|0x0006) status 0x00 ncmd 1
 > HCI Event: Disconn Complete (0x05) plen 4
     status 0x00 handle 43 reason 0x16
     Reason: Connection Terminated by Local Host

-------------------------------------------------------------------------
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
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

Re: [Bluez-users] Problems fooling my S100 into using Bluez as a modem

[Paul Gardiner]

Paul Gardiner wrote:
> Also, I have to own up to something silly: when some of your
> statements seemed to imply that most of this should work
> without special configuration, I put the original config
> files in place, but didn't notice that dund was off by
> default.  I'll post some new dumps with that corrected.

This is my S100 trying to actually connect to my server.
This time I haven't been daft and tried it without
dund running.  I still have to issue

sdptool add DUN

to get this far though:

HCI sniffer - Bluetooth packet analyzer ver 1.33
device: hci0 snap_len: 1028 filter: 0xffffffff
 > HCI Event: Connect Request (0x04) plen 10
     bdaddr 00:09:2D:08:BC:57 class 0x100114 type ACL
< HCI Command: Accept Connection Request (0x01|0x0009) plen 7
     bdaddr 00:09:2D:08:BC:57 role 0x01
     Role: Slave
 > HCI Event: Command Status (0x0f) plen 4
     Accept Connection Request (0x01|0x0009) status 0x00 ncmd 1
 > HCI Event: Connect Complete (0x03) plen 11
     status 0x00 handle 42 bdaddr 00:09:2D:08:BC:57 type ACL encrypt 0x00
< HCI Command: Read Remote Supported Features (0x01|0x001b) plen 2
     handle 42
 > HCI Event: Page Scan Repetition Mode Change (0x20) plen 7
     bdaddr 00:09:2D:08:BC:57 mode 1
 > HCI Event: Max Slots Change (0x1b) plen 3
     handle 42 slots 5
 > HCI Event: Command Status (0x0f) plen 4
     Read Remote Supported Features (0x01|0x001b) status 0x00 ncmd 0
 > ACL data: handle 42 flags 0x02 dlen 12
     L2CAP(s): Connect req: psm 1 scid 0x0063
< ACL data: handle 42 flags 0x02 dlen 16
     L2CAP(s): Connect rsp: dcid 0x0040 scid 0x0063 result 0 status 0
       Connection successful
 > HCI Event: Number of Completed Packets (0x13) plen 5
     handle 42 packets 1
 > HCI Event: Command Status (0x0f) plen 4
     Unknown (0x00|0x0000) status 0x00 ncmd 1
< HCI Command: Write Link Policy Settings (0x02|0x000d) plen 4
     handle 42 policy 0x0f
     Link policy: RSWITCH HOLD SNIFF PARK
 > HCI Event: Command Complete (0x0e) plen 6
     Write Link Policy Settings (0x02|0x000d) ncmd 1
     status 0x00 handle 42
< HCI Command: Change Connection Packet Type (0x01|0x000f) plen 4
     handle 42 ptype 0xcc18
     Packet type: DM1 DM3 DM5 DH1 DH3 DH5
 > HCI Event: Read Remote Supported Features (0x0b) plen 11
     status 0x00 handle 42
     Features: 0xff 0xff 0x0f 0x00 0x00 0x00 0x00 0x00
 > HCI Event: Command Status (0x0f) plen 4
     Change Connection Packet Type (0x01|0x000f) status 0x00 ncmd 1
< HCI Command: Remote Name Request (0x01|0x0019) plen 10
     bdaddr 00:09:2D:08:BC:57 mode 2 clkoffset 0x0000
 > HCI Event: Connection Packet Type Changed (0x1d) plen 5
     status 0x00 handle 42 ptype 0xff1e
     Packet type: DM1 DM3 DM5 DH1 DH3 DH5 2-DH1 2-DH3 2-DH5 3-DH1 3-DH3 
3-DH5
 > HCI Event: Command Status (0x0f) plen 4
     Remote Name Request (0x01|0x0019) status 0x00 ncmd 1
 > ACL data: handle 42 flags 0x02 dlen 16
     L2CAP(s): Config req: dcid 0x0040 flags 0x00 clen 4
       MTU 4096
< ACL data: handle 42 flags 0x02 dlen 14
     L2CAP(s): Config rsp: scid 0x0063 flags 0x00 result 0 clen 0
       Success
< ACL data: handle 42 flags 0x02 dlen 12
     L2CAP(s): Config req: dcid 0x0063 flags 0x00 clen 0
 > HCI Event: Number of Completed Packets (0x13) plen 5
     handle 42 packets 1
 > ACL data: handle 42 flags 0x02 dlen 14
     L2CAP(s): Config rsp: scid 0x0040 flags 0x00 result 0 clen 0
       Success
 > HCI Event: Remote Name Req Complete (0x07) plen 255
     status 0x00 bdaddr 00:09:2D:08:BC:57 name 'Pocket_PC2'
 > HCI Event: Number of Completed Packets (0x13) plen 5
     handle 42 packets 1
 > ACL data: handle 42 flags 0x02 dlen 17
 > ACL data: handle 42 flags 0x01 dlen 17
 > ACL data: handle 42 flags 0x01 dlen 2
     L2CAP(d): cid 0x0040 len 32 [psm 1]
         SDP SSA Req: tid 0x0 len 0x1b
           pat uuid-128 00001103-0000-1000-8000-00805f9b34fb
           max 4088
           aid(s) 0x0004 (ProtocolDescList)
           cont 00
< ACL data: handle 42 flags 0x02 dlen 33
     L2CAP(d): cid 0x0063 len 29 [psm 1]
         SDP SSA Rsp: tid 0x0 len 0x18
           count 21
           record #0
               aid 0x0004 (ProtocolDescList)
                  < < uuid-16 0x0100 (L2CAP) > <
                  uuid-16 0x0003 (RFCOMM) uint 0x2 > >
           cont 00
 > HCI Event: Number of Completed Packets (0x13) plen 5
     handle 42 packets 1
 > ACL data: handle 42 flags 0x02 dlen 12
     L2CAP(s): Connect req: psm 3 scid 0x0064
< ACL data: handle 42 flags 0x02 dlen 16
     L2CAP(s): Connect rsp: dcid 0x0041 scid 0x0064 result 0 status 0
       Connection successful
 > HCI Event: Number of Completed Packets (0x13) plen 5
     handle 42 packets 1
 > ACL data: handle 42 flags 0x02 dlen 12
     L2CAP(s): Disconn req: dcid 0x0040 scid 0x0063
< ACL data: handle 42 flags 0x02 dlen 12
     L2CAP(s): Disconn rsp: dcid 0x0040 scid 0x0063
 > ACL data: handle 42 flags 0x02 dlen 12
     L2CAP(s): Config req: dcid 0x0041 flags 0x00 clen 0
< ACL data: handle 42 flags 0x02 dlen 14
     L2CAP(s): Config rsp: scid 0x0064 flags 0x00 result 0 clen 0
       Success
< ACL data: handle 42 flags 0x02 dlen 16
     L2CAP(s): Config req: dcid 0x0064 flags 0x00 clen 4
       MTU 1013
 > HCI Event: Number of Completed Packets (0x13) plen 5
     handle 42 packets 1
 > HCI Event: Number of Completed Packets (0x13) plen 5
     handle 42 packets 1
 > HCI Event: Number of Completed Packets (0x13) plen 5
     handle 42 packets 1
 > ACL data: handle 42 flags 0x02 dlen 14
     L2CAP(s): Config rsp: scid 0x0041 flags 0x00 result 0 clen 0
       Success
 > ACL data: handle 42 flags 0x02 dlen 8
     L2CAP(d): cid 0x0041 len 4 [psm 3]
       RFCOMM(s): SABM: cr 1 dlci 0 pf 1 ilen 0 fcs 0x1c
< ACL data: handle 42 flags 0x02 dlen 8
     L2CAP(d): cid 0x0064 len 4 [psm 3]
       RFCOMM(s): UA: cr 1 dlci 0 pf 1 ilen 0 fcs 0xd7
 > ACL data: handle 42 flags 0x02 dlen 17
 > ACL data: handle 42 flags 0x01 dlen 1
     L2CAP(d): cid 0x0041 len 14 [psm 3]
       RFCOMM(s): PN CMD: cr 1 dlci 0 pf 0 ilen 10 fcs 0x70 mcc_len 8
       dlci 4 frame_type 0 credit_flow 15 pri 32 ack_timer 0
       frame_size 1024 max_retrans 0 credits 7
< ACL data: handle 42 flags 0x02 dlen 8
     L2CAP(d): cid 0x0064 len 4 [psm 3]
       RFCOMM(s): DM: cr 1 dlci 4 pf 1 ilen 0 fcs 0xbc
 > HCI Event: Number of Completed Packets (0x13) plen 5
     handle 42 packets 1
 > HCI Event: Number of Completed Packets (0x13) plen 5
     handle 42 packets 1
 > ACL data: handle 42 flags 0x02 dlen 12
     L2CAP(s): Disconn req: dcid 0x0041 scid 0x0064
< ACL data: handle 42 flags 0x02 dlen 12
     L2CAP(s): Disconn rsp: dcid 0x0041 scid 0x0064
 > HCI Event: Number of Completed Packets (0x13) plen 5
     handle 42 packets 1
< HCI Command: Disconnect (0x01|0x0006) plen 3
     handle 42 reason 0x13
     Reason: Remote User Terminated Connection
 > HCI Event: Command Status (0x0f) plen 4
     Disconnect (0x01|0x0006) status 0x00 ncmd 1
 > HCI Event: Disconn Complete (0x05) plen 4
     status 0x00 handle 42 reason 0x16
     Reason: Connection Terminated by Local Host

-------------------------------------------------------------------------
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
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

Re: [Bluez-users] Problems fooling my S100 into using Bluez as a modem

[Paul Gardiner]

Paul Gardiner wrote:
> Marcel Holtmann wrote:
>> Check /sys/class/bluetooth/rfcomm that you really have a listening
>> RFCOMM socket on the right channel after starting dund.
> 
> How do I check this?  In that directory I have "hci0", which is a soft
> link, and three other files "l2cap", "rfcomm", "rfcomm_dlc".  How
> do I check they are correct?
> 
> Also, I have to own up to something silly: when some of your
> statements seemed to imply that most of this should work
> without special configuration, I put the original config
> files in place, but didn't notice that dund was off by
> default.  I'll post some new dumps with that corrected.

No chance someone can have a quick look at the three
traces? (should be the messages that appear at the
same level in this thread as this message)

I know its a lot to ask, but I so much want to have
this working again, and there's no way forward
without help.

Cheers,
	Paul.

-------------------------------------------------------------------------
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
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

Re: [Bluez-users] problem in making multiple connections using single bluetooth adapter using bluez

[Cris]

On Tue, 2 Jan 2007 18:16:28 +0530
"siddhant tewari" <siddhant.tewari@gmail.com> wrote:

>     With linux being one of the major players in embedded domain and bluez
> being an official protocol of linux there is definitely a great need for
> multi connection support. You have suggested that somebody with a thorough
> understanding of bluetooth and its protocol should start to fork the full
> development of bluetooth support in linux , but that somebody cannot be at
> least me at this instance as i am just a starter and it took some effort
> from my side to even get the idea of what u wrote ... i think it should be
> someone like you who has such a clear picture of the problem or to be more
> precise really understands the problem well , who can initiate such
> development... all i can say is that i am ready to work if somebody  can
> guide me ....

I'd love to start a fork and am thinking about it since a long time
and each time I crash on BlueZ. Unfortunately, I lack the fundings to
do so, as this is certainly not a job for a weekend.

> Please tell me what are the other options parallel to bluez and is it really
> advisable to  use them .
> 
> I am stuck at this problem and i dont like leaving it as such.

As I told you, there is no other way. If there was, I wouldn't have
started a complete user-space bluetooth stack spending already many
months on that. And unfortunately, I'm not allowed to share my code so
far (I wish I was).

Well, besides the two options (giving up or doing it yourself), there
might be a third one: It seems that they are working now on flow
control which is quite related to multi-connections. At least it
should. Meaning: you can wait until they think it's somehow useable
and try then. But you'll always be stuck on a fundamentally broken
design and depend on the help of a not so benevolent dictator. And I
wouldn't expect to see mainstream kernels with this code before mid
2007. If you watch out for what is said about bluetooth, we can expect
a significant increase in complexity regarding implementations. At
latest then, BlueZ will have to change anyway. Maybe then, you'll be
able to use it. This may take a couple of years.

-------------------------------------------------------------------------
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
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

Re: [Bluez-users] problem in making multiple connections using single bluetooth adapter using bluez

[Marcel Holtmann]

Hi,

> Obviously, BlueZ didn't learn to deal with more than one connection at
> the same time yet. They are still thinking that everybody has a
> desktop computer with KDE (or Windows, as dbus being a derivate from
> gtk, is specially designed to be platform independent) and just a
> single cellphone or PDA at home. Of course, large companies like Nokia
> are not really affected by these problems, as a cellphone is so small
> that it can't deal with much more than one thing at the same time
> anyway. But this may change in some future.

that is FUD. BlueZ can deal with as many connections as the chip allows
us to establish.

> So your only choice is to not use libbluetooth. Marcel is right when
> he says that this implies a lot of work, as you will have to implement
> each protocol layer yourself. But as these are quite badly designed in
> BlueZ, there is really no fix for it. If the BlueZ developers had a
> different way of dealing with users (just look at their answers) the
> many thousands of hours of work we are doing each one on his own could
> go into this project. So, we are alone here. Your choices like mine or
> anybody else's who is trying to serious work with bluetooth, is either
> to give up or to do the work.

Badly designed protocol layers. We provide BSD socket based access to
them which is one of the most intuitive interfaces. Did you ever looked
at other stacks and their API?

> But be aware, that re-writing the protocol stack may not be
> enough. I've done so and am having bad troubles because BlueZ
> developers think that an exclusive usage over a socket can be
> implemented by the concept of a raw socket. This is not true. Even
> using raw sockets the kernel will interfere in your programming,
> meaning that it is quite possible that we will have to replace also
> the kernel modules, which would make 100% of BlueZ code unusable. Not
> regulating mutually interfering accesses to one and the same ressource
> is pure Windows philosophy, where each program, starting with
> kernel.dll thinks it owns the complete device. Raw sockets allow to do
> low leve things, but they don't guarantee that someone else wont undo
> what ever my program has done a second earlier. Even if this someone
> else is the kernel herself.
> 
> I've suggested the use of an exclusive flag with the HCI sockets, when
> Marcel answered, that the kernel does NOT interfere when I open that
> socket in raw. This is just not true. Marcel (who should know as he
> wrote this monster) asked what exactly happens. Here it is:
> 
> If your program is already active and you plug in an USB bluetooth
> dongle, the kernel issues several informational queries to the
> device. It needs to do so, as a raw socket doesn't imply that there
> couldn't be more than one processes accessing the same device (there
> is no exclusivity), while a second process might want to use a cooked
> socket. In my case, I know that there will be no other process,
> specially not hcid or dbus, but the kernel doesn't, and still issues
> these commands. Thus, I need to expect anything to happen, just for
> the USB dongle having been plugged in. This raises the level of
> complexity of my program by a power of magnitud. Also, Marcel himself
> said, that whenever a major version number is increased, we can not
> trust that the behaviour wont change incompatibly with the previous
> version (besides the use of dbus and apparently the inability to
> multitask). Did anybody see any reasoning why dbus is defended so
> stiff neckedly? Or why nobody cares to work on a design which actually
> matches what bluetooth specifications persue?

I actually have no real idea what your complaints are. The raw HCI
socket is different from an adapter in raw mode. I mentioned that
multiple times, but you don't seem to understand the difference. And
again, everybody who wants to do direct HCI programming is better off
writing their own stack. Leave the HCI handling to the kernel or hcid
and concentrate on real applications.

> Much worse is what happens if you create a connection. Until you get
> the connection complete event, everything is fine. But then, the
> kernel will issue several commands, ignoring any commands of yours
> until it's done. Among those is HCI_Write_Link_Policy_Settings. At
> this point it seems to be impossible to achieve for instance a role
> switch. Also, the kernel has no way to know what my program is trying
> to do, and thus can not know which is the link policy I need.
> 
> You see, everybody doing things like you and me (and I've seen more
> than just a few more out there) is just out of luck. The best would be
> somebody starting to fork the full development of Bluetooth support in
> Linux, but this time with a well thought design based on a thorough
> understanding of bluetooth and it's protocols.

Be my guest and start the fork. When you think you understand
everything, I will show you bits and pieces you haven't thought about.
At some point you will realize that various parts of the Bluetooth
specification have their own problems.

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
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users