Re: How to change default MTU for Obex over L2CAP

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

 



On Tue, Oct 31, 2017 at 7:09 PM, Luiz Augusto von Dentz
<luiz.dentz@xxxxxxxxx> wrote:
> Hi Sathish,
>
> On Tue, Oct 31, 2017 at 3:24 PM, Sathish Narasimman
> <nsathish41@xxxxxxxxx> wrote:
>> Hi Luiz,
>>
>> On Tue, Oct 31, 2017 at 3:03 PM, Luiz Augusto von Dentz
>> <luiz.dentz@xxxxxxxxx> wrote:
>>> 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.
>>>
>> Yes I am using OBEX over L2CAP(where trying to send file to another
>> Linux system using obexctl tool it uses GOEP)
>>
>> 1. Please let me know how to change the OBEX maximum packet length
>> when receiving file (i.e In OBEX response code: Success, Maximum
>> packet length is 672 - Logs)
>> btmon Log: https://pastebin.com/BvVERsfq
>> 2. How to change the Default L2CAP MTU. In logs for configure
>> response, the MTU is 672.
>> 3. I am not able to see any logs in obexd when File is received.
>
> It is requesting 32K:
>
> < ACL Data TX: Handle 256 flags 0x00 dlen 27
>             [hci0] 43.021610
>       L2CAP: Configure Request (0x04) ident 7 len 19
>         Destination CID: 64
>         Flags: 0x0000
>         Option: Maximum Transmission Unit (0x01) [mandatory]
>           MTU: 32767
>         Option: Retransmission and Flow Control (0x04) [mandatory]
>           Mode: Enhanced retransmission (0x03)
>           TX window size: 63
>           Max transmit: 3
>           Retransmission timeout: 2000
>           Monitor timeout: 12000
>           Maximum PDU size: 1009
>> ACL Data RX: Handle 256 flags 0x02 dlen 23                                       [hci0] 43.023856
>       L2CAP: Configure Request (0x04) ident 4 len 15
>         Destination CID: 65
>         Flags: 0x0000
>         Option: Retransmission and Flow Control (0x04) [mandatory]
>           Mode: Enhanced retransmission (0x03)
>           TX window size: 63
>           Max transmit: 3
>           Retransmission timeout: 2000
>           Monitor timeout: 12000
>           Maximum PDU size: 1009
>
> I guess because there is no MTU in the remote request we respond with 672:
>
> < ACL Data TX: Handle 256 flags 0x00 dlen 29
>             [hci0] 43.023870
>       L2CAP: Configure Response (0x05) ident 4 len 21
>         Source CID: 64
>         Flags: 0x0000
>         Result: Success (0x0000)
>         Option: Maximum Transmission Unit (0x01) [mandatory]
>           MTU: 672
>         Option: Retransmission and Flow Control (0x04) [mandatory]
>           Mode: Enhanced retransmission (0x03)
>           TX window size: 63
>           Max transmit: 3
>           Retransmission timeout: 2000
>           Monitor timeout: 12000
>           Maximum PDU size: 1009
>> ACL Data RX: Handle 256 flags 0x02 dlen 29                                       [hci0] 43.028883
>       L2CAP: Configure Response (0x05) ident 7 len 21
>         Source CID: 65
>         Flags: 0x0000
>         Result: Success (0x0000)
>         Option: Maximum Transmission Unit (0x01) [mandatory]
>           MTU: 32767
>         Option: Retransmission and Flow Control (0x04) [mandatory]
>           Mode: Enhanced retransmission (0x03)
>           TX window size: 63
>           Max transmit: 3
>           Retransmission timeout: 2000
>           Monitor timeout: 12000
>           Maximum PDU size: 1009
>
> I guess this will result in 32K omtu and 672 imtu, though Im not sure
> if the PDU size are correct either. Have tried transfering anything to
> see what is the actual payload we can carry over this channel. Btw
> keep in mind OBEX channel is using ERTM the other channels like SDP
> will have their own MTU, most likely 672.
>
Hi Luiz,

Yes, the the omtu is 32k and imtu is still 672.
I can see logs printed in obexd during TX. When running the obexd with
"sudo GOBEX_DEBUG=all ./obexd/src/obexd"
But why I am not able to see any logs for RX i.e Input files received.
May I know where the receive RX is handled?



>> Thanks,
>> Sathish N
>>
>>>>
>>>>>https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/obexd/client/bluetooth.c#n457
>>>>> --
>>>>> Luiz Augusto von Dentz
>>>
>>>
>>>
>>> --
>>> 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



[Index of Archives]     [Bluez Devel]     [Linux Wireless Networking]     [Linux Wireless Personal Area Networking]     [Linux ATH6KL]     [Linux USB Devel]     [Linux Media Drivers]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Big List of Linux Books]

  Powered by Linux