Date: Tue, 26 Oct 2010 07:03:10 -0700 From: Maksim Yevmenkin <maksim.yevmenkin@gmail.com> To: Iain Hibbert <plunky@rya-online.net> Cc: freebsd-bluetooth@freebsd.org Subject: Re: obexapp get failure Message-ID: <AANLkTi=mLPjB6aCt3fag4yQ7wwF5%2B7gagK=WxJsW=wC4@mail.gmail.com> In-Reply-To: <1288081190.705299.12876.nullmailer@galant.ukfsn.org> References: <1287509041.022618.4884.nullmailer@galant.ukfsn.org> <AANLkTimVZRNp8oh9%2BVQ6rPbXXFjdNqpgSQ2AqWjqATJY@mail.gmail.com> <1287561876.893861.6837.nullmailer@galant.ukfsn.org> <AANLkTi=V8pm51C4D58KRsiz0FfhOiU=NnUYGQJdeUwxA@mail.gmail.com> <1287732977.227959.8695.nullmailer@galant.ukfsn.org> <1287738768.915002.8520.nullmailer@galant.ukfsn.org> <AANLkTi=iHT9WOVuNq_VFfWo6R3J1ynkhGBV0s6VkS_Uw@mail.gmail.com> <1287857292.298365.1038.nullmailer@galant.ukfsn.org> <AANLkTinU1YpT=kVNHH28fkG2UuMdaRKNWzSmTa4Nq77K@mail.gmail.com> <1287874077.365931.1417.nullmailer@galant.ukfsn.org> <1287909035.704733.393.nullmailer@galant.ukfsn.org> <AANLkTimUBf8ALdpe2JHsS%2BQji-Pf_Ym1BuefCsOVLnHr@mail.gmail.com> <1288042690.562160.2361.nullmailer@galant.ukfsn.org> <AANLkTik%2BBvzyHp_u9iwdT8wG9AMG4eysnFoDvkY5amj4@mail.gmail.com> <AANLkTinADNrrNLcv964SSds_Ftt-a0uJ5S_3_mBtrbVL@mail.gmail.com> <1288081190.705299.12876.nullmailer@galant.ukfsn.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Oct 26, 2010 at 1:19 AM, Iain Hibbert <plunky@rya-online.net> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTi=mLPjB6aCt3fag4yQ7wwF5%2B7gagK=WxJsW=wC4>