Hi Ulisses, On Tue, Feb 7, 2012 at 3:45 PM, Ulisses Furquim <ulisses@xxxxxxxxxxxxxx> wrote: >> 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? Yep >> 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. It timeout after 10 seconds than the client disconnects, but I don't think it would recover even after that since basically each side does ack with s-frame RR and nothing else happen. I suspect we are going past what a window could carry (tx_win (63) * mts (300)) because the MTU is bigger than that the sdu_len can be bigger too, afaik this would have to be fragmented in different window or perhaps the mts size should be adjusted too, but lets figure out this in another thread to avoid too much noise here. -- 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
