Hi Pavan, * Pavan Savoy <pavan_savoy@xxxxxxxxxxx> [2010-04-14 02:54:00 +0530]: > > --- On Wed, 14/4/10, Gustavo F. Padovan <gustavo@xxxxxxxxxxx> wrote: > > > From: Gustavo F. Padovan <gustavo@xxxxxxxxxxx> > > Subject: Re: l2cap connection id in user-space > > To: "Pavan Savoy" <pavan_savoy@xxxxxxxxxxx> > > Cc: linux-bluetooth@xxxxxxxxxxxxxxx, shitiz_kumar@xxxxxx > > Date: Wednesday, 14 April, 2010, 2:49 AM > > Hi Pavan, > > > > * Pavan Savoy <pavan_savoy@xxxxxxxxxxx> > > [2010-04-14 02:26:41 +0530]: > > > > > Is there a possibility as of now for me to extract the > > l2cap connection ID into my application ? > > > > bluez-hcidump does that. Look to its source code to learn > > how. > > Yeah, correct, it does. > However for that wouldn't I have to set filter for all ACL (or L2CAP) packets to even start receiving ACL (or L2CAP) packets ? > strip off the l2cap_hdr and then get the channel ID from it. > > I was more or less looking to add in 1 more getsockopt option to specifically request for the l2cap_hdr ? (like the imtu/omtu which happens currently). > Wouldn't this be the right way ? No, we do not want such info on getsockopt. If you do that you'll have to mantain it by yourself, which is not a good idea. The cid is L2CAP specific, upper layers should not care about it. > > > > > > > I require 2 sets of information about an L2CAP > > connection in my bluetooth application, I require the > > connection ID on connection to a remote headset/sink, and > > also the maximum packet size for that connection (which I > > think is the MTU, I can get via the getsockopt). > > > > > -- Gustavo F. Padovan http://padovan.org -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
