Date: Mon, 25 Oct 2010 17:09:20 -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: <AANLkTinADNrrNLcv964SSds_Ftt-a0uJ5S_3_mBtrbVL@mail.gmail.com> In-Reply-To: <AANLkTik%2BBvzyHp_u9iwdT8wG9AMG4eysnFoDvkY5amj4@mail.gmail.com> 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> <AANLkTimUBf8ALdpe2JHsS%2BQji-Pf_Ym1BuefCsOVLnHr@mail.gmail.com> <1288042690.562160.2361.nullmailer@galant.ukfsn.org> <AANLkTik%2BBvzyHp_u9iwdT8wG9AMG4eysnFoDvkY5amj4@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Oct 25, 2010 at 4:39 PM, Maksim Yevmenkin
<maksim.yevmenkin@gmail.com> wrote:
> On Mon, Oct 25, 2010 at 2:38 PM, Iain Hibbert <plunky@rya-online.net> wrote:
>> On Mon, 25 Oct 2010, Maksim Yevmenkin wrote:
>>
>>> 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
>>
>> Well, that works fine naturally and shows nothing interesting alas. What
>> is more revealing is if I use wm6 to issue a multi-GET from obexapp server
>> (which does work fine)
>>
>>> ACL data: handle 13 flags 0x02 dlen 42
>> L2CAP(d): cid 0x0044 len 38 [psm 3]
>> RFCOMM(d): UIH: cr 1 dlci 20 pf 1 ilen 33 fcs 0x2d credits 1
>> OBEX: Get cmd(f): len 33
>> Connection ID (0xcb) = 1
>> 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 58
>> L2CAP(d): cid 0x00b8 len 54 [psm 3]
>> RFCOMM(d): UIH: cr 0 dlci 20 pf 0 ilen 50 fcs 0xeb
>> OBEX: Get rsp(f): status 100 len 4096
>> Status 100 = Continue
>> Length (0xc3) = 65529
>> Body (0x48) = Sequence length 4085
>> 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
>> [...]
>> 0fe0: 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 aaaaaaaaaaaaaaaa
>> 0ff0: 61 61 61 61 61 aaaaa
>>
>> so the Get command starts and we return the first segment with status 100
>> (Continued)
>>
>>> ACL data: handle 13 flags 0x02 dlen 17
>> L2CAP(d): cid 0x0044 len 13 [psm 3]
>> RFCOMM(d): UIH: cr 1 dlci 20 pf 1 ilen 8 fcs 0x2d credits 2
>> OBEX: Get cmd(f): len 8 (continue)
>> Connection ID (0xcb) = 1
>>
>> < ACL data: handle 13 flags 0x02 dlen 58
>> L2CAP(d): cid 0x00b8 len 54 [psm 3]
>> RFCOMM(d): UIH: cr 0 dlci 20 pf 0 ilen 50 fcs 0xeb
>> OBEX: Get rsp(f): status 100 len 4096
>> Status 100 = Continue
>> Body (0x48) = Sequence length 4090
>> 0000: 61 61 61 61 61 61 61 61 0a 61 61 61 61 61 61 61 aaaaaaaa.aaaaaaa
>> 0010: 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 aaaaaaaaaaaaaaaa
>> [...]
>> 0fe0: 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 aaaaaaaaaaaaaaaa
>> 0ff0: 61 61 61 61 61 61 61 61 61 61 aaaaaaaaaa
>>
>> and wm6 phone issues a Get continuation cmd as it should, but it does
>> always put the Connection ID in the packet. [and this repeats quite a few
>> times]
>
> [...]
>
> i see
>
>> until the final segment where we return 200 as normal
>>
>> So, I think there is a good chance that the phone is losing because there
>> is no Connection ID included.. it seems to be allowed (but not required)
>> by the spec to include such a thing but I find openobex documentation (!)
>> to be more or less incomprehensible and I don't even see how that packet
>> is being generated..
>
> i'm pretty sure that is what it is. can you please try the patch
> below. this is completely untested :) no idea what it will do.
>
> beetle% cvs diff -u
> cvs diff: Diffing .
> Index: stream.c
> ===================================================================
> RCS file: /usr/local/cvs/ports/obexapp/stream.c,v
> retrieving revision 1.10
> diff -u -r1.10 stream.c
> --- stream.c 22 Oct 2010 17:04:11 -0000 1.10
> +++ stream.c 25 Oct 2010 23:36:11 -0000
> @@ -230,6 +230,12 @@
>
> context->stotal += length;
> log_debug("%s(): Wrote %d bytes of stream data", __func__, length);
> +
> + if (context->connection_id != OBEXAPP_INVALID_CONNECTION_ID) {
> + hv.bq4 = context->connection_id;
> + OBEX_ObjectAddHeader(handle, object,
> + OBEX_HDR_CONNECTION, hv, sizeof(hv.bq4), 0);
> + }
> } /* obexapp_stream_read */
>
> void
>
> ==
>
> in any case, openobex library generates continue packets.
i'm convinced that there is a bug in obexapp (or, less likely,
openobex library). it appears that "connection id" header is intended
for multiplexing of several data streams. its pretty much analog of
http "host" header. i think its clear what "connection id" header must
be present on all requests from the client, including continue-GET
request. what is not entirely clear if the server responses should
also contain "connection id" header. i think they should as well.
clearly, wm6 server is not sending "connection id" header back in its
responses, so perhaps its a double whammy.
thanks,
max
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTinADNrrNLcv964SSds_Ftt-a0uJ5S_3_mBtrbVL>