From owner-freebsd-bluetooth@FreeBSD.ORG Fri Dec 19 18:10:08 2008 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 077001065676 for ; Fri, 19 Dec 2008 18:10:08 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.229]) by mx1.freebsd.org (Postfix) with ESMTP id CE1F38FC0C for ; Fri, 19 Dec 2008 18:10:07 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so2455507rvf.43 for ; Fri, 19 Dec 2008 10:10:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=dit0D3TUr88btNiyYt3CLemHbqY9RVzmetO8LPTcf1o=; b=Ja8DV+Fe9/lFzbxFelLpFlQp2A1E9DjcnYBstMe5pg6jieC4IwUcOaDhTojxme2hbq SSgsmkx5PkDBgKE3QfqA7f0gK7N5dq2/jnp6ZZxtMY0iR5YD4sNte8wYH8k0ZUollyrA 4rgVUpGWG+lF+cA1WLZ2zfn+nZzMQZPnDdHzA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=u5d/VHST6mx1Q2ntb89y4wsrh+6g6RXygoMj2Fn/NmQKRCynVV7sDER19XwmHFJ8+p PRZ1zDETkuHDGmTUU43SLpvOxUuJclcwbDUoINOq3Vh3flnsi3qWG4QlwReXVnJrFjaB gO0yF7+9wGfymznYJje2j/G7ffJiHPYkZCHUc= Received: by 10.140.193.15 with SMTP id q15mr1673554rvf.274.1229710207588; Fri, 19 Dec 2008 10:10:07 -0800 (PST) Received: by 10.140.177.21 with HTTP; Fri, 19 Dec 2008 10:10:07 -0800 (PST) Message-ID: Date: Fri, 19 Dec 2008 10:10:07 -0800 From: "Maksim Yevmenkin" To: "Iain Hibbert" In-Reply-To: <1229708847.488082.724.nullmailer@galant.ukfsn.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200812182301.mBIN1PGs062021@lurza.secnetix.de> <1229708847.488082.724.nullmailer@galant.ukfsn.org> Cc: freebsd-bluetooth@freebsd.org, Oliver Fromme Subject: Re: Bluetooth socket timeout, device pairing 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, 19 Dec 2008 18:10:08 -0000 Iain, >> > When I try to open a connection for the first time, >> > the device (i.e. my Mindstorms NXT brick) asks me to >> > enter the PIN code. >> >> its so called "LMP (link manager protocol) response timeout". its >> defined in link manager, i.e. part of the device's firmware. v1.1 spec >> seems to be implying that LMP response timeout should be set to 30 >> sec. > > It could be that its not the LMP timeout that is causing the connection to > be terminated though -- I never read that part of the spec but there are a > bunch of other timeouts that could cause the problem depending on how the > pairing is initiated? > > HCI Page Timeout > time given for remote device to respond to HCI connection attempt > > L2CAP response timeout > L2CAP control packet times out after this time. > > RFCOMM mcc/ack timeout hmm... i think, i'd like to see hci dump now to see what is going on. i kind of doubt it is "HCI Page Timeout" because, obviously, remote device has responded and asked for authentication. but then again, it is how i understand "page timeout" based on what spec says. The Page_Timeout configuration parameter defines the maximum time the local Link Manager will wait for a baseband page response from the remote device at a locally initiated connection attempt. i.e. wait for page response, not complete connection setup including authentication. but then again, you never know :) and i have been wrong before :) l2cap and rfcomm timeouts are also not likely, imo, because Oliver said he tried to increase them and it did not help. > and I find that on NetBSD I don't really think I've got it right, because > the timeouts can trigger too fast. Eg, the default L2CAP response timeout > is 20 seconds but the L2CAP connect request will often trigger a link code > request then pin code request and entering the pin will take it over the > limit.. > > (pairing is not needed often so I pushed this to the back of my mind :) > > I notice that some phone software has a 'pairing' function, where they can > just pair with the remote hardware and not try to make higher level > connections. Perhaps this kind of thing would work (ie just use hccontrol > to create a baseband connection) to avoid any higher level protocol > timeouts? yes, that will work. >> i'm not sure why do you care much about pin length. pin is only used >> once to generate link key and as soon as link key is generated both >> devices should use it instead of pin. > > more complex PIN does apparently mean more secure link key. mmmm.... i'm not that good in cryto, so i will let someone more qualified to render an opinion on the subject :) like i said, according to spec, e22 takes 128-bit random number in addition to pin code. plus pin code is apparently augmented by device's bd_addr, so... > I wonder though, if "Change Connection Link Key" (not in hccontrol IIRC?) > can be used to make the link key more secure without needing to pair with > a complex PIN.. presumably it generates a new link key based on some kind > of random value exchanged over the already secure connection? i guess i could always add it :) > ps I am also wondering, what kind of evil lego machine it is that Oliver > is making that he requires ultimate security on the command channel :) good call! now i want to know that too :) lego world domination team :) go lego! thanks, max