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