Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 29 Oct 2010 12:10:53 -0700
From:      Maksim Yevmenkin <maksim.yevmenkin@gmail.com>
To:        Iain Hibbert <plunky@galant.ukfsn.org>
Cc:        freebsd-bluetooth@freebsd.org
Subject:   Re: obexapp get failure
Message-ID:  <AANLkTikOpAMV98v16Lx0UuXg7iMNVhcJ1dZjKPbhJWP4@mail.gmail.com>
In-Reply-To: <alpine.NEB.2.00.1010291024550.7878@galant.ukfsn.org>
References:  <1287509041.022618.4884.nullmailer@galant.ukfsn.org> <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> <alpine.NEB.2.00.1010272149200.486@localhost.> <AANLkTikZ0XYYcBceViJQRp7Pxg1Ay5FPrDkQT6jwN76A@mail.gmail.com> <alpine.NEB.2.00.1010291024550.7878@galant.ukfsn.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Oct 29, 2010 at 4:01 AM, Iain Hibbert <plunky@galant.ukfsn.org> 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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTikOpAMV98v16Lx0UuXg7iMNVhcJ1dZjKPbhJWP4>