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