From owner-freebsd-bluetooth@FreeBSD.ORG Sun Oct 24 08:30:22 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 A5A3A1065672 for ; Sun, 24 Oct 2010 08:30:22 +0000 (UTC) (envelope-from plunky@rya-online.net) Received: from smtp5.freeserve.com (smtp5.freeserve.com [193.252.22.128]) by mx1.freebsd.org (Postfix) with ESMTP id 36FD58FC0A for ; Sun, 24 Oct 2010 08:30:21 +0000 (UTC) Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf3411.me.freeserve.com (SMTP Server) with ESMTP id 6528A1C00083; Sun, 24 Oct 2010 10:30:20 +0200 (CEST) Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf3411.me.freeserve.com (SMTP Server) with ESMTP id 56FB71C00086; Sun, 24 Oct 2010 10:30:20 +0200 (CEST) Received: from rya-online.net (unknown [89.194.193.90]) by mwinf3411.me.freeserve.com (SMTP Server) with SMTP id D31091C00083; Sun, 24 Oct 2010 10:30:18 +0200 (CEST) X-ME-UUID: 20101024083018864.D31091C00083@mwinf3411.me.freeserve.com Received: (nullmailer pid 695 invoked by uid 1000); Sun, 24 Oct 2010 08:30:35 -0000 Date: Sun, 24 Oct 2010 09:30:35 +0100 (BST) To: Maksim Yevmenkin In-Reply-To: <1287874077.365931.1417.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> User-Agent: Alpine 2.00 (NEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-Id: <1287909035.704733.393.nullmailer@galant.ukfsn.org> From: Iain Hibbert 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: Sun, 24 Oct 2010 08:30:22 -0000 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.. < ACL data: handle 13 flags 0x02 dlen 47 L2CAP(d): cid 0x00ab len 43 [psm 3] RFCOMM(d): UIH: cr 1 dlci 8 pf 1 ilen 38 fcs 0x46 credits 1 OBEX: Get cmd(f): len 38 Connection ID (0xcb) = 43 Name (0x01) = Unicode length 2 0000: 00 00 .. Type (0x42) = Sequence length 22 0000: 78 2d 6f 62 65 78 2f 66 6f 6c 64 65 72 2d 6c 69 x-obex/folder-li 0010: 73 74 69 6e 67 00 sting. > 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) > 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 503 len 3 < ACL data: handle 13 flags 0x02 dlen 47 L2CAP(d): cid 0x00ab len 43 [psm 3] RFCOMM(d): UIH: cr 1 dlci 8 pf 1 ilen 38 fcs 0x46 credits 1 OBEX: Get cmd(f): len 38 Connection ID (0xcb) = 43 Name (0x01) = Unicode length 2 0000: 00 00 .. Type (0x42) = Sequence length 22 0000: 78 2d 6f 62 65 78 2f 66 6f 6c 64 65 72 2d 6c 69 x-obex/folder-li 0010: 73 74 69 6e 67 00 sting. > ACL data: handle 13 flags 0x02 dlen 28 L2CAP(d): cid 0x0044 len 24 [psm 3] RFCOMM(d): UIH: cr 0 dlci 8 pf 0 ilen 20 fcs 0x80 OBEX: Get rsp(f): status 200 len 20 Status 200 = Success End of Body (0x49) = Sequence length 14 0000: 58 58 58 58 58 58 58 58 58 58 58 58 58 0a XXXXXXXXXXXXX. I don't see how to change that to add the connection id though, any ideas? iain From owner-freebsd-bluetooth@FreeBSD.ORG Mon Oct 25 09:41:17 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 BAD151065670 for ; Mon, 25 Oct 2010 09:41:17 +0000 (UTC) (envelope-from plunky@rya-online.net) Received: from smtp6.freeserve.com (smtp6.freeserve.com [193.252.22.190]) by mx1.freebsd.org (Postfix) with ESMTP id 4FF1A8FC0A for ; Mon, 25 Oct 2010 09:41:16 +0000 (UTC) Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf3614.me.freeserve.com (SMTP Server) with ESMTP id A627E7000082; Mon, 25 Oct 2010 11:41:15 +0200 (CEST) Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf3614.me.freeserve.com (SMTP Server) with ESMTP id 993717000086; Mon, 25 Oct 2010 11:41:15 +0200 (CEST) Received: from rya-online.net (unknown [89.194.147.97]) by mwinf3614.me.freeserve.com (SMTP Server) with SMTP id 41C5C7000082; Mon, 25 Oct 2010 11:41:14 +0200 (CEST) X-ME-UUID: 20101025094114269.41C5C7000082@mwinf3614.me.freeserve.com Received: (nullmailer pid 828 invoked by uid 1000); Mon, 25 Oct 2010 09:41:34 -0000 Date: Mon, 25 Oct 2010 10:41:33 +0100 (BST) To: Maksim Yevmenkin In-Reply-To: References: <1287509041.022618.4884.nullmailer@galant.ukfsn.org> <1287561876.893861.6837.nullmailer@galant.ukfsn.org> User-Agent: Alpine 2.00 (NEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-2135702284-1287999693=:995" Message-Id: <1287999693.989346.1023.nullmailer@galant.ukfsn.org> From: Iain Hibbert Cc: freebsd-bluetooth@freebsd.org Subject: Re: obexapp print stream statistics after transfer 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 09:41:17 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-2135702284-1287999693=:995 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 21 Oct 2010, Maksim Yevmenkin wrote: > thanks for your patches, Iain. please find attached combined patch. > please let me know if this works, and i will commit and release next > version one more suggestion attached: bt_devaddr() is available in recent versions of FreeBSD and perhaps some other OS (OpenBSD at least though I don't see obexapp in their ports tree) so use a different definition to include its use.. (I don't know if you can add something to compat.h for FreeBSD?) iain --0-2135702284-1287999693=:995 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=devaddr.diff Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename=devaddr.diff LS0tIGNvbXBhdC5oLm9yaWcJMjAwNy0wMy0xMiAyMToxOTozMC4wMDAwMDAw MDAgKzAwMDANCisrKyBjb21wYXQuaAkyMDEwLTEwLTI1IDEwOjMwOjU1LjAw MDAwMDAwMCArMDEwMA0KQEAgLTQ0LDYgKzQ0LDggQEANCiAjZGVmaW5lIHJm Y29tbV9jaGFubmVsCQlidF9jaGFubmVsDQogI2RlZmluZSByZmNvbW1fbGVu CQlidF9sZW4NCiAjZGVmaW5lIHJmY29tbV9mYW1pbHkJCWJ0X2ZhbWlseQ0K Kw0KKyNkZWZpbmUgSEFWRV9CVF9ERVZBRERSCQkxDQogI2VuZGlmIC8qIF9f TmV0QlNEX18gKi8NCiANCiAjZW5kaWYgLyogX0NPTVBBVF9IXyAqLw0KLS0t IG1haW4uYy5vcmlnCTIwMTAtMTAtMjIgMDc6Mjk6MDYuMDAwMDAwMDAwICsw MTAwDQorKysgbWFpbi5jCTIwMTAtMTAtMjUgMTA6MzE6MjYuMDAwMDAwMDAw ICswMTAwDQpAQCAtMTM1LDcgKzEzNSw3IEBAIG1haW4oaW50IGFyZ2MsIGNo YXIgKmFyZ3ZbXSkNCiAJCQlicmVhazsNCiANCiAJCWNhc2UgJ0EnOg0KLSNp ZmRlZiBfX05ldEJTRF9fDQorI2lmZGVmIEhBVkVfQlRfREVWQUREUg0KIAkJ CWlmICghYnRfZGV2YWRkcihvcHRhcmcsICZjb250ZXh0LmxhZGRyKSkNCiAJ CQkJZXJyKDEsICIlcyIsIG9wdGFyZyk7DQogI2Vsc2UNCkBAIC0xNDksNyAr MTQ5LDcgQEAgbWFpbihpbnQgYXJnYywgY2hhciAqYXJndltdKQ0KIAkJCQlt ZW1jcHkoJmNvbnRleHQubGFkZHIsIGhlLT5oX2FkZHIsDQogCQkJCQkJc2l6 ZW9mKGNvbnRleHQubGFkZHIpKTsNCiAJCQl9DQotI2VuZGlmIC8qIF9fTmV0 QlNEX18gKi8NCisjZW5kaWYgLyogSEFWRV9CVF9ERVZBRERSICovDQogCQkJ YnJlYWs7DQogDQogCQljYXNlICdjJzogLyogY2xpZW50ICovDQo= --0-2135702284-1287999693=:995-- From owner-freebsd-bluetooth@FreeBSD.ORG Mon Oct 25 11:06:56 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 CB21E10656CF for ; Mon, 25 Oct 2010 11:06:56 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 9DC898FC12 for ; Mon, 25 Oct 2010 11:06:56 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o9PB6udQ088718 for ; Mon, 25 Oct 2010 11:06:56 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o9PB6tLE088716 for freebsd-bluetooth@FreeBSD.org; Mon, 25 Oct 2010 11:06:55 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 25 Oct 2010 11:06:55 GMT Message-Id: <201010251106.o9PB6tLE088716@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-bluetooth@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-bluetooth@FreeBSD.org 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 11:06:56 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- p kern/140590 bluetooth [bluetooth] ng_ubt(4) ng_l2cap_process_cmd_rej warning 1 problem total. 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 From owner-freebsd-bluetooth@FreeBSD.ORG Mon Oct 25 21:37:58 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 679C21065672 for ; Mon, 25 Oct 2010 21:37:58 +0000 (UTC) (envelope-from plunky@rya-online.net) Received: from smtp5.freeserve.com (smtp5.freeserve.com [193.252.22.128]) by mx1.freebsd.org (Postfix) with ESMTP id EAB5F8FC13 for ; Mon, 25 Oct 2010 21:37:57 +0000 (UTC) Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf3419.me.freeserve.com (SMTP Server) with ESMTP id 0F6C11C00081; Mon, 25 Oct 2010 23:37:56 +0200 (CEST) Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf3419.me.freeserve.com (SMTP Server) with ESMTP id 022FD1C0008F; Mon, 25 Oct 2010 23:37:56 +0200 (CEST) Received: from rya-online.net (unknown [89.194.147.97]) by mwinf3419.me.freeserve.com (SMTP Server) with SMTP id A3F121C00081; Mon, 25 Oct 2010 23:37:54 +0200 (CEST) X-ME-UUID: 20101025213754671.A3F121C00081@mwinf3419.me.freeserve.com Received: (nullmailer pid 2974 invoked by uid 1000); Mon, 25 Oct 2010 21:38:10 -0000 Date: Mon, 25 Oct 2010 22:38:10 +0100 (BST) To: Maksim Yevmenkin In-Reply-To: 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> User-Agent: Alpine 2.00 (NEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-Id: <1288042690.562160.2361.nullmailer@galant.ukfsn.org> From: Iain Hibbert 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 21:37:58 -0000 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] > 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 108 L2CAP(d): cid 0x00b8 len 104 [psm 3] RFCOMM(d): UIH: cr 0 dlci 20 pf 0 ilen 100 fcs 0xeb OBEX: Get rsp(f): status 200 len 100 Status 200 = Success End of Body (0x49) = Sequence length 94 0000: 61 61 61 61 61 61 61 61 61 61 61 61 61 0a 61 61 aaaaaaaaaaaaa.aa 0010: 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 aaaaaaaaaaaaaaaa [...] 0040: 61 61 61 61 61 61 61 61 61 61 61 61 61 61 0a 62 aaaaaaaaaaaaaa.b 0050: 62 62 62 62 62 62 62 62 62 62 62 62 62 0a bbbbbbbbbbbbb. 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.. iain 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 From owner-freebsd-bluetooth@FreeBSD.ORG Tue Oct 26 00:09:21 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 08679106566C for ; Tue, 26 Oct 2010 00:09:21 +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 B76288FC1F for ; Tue, 26 Oct 2010 00:09:20 +0000 (UTC) Received: by iwn39 with SMTP id 39so5018134iwn.13 for ; Mon, 25 Oct 2010 17:09:20 -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=zZr56lMvcr5RIcfWc8rAhIR3+RkBDkslNyrG9uQgG2U=; b=QthtBT8RQ7esaeKkyG8w4YKVKuoNfudJ89oYQ0YbaPTd0O3E7J92MmnUk+hOzQbmNT WTpYANKerMXlfd+wANsuAcPGaqC84YtYfDetqkuzmn/VfcJrrxXBc2zD3iBfoMjHyw15 IoPoowbJb0T58AtCAb4LQliqWa1czvSwO3ESg= 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=JH6o68RR8APkX73uEF/9+XbTNVja5CE7IrKkupMWs5dwvZX+bNMvA3+E8okBEISTno a5e4IJU2HyBzkaJlXP6WBQxkC39WisVCn3NY8MTl57AR/ddqU65tmRgBXChXCVxr4fW4 lpCJE7cleUCxAow06+CHGaEdW0quzJU+zjaqw= MIME-Version: 1.0 Received: by 10.42.191.210 with SMTP id dn18mr5733150icb.288.1288051760068; Mon, 25 Oct 2010 17:09:20 -0700 (PDT) Received: by 10.231.191.206 with HTTP; Mon, 25 Oct 2010 17:09:20 -0700 (PDT) In-Reply-To: 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 17:09:20 -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: Tue, 26 Oct 2010 00:09:21 -0000 On Mon, Oct 25, 2010 at 4:39 PM, Maksim Yevmenkin wrote: > 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. 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 From owner-freebsd-bluetooth@FreeBSD.ORG Tue Oct 26 08:19:33 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 4532B1065694 for ; Tue, 26 Oct 2010 08:19:33 +0000 (UTC) (envelope-from plunky@rya-online.net) Received: from smtp6.freeserve.com (smtp7.freeserve.com [80.12.242.2]) by mx1.freebsd.org (Postfix) with ESMTP id CD1658FC0C for ; Tue, 26 Oct 2010 08:19:32 +0000 (UTC) Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf3j02.me.freeserve.com (SMTP Server) with ESMTP id 2FED6300008B; Tue, 26 Oct 2010 10:19:31 +0200 (CEST) Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf3j02.me.freeserve.com (SMTP Server) with ESMTP id 223773000095; Tue, 26 Oct 2010 10:19:31 +0200 (CEST) Received: from rya-online.net (unknown [89.194.99.220]) by mwinf3j02.me.freeserve.com (SMTP Server) with SMTP id 20F07300008B; Tue, 26 Oct 2010 10:19:30 +0200 (CEST) X-ME-UUID: 20101026081930135.20F07300008B@mwinf3j02.me.freeserve.com Received: (nullmailer pid 1595 invoked by uid 1000); Tue, 26 Oct 2010 08:19:50 -0000 Date: Tue, 26 Oct 2010 09:19:50 +0100 (BST) To: Maksim Yevmenkin In-Reply-To: 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> User-Agent: Alpine 2.00 (NEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-Id: <1288081190.705299.12876.nullmailer@galant.ukfsn.org> From: Iain Hibbert 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: Tue, 26 Oct 2010 08:19:33 -0000 On Mon, 25 Oct 2010, Maksim Yevmenkin wrote: > 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. for what its worth, obexftp-0.20 exhibits the exact same behaviour as obexapp. (there are later versions but I can't be bothered to try and build them at this time, I have submitted patches to clean up Bluetooth support on *BSD over a year ago but the git repository shows no related activity) > 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. Hm, are you saying that if the server included the Connection ID in its GET-response, would that make it to the continue-GET (because of OBEX_ObjectReParseHeaders() call)? iain From owner-freebsd-bluetooth@FreeBSD.ORG Tue Oct 26 08:30:37 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 28A4E106566C for ; Tue, 26 Oct 2010 08:30:37 +0000 (UTC) (envelope-from plunky@rya-online.net) Received: from smtp6.freeserve.com (smtp7.freeserve.com [80.12.242.2]) by mx1.freebsd.org (Postfix) with ESMTP id B20F58FC19 for ; Tue, 26 Oct 2010 08:30:36 +0000 (UTC) Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf3j02.me.freeserve.com (SMTP Server) with ESMTP id C9B03300008B; Tue, 26 Oct 2010 10:30:35 +0200 (CEST) Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf3j02.me.freeserve.com (SMTP Server) with ESMTP id BD1CD3000095; Tue, 26 Oct 2010 10:30:35 +0200 (CEST) Received: from rya-online.net (unknown [89.194.99.220]) by mwinf3j02.me.freeserve.com (SMTP Server) with SMTP id 34E26300008B; Tue, 26 Oct 2010 10:30:33 +0200 (CEST) X-ME-UUID: 20101026083034216.34E26300008B@mwinf3j02.me.freeserve.com Received: (nullmailer pid 5519 invoked by uid 1000); Tue, 26 Oct 2010 08:30:53 -0000 Date: Tue, 26 Oct 2010 09:30:53 +0100 (BST) To: Maksim Yevmenkin In-Reply-To: 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> User-Agent: Alpine 2.00 (NEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-Id: <1288081853.739346.21413.nullmailer@galant.ukfsn.org> From: Iain Hibbert 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: Tue, 26 Oct 2010 08:30:37 -0000 On Mon, 25 Oct 2010, Maksim Yevmenkin wrote: > 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 that patch does indeed make it work! fetching an 8k file with 4k MTU: < ACL data: handle 13 flags 0x02 dlen 40 L2CAP(d): cid 0x00c0 len 36 [psm 3] RFCOMM(d): UIH: cr 1 dlci 8 pf 1 ilen 31 fcs 0x46 credits 1 OBEX: Get cmd(f): len 31 Connection ID (0xcb) = 52 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 [...] 0ff0: 58 58 58 58 58 58 58 58 58 58 XXXXXXXXXX < ACL data: handle 13 flags 0x02 dlen 17 L2CAP(d): cid 0x00c0 len 13 [psm 3] RFCOMM(d): UIH: cr 1 dlci 8 pf 1 ilen 8 fcs 0x46 credits 5 OBEX: Get cmd(f): len 8 (continue) Connection ID (0xcb) = 52 > 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 [...] 0ff0: 58 58 58 58 58 58 58 58 58 58 XXXXXXXXXX < ACL data: handle 13 flags 0x02 dlen 17 L2CAP(d): cid 0x00c0 len 13 [psm 3] RFCOMM(d): UIH: cr 1 dlci 8 pf 1 ilen 8 fcs 0x46 credits 5 OBEX: Get cmd(f): len 8 (continue) Connection ID (0xcb) = 52 > ACL data: handle 13 flags 0x02 dlen 28 L2CAP(d): cid 0x0044 len 24 [psm 3] RFCOMM(d): UIH: cr 0 dlci 8 pf 0 ilen 20 fcs 0x80 OBEX: Get rsp(f): status 200 len 20 Status 200 = Success End of Body (0x49) = Sequence length 14 0000: 58 58 58 58 58 58 58 58 58 58 58 58 58 0a XXXXXXXXXXXXX. (I have no time to think about possible misconsequences of this just now, perhaps I will subscribe to openobex-users mailing list and query them later) iain From owner-freebsd-bluetooth@FreeBSD.ORG Tue Oct 26 14:03:11 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 2F65A106566B for ; Tue, 26 Oct 2010 14:03:11 +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 DE84D8FC1C for ; Tue, 26 Oct 2010 14:03:10 +0000 (UTC) Received: by iwn39 with SMTP id 39so5850209iwn.13 for ; Tue, 26 Oct 2010 07:03:10 -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=tAVJoCy7eROjnVnYq1zY4eIT3qnBbpM9HqhiSOFHrg8=; b=h3uJsB8gzbXOewFlGIk+KIBxo5E5Bl14Vie0y3pGks3Q10Cgdz4VKLDInYwQX6pX2F l1Ko1aWd5wvmjJUuGw6333rZofN1Xk7QE8KD2h1Z/jGRQwg8NluaznRCpHlPF4Ud85sm 6cKNWJeTsnIK3lUaRtgN7pAy5zlY8jjT5lBow= 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=u+zO2io3CHUPLZ8YyhEbmIu1amEPiXULC0sQEAod8oNHLhzjP+1fahXQercU5f4ALK 56UaD7t6uhkkmXmPur8w0CtM0h0QmHGF9SGuJJBIFz+4Vhr2LsoFejQz92/ucNPttY// ijsrJBHJr69I0uZ0Hq/o87039cOY2KsOw/DvE= MIME-Version: 1.0 Received: by 10.231.12.2 with SMTP id v2mr2574728ibv.3.1288101790201; Tue, 26 Oct 2010 07:03:10 -0700 (PDT) Received: by 10.231.191.206 with HTTP; Tue, 26 Oct 2010 07:03:10 -0700 (PDT) In-Reply-To: <1288081190.705299.12876.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> <1288081190.705299.12876.nullmailer@galant.ukfsn.org> Date: Tue, 26 Oct 2010 07:03:10 -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: Tue, 26 Oct 2010 14:03:11 -0000 On Tue, Oct 26, 2010 at 1:19 AM, Iain Hibbert wrote: > On Mon, 25 Oct 2010, Maksim Yevmenkin wrote: > >> 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. > > for what its worth, obexftp-0.20 exhibits the exact same behaviour as > obexapp. well, sadly, i'm not surprised. its based on openobex as well. > (there are later versions but I can't be bothered to try and build them at > this time, I have submitted patches to clean up Bluetooth support on *BSD > over a year ago but the git repository shows no related activity) not sure if obexftp still being actively used. last time i checked there was a bunch of bluetooth-obex related code in gnome/kde etc. i dont keep track of it - things change too fast in linux land :) >> 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. > > Hm, are you saying that if the server included the Connection ID in its > GET-response, would that make it to the continue-GET (because of i _think_ so > OBEX_ObjectReParseHeaders() call)? no, not because of that. OBEX_ObjectReParseHeaders() simply moves parsed headers back to its original "un-parsed" state (as i understand the code). so when the PUT callback invoked it will get access to the same headers. [combining emails] > that patch does indeed make it work! fetching an 8k file with 4k MTU: > > (I have no time to think about possible misconsequences of this just now, > perhaps I will subscribe to openobex-users mailing list and query them > later) thanks for trying it! could you please also try PUT (to and from obexapp server) using wm6? thanks, max From owner-freebsd-bluetooth@FreeBSD.ORG Thu Oct 28 20:58:38 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 7585D106564A for ; Thu, 28 Oct 2010 20:58:38 +0000 (UTC) (envelope-from plunky@galant.ukfsn.org) Received: from mail.ukfsn.org (mail.ukfsn.org [77.75.108.10]) by mx1.freebsd.org (Postfix) with ESMTP id 08C1E8FC0A for ; Thu, 28 Oct 2010 20:58:37 +0000 (UTC) Received: from localhost (smtp-filter.ukfsn.org [192.168.54.205]) by mail.ukfsn.org (Postfix) with ESMTP id 7780CDEC01; Thu, 28 Oct 2010 21:31:26 +0100 (BST) Received: from mail.ukfsn.org ([192.168.54.25]) by localhost (smtp-filter.ukfsn.org [192.168.54.205]) (amavisd-new, port 10024) with ESMTP id FZTl-9klV1DX; Thu, 28 Oct 2010 21:31:26 +0100 (BST) Received: from galant.ukfsn.org (84-43-108-63.ppp.onetel.net.uk [84.43.108.63]) by mail.ukfsn.org (Postfix) with ESMTP id 24A6FDEBFC; Thu, 28 Oct 2010 21:31:26 +0100 (BST) Received: by galant.ukfsn.org (Postfix, from userid 1000) id CA155260260; Thu, 28 Oct 2010 21:31:50 +0100 (BST) Date: Thu, 28 Oct 2010 21:31:50 +0100 (BST) From: Iain Hibbert To: Maksim Yevmenkin In-Reply-To: Message-ID: 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> <1288081190.705299.12876.nullmailer@galant.ukfsn.org> User-Agent: Alpine 2.00 (NEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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: Thu, 28 Oct 2010 20:58:38 -0000 On Tue, 26 Oct 2010, Maksim Yevmenkin wrote: > not sure if obexftp still being actively used. last time i checked > there was a bunch of bluetooth-obex related code in gnome/kde etc. i > dont keep track of it - things change too fast in linux land :) perhaps development has ceased with obexftp. I know that there is an obexd in development for BlueZ now > > that patch does indeed make it work! fetching an 8k file with 4k MTU: > > thanks for trying it! could you please also try PUT (to and from > obexapp server) using wm6? sure obexapp client PUT -> wm6 server, no change (that code path is not used) wm6 client PUT -> obexapp server, it works ok but I see that the obexapp server does not ever actually provide a Connection ID but that we do send one that is zero with the Put response because it is not initialized to OBEXAPP_INVALID_CONNECTION_ID, eg < ACL data: handle 11 flags 0x02 dlen 16 L2CAP(d): cid 0x0048 len 12 [psm 3] RFCOMM(d): UIH: cr 0 dlci 20 pf 0 ilen 8 fcs 0xeb OBEX: Put rsp(f): status 100 len 8 Status 100 = Continue Connection ID (0xcb) = 0 so if I initialize that (in main.c, below) then it does not appear during a remote PUT. One thing that I can't check, what would happen if the "obexapp client GET -> remote" session get response did contain a Connection ID already, would we send it twice? iain --- main.c.orig 2010-10-22 07:29:06.000000000 +0100 +++ main.c 2010-10-27 22:12:01.000000000 +0100 @@ -108,6 +108,7 @@ main(int argc, char *argv[]) errx(1, "Could not allocate context.sbuffer"); context.mtu = OBEX_MAXIMUM_MTU; + context.connection_id = OBEXAPP_INVALID_CONNECTION_ID; memset(&custfunc, 0, sizeof(custfunc)); custfunc.connect = obexapp_transport_connect; From owner-freebsd-bluetooth@FreeBSD.ORG Thu Oct 28 21:03:26 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 55DD3106566B for ; Thu, 28 Oct 2010 21:03:26 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 04AE98FC13 for ; Thu, 28 Oct 2010 21:03:25 +0000 (UTC) Received: by ywh2 with SMTP id 2so1084170ywh.13 for ; Thu, 28 Oct 2010 14:03:25 -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=pli5CAvBpB5WqJAoJrZ3oOzO56mNseWEgjohGvYJ924=; b=pPRng8QpSNiHsL9BibzF0r73DYsJkpH/Wj+sDfeOlROVG1uM8jyskRYW5ZSirt3q0c wuAmzgViKURTqmTHr1NFz0n7p/qLZrcgH7G4YfoInfUsTncTmdF+TvSeCWGXZWmlHOvq MnSY+sWPM9+voPBPr3uZ88xI95i/LSuGdtxEo= 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=hFj7bj5VtHLvoewavG4CZ8Wtq29OyVoVMF3QzKIQ1fd3fGyZeZaA7g3EkbIGmdeToY twwbmJa6ELn10YrzAaeh4OyrraVHeOQFI5nEuPa8s9DEwQlf9BkLN4pJwa8bpkbUJsDo P1YO4HNZMQdLm18oHqbutL0ObUeLWxQ51sZSA= MIME-Version: 1.0 Received: by 10.42.151.7 with SMTP id c7mr1891647icw.9.1288299804921; Thu, 28 Oct 2010 14:03:24 -0700 (PDT) Received: by 10.231.191.206 with HTTP; Thu, 28 Oct 2010 14:03:24 -0700 (PDT) In-Reply-To: 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> <1288081190.705299.12876.nullmailer@galant.ukfsn.org> Date: Thu, 28 Oct 2010 14:03:24 -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: Thu, 28 Oct 2010 21:03:26 -0000 On Thu, Oct 28, 2010 at 1:31 PM, Iain Hibbert wrote: > On Tue, 26 Oct 2010, Maksim Yevmenkin wrote: > >> not sure if obexftp still being actively used. last time i checked >> there was a bunch of bluetooth-obex related code in gnome/kde etc. i >> dont keep track of it - things change too fast in linux land :) > > perhaps development has ceased with obexftp. I know that there is an obexd > in development for BlueZ now > >> > that patch does indeed make it work! fetching an 8k file with 4k MTU: >> >> thanks for trying it! could you please also try PUT (to and from >> obexapp server) using wm6? > > sure > > obexapp client PUT -> wm6 server, no change (that code path is not used) yes > wm6 client PUT -> obexapp server, it works ok but I see that the obexapp > server does not ever actually provide a Connection ID but that we do send > one that is zero with the Put response because it is not initialized to > OBEXAPP_INVALID_CONNECTION_ID, eg oops... yes, you are correct, we should initialize this. thanks for the patch! > One thing that I can't check, what would happen if the "obexapp client GET > -> remote" session get response did contain a Connection ID already, > would we send it twice? i'm not sure... i'm tempted to say no because header are parsed, i.e. we effectively move headers to another list (that is why we need reparse call). however, this is something that openobex library does internally, so, we need to test it. would be really nice to try it again apple mac os x. those guys usually do things according to standards :) thanks, max From owner-freebsd-bluetooth@FreeBSD.ORG Fri Oct 29 11:00:54 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 D3FEB106566B for ; Fri, 29 Oct 2010 11:00:54 +0000 (UTC) (envelope-from plunky@galant.ukfsn.org) Received: from mail.ukfsn.org (mail.ukfsn.org [77.75.108.10]) by mx1.freebsd.org (Postfix) with ESMTP id 68CF48FC17 for ; Fri, 29 Oct 2010 11:00:54 +0000 (UTC) Received: from localhost (smtp-filter.ukfsn.org [192.168.54.205]) by mail.ukfsn.org (Postfix) with ESMTP id A5033DEBDC; Fri, 29 Oct 2010 12:00:52 +0100 (BST) Received: from mail.ukfsn.org ([192.168.54.25]) by localhost (smtp-filter.ukfsn.org [192.168.54.205]) (amavisd-new, port 10024) with ESMTP id fkEHFjlUiABE; Fri, 29 Oct 2010 12:00:52 +0100 (BST) Received: from galant.ukfsn.org (unknown [87.242.154.254]) by mail.ukfsn.org (Postfix) with ESMTP id 4C568DEB85; Fri, 29 Oct 2010 12:00:52 +0100 (BST) Received: by galant.ukfsn.org (Postfix, from userid 1000) id DECC9260260; Fri, 29 Oct 2010 12:01:14 +0100 (BST) Date: Fri, 29 Oct 2010 12:01:14 +0100 (BST) From: Iain Hibbert To: Maksim Yevmenkin In-Reply-To: Message-ID: References: <1287509041.022618.4884.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> <1288081190.705299.12876.nullmailer@galant.ukfsn.org> User-Agent: Alpine 2.00 (NEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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: Fri, 29 Oct 2010 11:00:54 -0000 On Thu, 28 Oct 2010, Maksim Yevmenkin wrote: > > One thing that I can't check, what would happen if the "obexapp client GET > > -> remote" session get response did contain a Connection ID already, > > would we send it twice? > > i'm not sure... i'm tempted to say no because header are parsed, i.e. > we effectively move headers to another list (that is why we need > reparse call). however, this is something that openobex library does > internally, so, we need to test it. I thought about this and maybe it is a little clearer .. the object that is handed to the stream read/write functions is in fact the base GET/PUT command that openobex thinks we should be sending.. so it should be up to us to add any Connection ID headers since openobex doesn't know about them > would be really nice to try it again apple mac os x. those guys usually > do things according to standards :) obexapp works against Mac OS X 10.6 (see 2.5Mb log of get and put with connections from either side at www.netbsd.org/~plunky/obexapp-macos.txt) I also tried my wm6 phone against it and it works fine too but I don't have a packet sniffer on the mac iain From owner-freebsd-bluetooth@FreeBSD.ORG Fri Oct 29 19:10:55 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 6139A106564A for ; Fri, 29 Oct 2010 19:10:55 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 0EC448FC0C for ; Fri, 29 Oct 2010 19:10:54 +0000 (UTC) Received: by gya6 with SMTP id 6so2386055gya.13 for ; Fri, 29 Oct 2010 12:10:54 -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=gYBeclubtseTC6RBU5l4GCgTRlfhdJsxnxQ8sFPx5WA=; b=ivs73ntDb+AoHXTnb6Au36mEmjGEqphb80q6hSRvnsQInLDkG9DDHhZGGVizZ1SVz0 HhZsu9Iz6EzmSAp7D5TjU65jz/A2x28AuJE0inaSeYJd5uNjQ6UlyROeUE5LzdZKywG4 hdNMaBj058mN2lvh/vL3huDVflB8Me8878Z8g= 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=X0Bzhne3FSyz9QXTN7+whTQOl1WEsfNn+56o9sc+AkjtS/Rm6tUXq0kgZN+xpC+Svc /Rt02LpiiYWLB/0c9NiZYw/aKlsls2KeKFoYKMMM0l8DUyHN58fzPg94x7jG72t5CvYq Iz8bXwC/NJX+OIIFUo4rNrKtOSdPZEnnvq4Oo= MIME-Version: 1.0 Received: by 10.42.16.133 with SMTP id p5mr9810199ica.210.1288379453814; Fri, 29 Oct 2010 12:10:53 -0700 (PDT) Received: by 10.231.191.206 with HTTP; Fri, 29 Oct 2010 12:10:53 -0700 (PDT) In-Reply-To: References: <1287509041.022618.4884.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> <1288081190.705299.12876.nullmailer@galant.ukfsn.org> Date: Fri, 29 Oct 2010 12:10:53 -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: Fri, 29 Oct 2010 19:10:55 -0000 On Fri, Oct 29, 2010 at 4:01 AM, Iain Hibbert wrote: > On Thu, 28 Oct 2010, Maksim Yevmenkin wrote: > >> > One thing that I can't check, what would happen if the "obexapp client GET >> > -> remote" session get response did contain a Connection ID already, >> > would we send it twice? >> >> i'm not sure... i'm tempted to say no because header are parsed, i.e. >> we effectively move headers to another list (that is why we need >> reparse call). however, this is something that openobex library does >> internally, so, we need to test it. > > I thought about this and maybe it is a little clearer .. the object that > is handed to the stream read/write functions is in fact the base GET/PUT > command that openobex thinks we should be sending.. so it should be up to > us to add any Connection ID headers since openobex doesn't know about them i agree, openobex does not seem to know (or particularly care) about "connection id" header. clearly, its up to the application to set it. >> would be really nice to try it again apple mac os x. those guys usually >> do things according to standards :) > > obexapp works against Mac OS X 10.6 (see 2.5Mb log of get and put with > connections from either side at www.netbsd.org/~plunky/obexapp-macos.txt) thank you. very interesting. it appears that for PUT "connection id" header only appears on the very first request. PUT-continue does not seem to have it. it appears that mac os x consistent with obexapp here :) GET, however, is different, we can see "connection id" header on both initial GET request and GET-continue requests. again, mac os x seems to be consistent with patched obexapp. also, GET-responses on both mac os x and patched obexapp do not contain "connection id" header. so, it looks like GET-continue request is the only odd case here. i wonder if this is basically wm6 obex server oddity/bug/feature :) > I also tried my wm6 phone against it and it works fine too but I don't > have a packet sniffer on the mac well, yes, mac os x does put "connection id' header onto GET-continue requests. basically, i think, the patch should be safe. thanks for the help Iain! thanks, max