Re: [Bluez-devel] L2CAP dropping packets on BlueZ based receiver

[Marcel Holtmann <marcel@holtmann.org>]

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. www.ostg.com
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel