Date: Fri, 22 Oct 2010 10:12:48 +0100 (BST) From: Iain Hibbert <plunky@rya-online.net> To: Maksim Yevmenkin <maksim.yevmenkin@gmail.com> Cc: freebsd-bluetooth@freebsd.org Subject: Re: obexapp get failure Message-ID: <1287738768.915002.8520.nullmailer@galant.ukfsn.org> In-Reply-To: <1287732977.227959.8695.nullmailer@galant.ukfsn.org> References: <1287509041.022618.4884.nullmailer@galant.ukfsn.org> <AANLkTimVZRNp8oh9%2BVQ6rPbXXFjdNqpgSQ2AqWjqATJY@mail.gmail.com> <1287561876.893861.6837.nullmailer@galant.ukfsn.org> <AANLkTi=V8pm51C4D58KRsiz0FfhOiU=NnUYGQJdeUwxA@mail.gmail.com> <1287732977.227959.8695.nullmailer@galant.ukfsn.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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?
iain
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1287738768.915002.8520.nullmailer>