Date: Thu, 28 Oct 2010 21:31:50 +0100 (BST) From: Iain Hibbert <plunky@rya-online.net> To: Maksim Yevmenkin <maksim.yevmenkin@gmail.com> Cc: freebsd-bluetooth@freebsd.org Subject: Re: obexapp get failure Message-ID: <alpine.NEB.2.00.1010272149200.486@localhost.> In-Reply-To: <AANLkTi=mLPjB6aCt3fag4yQ7wwF5%2B7gagK=WxJsW=wC4@mail.gmail.com> References: <1287509041.022618.4884.nullmailer@galant.ukfsn.org> <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> <AANLkTi=mLPjB6aCt3fag4yQ7wwF5%2B7gagK=WxJsW=wC4@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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;
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.NEB.2.00.1010272149200.486>