[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [bluetooth-dev] l2cap





> -----Original Message-----
> From: Gordon McNutt [mailto:gmcnutt@xxxxxxx.com]
> Sent: den 7 december 2000 19:46
> To: Mattias Ågren
> Cc: bluetooth-dev@xxxxxxx.com
> Subject: Re: [bluetooth-dev] l2cap
> 
> 
> Mattias Ågren wrote:
> 
> > > 3. If I read the spec correctly L2CAP needs to perform 
> segmentation.
> > > Currently it just drops packets too big for the MTU. Any 
> plans to fix
> > > this soon?
> > >
> >
> > The segmentation is not done from upper layers down to 
> l2cap, it is done from l2cap down to HCI/LMP.
> 
> After staring at the spec for a while here's my 
> interpretation. The local L2CAP exposes the peer L2CAP's MTU 
> to the upper layers. Upper layers must limit their packet 
> sizes to fit this limit. The baseband packet size can be less than
> this MTU. In cases where the upper layer data fits within the 
> MTU, but not the basband packet size, L2CAP must segment. Sound right?
> 

Exactly.

> So l2cap.c is correct to drop the packet. But it doesn't seem 
> to check the baseband packet size.
> 

I'm not quite sure of what you mean, as far as I can see we do this.

For outgoing l2cap data, the data is segmented into chunks determined from reading buffer sizes when initiating the stack (send_acl_packet() in hci.c)
When parsing incoming data we wait for a complete l2cap packet and then check the received l2cap packet size versus l2cap->local_mtu which is what the peer has agreed on. 

brgds
/Mattias
-
To unsubscribe from this list: send the line "unsubscribe bluetooth-dev" in
the body of a message to majordomo@xxxxxxx.com