obexapp get failure

[Maksim Yevmenkin]

On Mon, Oct 25, 2010 at 2:38 PM, Iain Hibbert <plunky at 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.

thanks,
max