From owner-freebsd-bluetooth@FreeBSD.ORG Mon Oct 25 18:23:07 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 8BB911065670 for ; Mon, 25 Oct 2010 18:23:07 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 3EB1C8FC12 for ; Mon, 25 Oct 2010 18:23:06 +0000 (UTC) Received: by gxk9 with SMTP id 9so265250gxk.13 for ; Mon, 25 Oct 2010 11:23:06 -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=D6RqIJ2xkcx0dwbxeHNvlAEAtMEqUCs6noyfnd3oako=; b=XuLCBdeEWdYE07o75GR+JevVtuQ8JsKgE3nMxQXddEgliPbOjhJWxtTV9Tmm3Xxnvp UkSx7N6I4WIx+S6aQumrqNgYLPD/mNXRuxAKMLfbNqbKhz8wMFlesX1C7qtzJkMaOlzp w4Pr4RaaNKaNzaWsp4q5fd5FUx8ypoufhz+3Y= 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=iNZXW8WSDjwJ0IdRJMrvjQQkOp9lW5utDoj2EZSVNxxP2OqcYtX1eRzDa22BI4dLI4 W023l2oFcSjqAz3fnspNcp0l12J++U7s47QR7wUVPqYhhIV6+E/quyDnlx0w8OUCaLo0 xgIQgOzkTtFCUbVGf6BXpw92HME3HUetUDf3w= MIME-Version: 1.0 Received: by 10.42.179.130 with SMTP id bq2mr1704251icb.427.1288030986029; Mon, 25 Oct 2010 11:23:06 -0700 (PDT) Received: by 10.231.191.206 with HTTP; Mon, 25 Oct 2010 11:23:05 -0700 (PDT) In-Reply-To: <1287909035.704733.393.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> Date: Mon, 25 Oct 2010 11:23:05 -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 18:23:07 -0000 On Sun, Oct 24, 2010 at 1:30 AM, Iain Hibbert 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