On Mon, Oct 25, 2010 at 4:39 PM, Maksim Yevmenkin <[email protected]> wrote: > On Mon, Oct 25, 2010 at 2:38 PM, Iain Hibbert <[email protected]> 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 _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bluetooth To unsubscribe, send any mail to "[email protected]"
