Re: [PATCH] Bluetooth: Fix not clearing ack timer when sending an i-frame

[Ulisses Furquim <ulisses@profusion.mobi>]

Hi Luiz,

On Tue, Feb 7, 2012 at 11:28 AM, Luiz Augusto von Dentz
<luiz.dentz@gmail.com> wrote:
> Hi Ulisses,
>
> On Tue, Feb 7, 2012 at 2:37 PM, Ulisses Furquim <ulisses@profusion.mobi> wrote:
>>> Well, if ack timer is running we have sth to ack. Isn't that enough?
>>
>> That should be the case. When ack timer is running we have something
>> to ack. The point is answering if we still have pending acks to send.
>> And that's being answered by the return of calling l2cap_ertm_send()
>> which was wrong until now and I don't think it's a good idea. Marcel,
>> any opinions on that? Luiz?
>
> For now I would just try to fix current code upstream without changing
> too much the logic and risk more regressions. Im afraid we gonna have
> to change quite a bit ertm code for next releases but we have
> obexd/obex-client to test regressions so it should be easier to test
> this code, so perhaps Szymon fix should be applied before its too late
> to do a pull request.

Another valid point. I'm ok with Szymon fix for now if we revisit this
when changing ERTM code for next releases. It does need some love.

> Btw, here is what Ive been using to test this code:
>
>> obexd/tools/test-server -b -c 4097 -p -i 32767 -o 32767
>
>> obexd/tools/test-client -b -s <address of source adapter> -d <address of destination adapter> -c 4097 -p -i 32767 -o 32767

Ok. Are you running them on the same machine with 2 dongles?

> Im using 32767 as MTU because that is what we use by default in OBEX,
> but currently it doesn't work due to some bug in ERTM that apparently
> doesn't handle MTU being bigger than mts * tx_win, so the transfer
> just stall at some point, using something like 16384 works though.

Does it stall forever? I have no idea what might be this one.

Regards,

-- 
Ulisses Furquim
ProFUSION embedded systems
http://profusion.mobi
Mobile: +55 19 9250 0942
Skype: ulissesffs