Hi Anderson,
> > 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?
this does not look clean to me. And we might have an internal MTU
variable as part of L2CAP, but the way how it gets set and thus its
semantic differs clearly between BR/EDR and LE. So shoehorning an
existing socket option this is clearly a bad idea.
Regards
Marcel
--
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
