obexapp get failure

Maksim Yevmenkin maksim.yevmenkin at gmail.com
Fri Oct 22 17:01:54 UTC 2010


On Fri, Oct 22, 2010 at 2:12 AM, Iain Hibbert <plunky at rya-online.net> wrote:
> On Fri, 22 Oct 2010, Iain Hibbert wrote:
>
>> I have one bug-report that I haven't looked into properly, not sure if its
>> obexapp or my phone (windows mobile 6) that is the problem..  if I connect
>> to FTRN on phone, using folder browsing service and try GET on a larger
>> file it fails and loses sync. I've done some tests and the largest file I
>> can GET is 65528 bytes (can send larger files from either side no problem)
>>
>> for example with two files (that are text files full of 'a')
>>
>> % obexapp -a touch -C ftrn -f
>> obex> ls
>> Access    Owner    Group    Size       Modified         Name
>>                                                         ..
>>           n/a      n/a      65528      n/a              test.small
>>           n/a      n/a      65529      n/a              test.large
>> Success, response: OK, Success (0x20)
>> obex> get test.small
>> 65528 bytes streamed in 4 seconds (16382 bytes/sec)
>> Success, response: OK, Success (0x20)
>> obex> get test.large
>> Failure, response: Unknown response (0x53)
>> obex> ls
>> Access    Owner    Group    Size       Modified         Name
>> Could not parse XML: (null)
>> Success, response: OK, Success (0x20)
>> obex> ls
>> Access    Owner    Group    Size       Modified         Name
>>                                                         ..
>>           n/a      n/a      65528      n/a              test.small
>>           n/a      n/a      65529      n/a              test.large
>> Success, response: OK, Success (0x20)
>> obex> get test.small
>> 65528 bytes streamed in 3 seconds (21842 bytes/sec)
>> Success, response: OK, Success (0x20)
>> obex> dis
>> Success, response: OK, Success (0x20)
>>
>> I guess its something to do with a uint16_t and a small amount of header
>> but I've no time to look at that until early next week..
>
> looking at the hcidump output for the test.large transaction,
>
> < ACL data: handle 13 flags 0x02 dlen 42
>    L2CAP(d): cid 0x0089 len 38 [psm 3]
>      RFCOMM(d): UIH: cr 1 dlci 8 pf 1 ilen 33 fcs 0x46 credits 6
>        OBEX: Get cmd(f): len 33
>        Connection ID (0xcb) = 27
>        Name (0x01) = Unicode length 22
>        0000: 00 74 00 65 00 73 00 74  00 2e 00 6c 00 61 00 72  .t.e.s.t...l.a.r
>        0010: 00 67 00 65 00 00                                 .g.e..
>
>> ACL data: handle 13 flags 0x02 dlen 11
>    L2CAP(d): cid 0x0044 len 7 [psm 3]
>      RFCOMM(d): UIH: cr 0 dlci 8 pf 0 ilen 3 fcs 0x80
>        OBEX: Get rsp(f): status 100 len 65535
>        Status 100 = Continue
>        Body (0x48) = Sequence length 65529
>        0000: 61 61 61 61 61 61 61 61  61 61 61 61 61 61 61 61  aaaaaaaaaaaaaaaa
>        0010: 61 61 61 61 61 61 61 61  61 61 61 61 61 61 61 61  aaaaaaaaaaaaaaaa
>        0020: 61 61 61 61 61 61 61 61  61 61 61 61 61 61 61 61  aaaaaaaaaaaaaaaa
> [...]
>        ffc0: 61 61 61 61 61 61 61 61  61 61 61 61 61 61 61 61  aaaaaaaaaaaaaaaa
>        ffd0: 61 61 61 61 61 61 61 61  61 61 61 61 61 61 61 61  aaaaaaaaaaaaaaaa
>        ffe0: 61 61 61 61 61 61 61 61  61 0a 61 61 61 61 61 61  aaaaaaaaa.aaaaaa
>        fff0: 61 61 61 61 61 61 61 61  0a                       aaaaaaaa.
>
> < ACL data: handle 13 flags 0x02 dlen 12
>    L2CAP(d): cid 0x0089 len 8 [psm 3]
>      RFCOMM(d): UIH: cr 1 dlci 8 pf 1 ilen 3 fcs 0x46 credits 6
>        OBEX: Get cmd(f): len 3 (continue)
>
>> ACL data: handle 13 flags 0x02 dlen 11
>    L2CAP(d): cid 0x0044 len 7 [psm 3]
>      RFCOMM(d): UIH: cr 0 dlci 8 pf 0 ilen 3 fcs 0x80
>        OBEX: Get rsp(f): status 500 len 3
>
> it seems that the wm6 phone tells us that more is to come, so we issue a
> continuation get but the phone is only confused..  I don't know if this is
> done correctly, or can be worked around?

hmmm... interesting....

could you please try to lower obexapp mtu? i.e. use -m command line
switch. try to set to something like 16k-32k and see if it makes any
difference. there is an OBEXAPP_BUFFER_SIZE which is set to 65536 by
default. but, i think, it might be wrong. it probably should be set to
OBEX_MAXIMUM_MTU (which just happens to be set to 65535 in my version
of openobex library).

i did not make any changes in this area recently. i recall doing
torture testing when i was transferring 4mb+ files between 2 unix
machines and between unix and windows machine without any problems.

thanks,
max


More information about the freebsd-bluetooth mailing list