Date: Mon, 25 Oct 2010 11:23:05 -0700 From: Maksim Yevmenkin <maksim.yevmenkin@gmail.com> To: Iain Hibbert <plunky@rya-online.net> Cc: freebsd-bluetooth@freebsd.org Subject: Re: obexapp get failure Message-ID: <AANLkTimUBf8ALdpe2JHsS%2BQji-Pf_Ym1BuefCsOVLnHr@mail.gmail.com> In-Reply-To: <1287909035.704733.393.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> <1287738768.915002.8520.nullmailer@galant.ukfsn.org> <AANLkTi=iHT9WOVuNq_VFfWo6R3J1ynkhGBV0s6VkS_Uw@mail.gmail.com> <1287857292.298365.1038.nullmailer@galant.ukfsn.org> <AANLkTinU1YpT=kVNHH28fkG2UuMdaRKNWzSmTa4Nq77K@mail.gmail.com> <1287874077.365931.1417.nullmailer@galant.ukfsn.org> <1287909035.704733.393.nullmailer@galant.ukfsn.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Oct 24, 2010 at 1:30 AM, Iain Hibbert <plunky@rya-online.net> wrote:
> On Sat, 23 Oct 2010, Iain Hibbert wrote:
>
>> I don't know the OBEX protocol, to say which end is not working correctly?
>
> Hmm, looking at OBEX13.pdf section "3.3.4 Get" I see
>
> | A typical multi-step GET operation proceeds as follows: the client sends
> | a GET request that may include a Name header; server responds with 0x90
> | (Continue) and headers describing the name and size of the object to be
> | returned. Seeing the Continue response code, the client sends another
> | GET request (with final bit set and no new headers) asking for
> | additional data, and the server responds with a response packet
> | containing more headers (probably Body Headers) along with another
> | Continue response code. As long as the response is Continue, The client
> | continues to issue GET requests until the final body information (in an
> | End-of-Body header) arrives, along with the response code 0xA0 Success.
>
> and from the dump I attached last night
>
> < ACL data: handle 13 flags 0x02 dlen 40
> L2CAP(d): cid 0x00ab len 36 [psm 3]
> RFCOMM(d): UIH: cr 1 dlci 8 pf 1 ilen 31 fcs 0x46 credits 3
> OBEX: Get cmd(f): len 31
> Connection ID (0xcb) = 43
> Name (0x01) = Unicode length 20
> 0000: 00 74 00 65 00 73 00 74 00 2e 00 38 00 31 00 39 .t.e.s.t...8.1.9
> 0010: 00 34 00 00 .4..
>
>> ACL data: handle 13 flags 0x02 dlen 40
> L2CAP(d): cid 0x0044 len 36 [psm 3]
> RFCOMM(d): UIH: cr 0 dlci 8 pf 0 ilen 32 fcs 0x80
> OBEX: Get rsp(f): status 100 len 4096
> Status 100 = Continue
> Body (0x48) = Sequence length 4090
> 0000: 58 58 58 58 58 58 58 58 58 58 58 58 58 58 58 58 XXXXXXXXXXXXXXXX
> 0010: 58 58 58 58 58 58 58 58 58 58 58 58 58 58 58 58 XXXXXXXXXXXXXXXX
> [...]
> 0fe0: 58 58 58 58 58 58 58 58 58 58 58 58 58 58 58 58 XXXXXXXXXXXXXXXX
> 0ff0: 58 58 58 58 58 58 58 58 58 58 XXXXXXXXXX
>
> < ACL data: handle 13 flags 0x02 dlen 12
> L2CAP(d): cid 0x00ab len 8 [psm 3]
> RFCOMM(d): UIH: cr 1 dlci 8 pf 1 ilen 3 fcs 0x46 credits 5
> OBEX: Get cmd(f): len 3 (continue)
>
> and even hcidump assumes that this Get is a continuation .. the only thing
> I can think of is that this Get does not include the "Connection ID"
> and/or the "Name" fields.. should it? The above paragraph does not
> explicitly state that the continuation Get request should be empty (though
> example in section "7.2 Simple Get" does show empty Get) and when we later
> send a Get with these fields, the phone ignores the contents and instead
> persists sending the original file until it is complete..
yes, i agree. there is something fishy going on at server (wm6) side.
obexapp terminates transfer because it sees
> 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
i.e. 500 status code response from wm6 server. oddly enough, as you
pointed out, wm6 server continues to send chunks of body even though
it had previously told client to go away, i.e. 500 response. weird....
> I don't see how to change that to add the connection id though, any ideas?
not really. the way i read the spec, connection id header is not
required on 'continue GET' however, wm6 server might require it (for
some reason). i'd like to see PUT dump, i.e. what does wm6 server
sends back in 'continue' when obexapp does multi-PUT
thanks
max
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTimUBf8ALdpe2JHsS%2BQji-Pf_Ym1BuefCsOVLnHr>