From owner-freebsd-bluetooth@FreeBSD.ORG Mon Oct 25 23:39:19 2010 Return-Path: Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 09758106564A for ; Mon, 25 Oct 2010 23:39:19 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id BA8F48FC19 for ; Mon, 25 Oct 2010 23:39:18 +0000 (UTC) Received: by iwn39 with SMTP id 39so4984766iwn.13 for ; Mon, 25 Oct 2010 16:39:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=+ZcCTTOkPrC7Vxam8WvKcmHfPAQrLRxIdp61FYUPufE=; b=TQh13agIT5SszWusOPDInF7ydZ1HvDAKZGCUZg4Otu/lht/b84KrTpi6bHCyZL8jDv Nv1MHBrlYyZGqxqJl9pYO47aL6vDbjfPy9D4b2n7E5Autn46cmE0GYEE3qx/+xqk0hEX yqJcgatIESZoiyTgJZ1LMqTYZHEgoHR95Rtzs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=cnl2fLC1bS1uuL3iXnx+logdQwe0z32ApFJ2gU8H1D/eczpu7C9nLRrt/Ezlc3LM9U xpOnMYluVboDNLhSdyhtBXSyMyST9n4xUzV92c55nggfkYkxfbge9W3VIaMZvbdcJ8QC CBhw1Aezb+TMLFl7TQV8741lUKF/mLW1cV+kA= MIME-Version: 1.0 Received: by 10.42.193.209 with SMTP id dv17mr5684757icb.367.1288049958060; Mon, 25 Oct 2010 16:39:18 -0700 (PDT) Received: by 10.231.191.206 with HTTP; Mon, 25 Oct 2010 16:39:18 -0700 (PDT) In-Reply-To: <1288042690.562160.2361.nullmailer@galant.ukfsn.org> References: <1287509041.022618.4884.nullmailer@galant.ukfsn.org> <1287561876.893861.6837.nullmailer@galant.ukfsn.org> <1287732977.227959.8695.nullmailer@galant.ukfsn.org> <1287738768.915002.8520.nullmailer@galant.ukfsn.org> <1287857292.298365.1038.nullmailer@galant.ukfsn.org> <1287874077.365931.1417.nullmailer@galant.ukfsn.org> <1287909035.704733.393.nullmailer@galant.ukfsn.org> <1288042690.562160.2361.nullmailer@galant.ukfsn.org> Date: Mon, 25 Oct 2010 16:39:18 -0700 Message-ID: From: Maksim Yevmenkin To: Iain Hibbert Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-bluetooth@freebsd.org Subject: Re: obexapp get failure X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2010 23:39:19 -0000 On Mon, Oct 25, 2010 at 2:38 PM, Iain Hibbert 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