Hi,
i have been using bluez l2cap for quite some time now. To my BlueMP3 receiver
i have streamed gigabytes via l2cap with no problems using bluez as a sender
so far.
A customer of mine now told me, that l2cap under bluez is unrealible. It was
hard to believe, but the follwing archive contains to little programs i wrote
to verify this. It's a sender and a (artifically slowed down) receiver:
http://www.harbaum.org/till/l2flow.tgz
The sender is marking the packets with some sequence number. After about
80kBytes the receiver starts complaining about missing sequence numbers.
Since i can stream to my won hardware (and successfully slowing down the
transmission, since the receiving mp3 decoder is only taking the data at the
appropriate bandwidth) i am sure that sending data with bluez is not the
problem. However the receiver seems to fetch all packets from its bluetooth
hardware and is dropping packets if it then sees, that it has run out of
internal buffers.
Why is that? Can this be avoided? Is this by purpose?
Ciao,
Till
--
Dr.-Ing. Till Harbaum Tel.: +49 721 4998963
BeeCon GmbH Fax: +49 721 4998962
Haid-und-Neu Strasse 7, 76131 Karlsruhe Mobil: +49 179 9087904
[email protected] http://www.beecon.de
-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. http://www.ostg.com
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On Wed, 2004-08-04 at 17:24 +0200, Talbi wrote:
> first I use rfcomm to connect a Bluetooth device to my Dongle.
> when I shut down the Bluetooth device, the disconnection is detected only
> after 20 seconds.
You're asking this in a reply to a mail about L2CAP dropping packets.
Why do you believe that your disconnection time outs are related to
L2CAP dropping packets?
--
dwmw2
-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. http://www.ostg.com
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
hello,
first the Dongle is connected to Bluetooth device.
first I use rfcomm to connect a Bluetooth device to my Dongle.
when I shut down the Bluetooth device, the disconnection is detected only
after 20 seconds.
Can i reduce this Time Out?
regards,
-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. http://www.ostg.com
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Till,
> > the point is that we don't really thought about it when we were writing
> > our RFCOMM layer. It worked out, but I never checked the granted credits
> > against the receive buffer. Sounds like a work for a diploma thesis ;)
> Sorry, i already have a diploma and a ph.d., but we do have some bluetooth
> related projects at the university. I'll propose this to some of the
> professors.
I know and actually this hint was meant like if you know someone who
wants do write something about Bluetooth propose this.
> > The checksum stuff is historical and you will only get the sense behind
> I know. But they thought enough about it to remove the need to build the
> chechsum over the payload. Why did they still keep a checksum? (i have to
> admit, it helped me a lot, since it found some bugs in my l2cap/rfcomm code).
> I'd really like to talk about the person who made the bluetooth changes to
> rfcomm :-)
They didn't thought enough. The original ETSI specification include UIH
and UI data frames and they simple left out the UI frames, because the
L2CAP channel have to be reliable.
> > The first time I realized why people asking for host to host controller
> > flow control (BlueZ don't supports it btw) I screamed out loud. Then I
> You are talking about the buffer management on hci layer for the buffers on
> host side aren't you? As long as you have "enough" buffer space this doesn't
> seem very important. But with my devices having only few bytes buffer space,
> it really is necessary.
Yes. We never needed it and so nobody implemented it.
> > flow control of a lower layer for its own purpose. Implementation
> > details must reside inside the layer. This is one of the basics of the
> > OSI model.
> And the L2CAP start/continuation flags are part of the acl header :-)
This is ugly, I know. I never said that the Bluetooth stack design was
perfect ;)
Regards
Marcel
-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. http://www.ostg.com
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Marcel,
On Tuesday 03 August 2004 15:09, Marcel Holtmann wrote:
> the point is that we don't really thought about it when we were writing
> our RFCOMM layer. It worked out, but I never checked the granted credits
> against the receive buffer. Sounds like a work for a diploma thesis ;)
Sorry, i already have a diploma and a ph.d., but we do have some bluetooth
related projects at the university. I'll propose this to some of the
professors.
> The checksum stuff is historical and you will only get the sense behind
I know. But they thought enough about it to remove the need to build the
chechsum over the payload. Why did they still keep a checksum? (i have to
admit, it helped me a lot, since it found some bugs in my l2cap/rfcomm code).
I'd really like to talk about the person who made the bluetooth changes to
rfcomm :-)
> The first time I realized why people asking for host to host controller
> flow control (BlueZ don't supports it btw) I screamed out loud. Then I
You are talking about the buffer management on hci layer for the buffers on
host side aren't you? As long as you have "enough" buffer space this doesn't
seem very important. But with my devices having only few bytes buffer space,
it really is necessary.
> flow control of a lower layer for its own purpose. Implementation
> details must reside inside the layer. This is one of the basics of the
> OSI model.
And the L2CAP start/continuation flags are part of the acl header :-)
Ciao,
Till
--
Dr.-Ing. Till Harbaum Tel.: +49 721 4998963
BeeCon GmbH Fax: +49 721 4998962
Haid-und-Neu Strasse 7, 76131 Karlsruhe Mobil: +49 179 9087904
[email protected] http://www.beecon.de
Hi Till,
> > this. We only have to take care of that we don't get more packets than
> > our receive buffers can take. So the RFCOMM flow control should be
> But this means, that rfcomm has to know about the socket buffers and will have
> to make sure, that it won't give more credits than socket buffers are
> available.
the point is that we don't really thought about it when we were writing
our RFCOMM layer. It worked out, but I never checked the granted credits
against the receive buffer. Sounds like a work for a diploma thesis ;)
> In fact i always wondered what the purpose of rfcomm giving credits on packets
> not on bytes is. But with such an implementation this even makes sense
> (although i still think, that these per-packet-credits are an as bad idea as
> keeping the header checksum behind the rfcomm payload is ...).
The checksum stuff is historical and you will only get the sense behind
it if you read the full ETSI specification that RFCOMM is based on. In
case of Bluetooth it makes no sense and costs only performance. They
left so much out that it would have been better if they designed a new
protocol for serial port emulation.
> > enought to assure this. In general this is a big design mistake in the
> > Bluetooth protocol stack itself and only L2CAP with retransmission and
> > flow control can fix it.
> Yes, you are right.
>
> Wouldn't it be a good idea to use acl flow control at least as long as there's
> only one acl client? This would at least increase the reliability for single
> connection scenarios which are probably the most common case.
>
> This has the disadvantage, that the system behaves differently with single
> connections and with multiple connections. For multiple acl connections it's
> exactly as unrealiable as it is today, but it gives a little advantage to
> single acl connections.
It won't work out in any case. If you have one ACL link and two L2CAP
channels (for HIDP, HCRP or AVDTP this is normal) then one of them can
suspend the other one, because they share the same ACL link and thus
they share the same flow control. This can't work.
The first time I realized why people asking for host to host controller
flow control (BlueZ don't supports it btw) I screamed out loud. Then I
tried to convince them that it is always a bad idea, but they still
wanted it and these people are still thinking that it is a good idea. In
the long run all of them must accept that it is not possible to use the
flow control of a lower layer for its own purpose. Implementation
details must reside inside the layer. This is one of the basics of the
OSI model.
Regards
Marcel
-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. http://www.ostg.com
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Marcel,
On Tuesday 03 August 2004 13:24, Marcel Holtmann wrote:
> this. We only have to take care of that we don't get more packets than
> our receive buffers can take. So the RFCOMM flow control should be
But this means, that rfcomm has to know about the socket buffers and will have
to make sure, that it won't give more credits than socket buffers are
available.
In fact i always wondered what the purpose of rfcomm giving credits on packets
not on bytes is. But with such an implementation this even makes sense
(although i still think, that these per-packet-credits are an as bad idea as
keeping the header checksum behind the rfcomm payload is ...).
> enought to assure this. In general this is a big design mistake in the
> Bluetooth protocol stack itself and only L2CAP with retransmission and
> flow control can fix it.
Yes, you are right.
Wouldn't it be a good idea to use acl flow control at least as long as there's
only one acl client? This would at least increase the reliability for single
connection scenarios which are probably the most common case.
This has the disadvantage, that the system behaves differently with single
connections and with multiple connections. For multiple acl connections it's
exactly as unrealiable as it is today, but it gives a little advantage to
single acl connections.
Ciao,
Till
--
Dr.-Ing. Till Harbaum Tel.: +49 721 4998963
BeeCon GmbH Fax: +49 721 4998962
Haid-und-Neu Strasse 7, 76131 Karlsruhe Mobil: +49 179 9087904
[email protected] http://www.beecon.de
Hi Till,
> > The solution for this is using RFCOMM or L2CAP with retransmission and
> > flow control from the Bluetooth 1.2 specification.
> It's been some time since i wrote my rfcomm layer, but i didn't remember
> rfcomm having a sequence number or the like and IMHO it does not have a
> mechanism for retransmission. Or have i really missed something that
> important?
>
> IMHO you can use rfcomm to make the whole transmission reliable, but this
> means, that you have to use acl flow control and make sure, that l2cap/acl
> won't block via rfcomms credit based flow control. Are there other options?
you are still right that RFCOMM uses no sequence numbers and this is
only because it depends on a reliable L2CAP. This said makes my previous
statement looking like non-sense, but actually the RFCOMM credit based
flow control is enough to not screw up the receiver. This is what I've
seen in practice, but I don't have a full proof for it. We know that our
packets will arrive in correct order. The ACL link will take care of
this. We only have to take care of that we don't get more packets than
our receive buffers can take. So the RFCOMM flow control should be
enought to assure this. In general this is a big design mistake in the
Bluetooth protocol stack itself and only L2CAP with retransmission and
flow control can fix it.
Regards
Marcel
-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. http://www.ostg.com
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Marcel,
On Monday 02 August 2004 20:57, Marcel Holtmann wrote:
> Some Bluetooth stacks emulate L2CAP flow control with the flow control
> of the HCI layer, but this is more bad than dropping a packet. Actually
> this is the reason why most mobiles phones don't support more than one
> ACL at the same time.
Hmm ... you are right. I have been implementing l2cap and have never really
faced this problem. In fact i have been using HCI layer flow control to have
a reliable L2CAP layer and thus, one blocking L2CAP client will affect all
clients.
> The solution for this is using RFCOMM or L2CAP with retransmission and
> flow control from the Bluetooth 1.2 specification.
It's been some time since i wrote my rfcomm layer, but i didn't remember
rfcomm having a sequence number or the like and IMHO it does not have a
mechanism for retransmission. Or have i really missed something that
important?
IMHO you can use rfcomm to make the whole transmission reliable, but this
means, that you have to use acl flow control and make sure, that l2cap/acl
won't block via rfcomms credit based flow control. Are there other options?
Thanks for your hints so far.
Till
--
Dr.-Ing. Till Harbaum Tel.: +49 721 4998963
BeeCon GmbH Fax: +49 721 4998962
Haid-und-Neu Strasse 7, 76131 Karlsruhe Mobil: +49 179 9087904
[email protected] http://www.beecon.de
-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. http://www.ostg.com
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Till,
> i have been using bluez l2cap for quite some time now. To my BlueMP3 receiver
> i have streamed gigabytes via l2cap with no problems using bluez as a sender
> so far.
>
> A customer of mine now told me, that l2cap under bluez is unrealible. It was
> hard to believe, but the follwing archive contains to little programs i wrote
> to verify this. It's a sender and a (artifically slowed down) receiver:
>
> http://www.harbaum.org/till/l2flow.tgz
>
> The sender is marking the packets with some sequence number. After about
> 80kBytes the receiver starts complaining about missing sequence numbers.
> Since i can stream to my won hardware (and successfully slowing down the
> transmission, since the receiving mp3 decoder is only taking the data at the
> appropriate bandwidth) i am sure that sending data with bluez is not the
> problem. However the receiver seems to fetch all packets from its bluetooth
> hardware and is dropping packets if it then sees, that it has run out of
> internal buffers.
>
> Why is that? Can this be avoided? Is this by purpose?
the L2CAP of the Bluetooth 1.1 specification has no flow control and so
it can't be fully reliable. See the comment the l2cap.c source code:
/* If socket recv buffers overflows we drop data here
* which is *bad* because L2CAP has to be reliable.
* But we don't have any other choice. L2CAP doesn't
* provide flow control mechanism. */
Some Bluetooth stacks emulate L2CAP flow control with the flow control
of the HCI layer, but this is more bad than dropping a packet. Actually
this is the reason why most mobiles phones don't support more than one
ACL at the same time.
The solution for this is using RFCOMM or L2CAP with retransmission and
flow control from the Bluetooth 1.2 specification.
Regards
Marcel
-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. http://www.ostg.com
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel