Hi Marcel,
On Tue, Apr 12, 2011 at 12:06 AM, Marcel Holtmann <marcel@xxxxxxxxxxxx> wrote:
> so how do you expect this to work exactly? In BR/EDR L2CAP you set the
> MTU details before calling connect(). With LE you expect to be connected
> and then tell the kernel what the limits actually are?
Yes. For LE, the MTU negotiation happens over the connected link
(using specific ATT commands).
> This sounds highly convoluted. And especially hijacking the existing
> command for it seems wrong. Using l2cap_sock_setsockopt_old() might have
> given it away that it is a bad idea to re-use that socket option for a
> new technology ;)
>
> So the real fact here is that the MTU handling/negotiation for BR/EDR
> and LE are different. Nothing is going to change this. So this should be
> also different from a socket option point of view.
One thing to consider is that there are a couple of MTU checks along
the L2CAP code. The issue which originated this patch is code such as:
/* Check outgoing MTU */
if (len > pi->omtu) {
err = -EMSGSIZE;
goto done;
}
We understood that just letting omtu/imtu values on kernel reflect the
current connection MTU settings was the cleanest solution. What do you
propose? Bypassing these checks for LE?
Regards,
--
Anderson Lizardo
Instituto Nokia de Tecnologia - INdT
Manaus - Brazil
--
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
