Hi Sathish, On Tue, Oct 31, 2017 at 11:27 AM, Sathish Narasimman <nsathish41@xxxxxxxxx> wrote: > Hi Luiz, > > On Tue, Oct 31, 2017 at 12:53 PM, Luiz Augusto von Dentz > <luiz.dentz@xxxxxxxxx> wrote: >> Hi Sathish, >> >> On Tue, Oct 31, 2017 at 9:05 AM, Luiz Augusto von Dentz >> <luiz.dentz@xxxxxxxxx> wrote: >>> Hi Sathish, >>> >>> On Tue, Oct 31, 2017 at 5:30 AM, Sathish Narasimman >>> <nsathish41@xxxxxxxxx> wrote: >>>> Hi, >>>> >>>> I am trying to do an OPP transfer between 2 Linux bluez system. >>>> It is always selecting the 672 MTU size during configuration. >>>> >>>> May I please know how to change the MTU size. >>> >>> It looks like for L2CAP we don't set the MTU properly but for RFCOMM we do: >>> >>> https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/obexd/client/bluetooth.c#n129 >>> >>> I will send a patch in a moment. >> >> Actually, it is the other way around, the RFCOMM don't actually >> support setting the MTU since it is a stream, though we should >> probably adjust the socket buffer size since we are using 32k for >> OBEX. > > Though I was trying to change the value for OBEX over L2CAP > > Does this have the effect of OBEX maximum packet length? > In which the maximum packet length parameter is always 672. > > Here the Default 32K omtu is changed to 672 at this point > https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/obexd/client/bluetooth.c#n468 That should never be reached in case of RFCOMM since it is not packet based, or are you really using OBEX over L2CAP aka. GOEP 2.0, that should be using 32K but we should check the HCI traces if that is actually what is negotiated. > >>https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/obexd/client/bluetooth.c#n457 >> -- >> Luiz Augusto von Dentz -- Luiz Augusto von Dentz -- 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
