From owner-freebsd-bluetooth@FreeBSD.ORG Tue Dec 16 12:29:26 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 2C29D1065686 for ; Tue, 16 Dec 2008 12:29:26 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (unknown [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id 9F97C8FC1A for ; Tue, 16 Dec 2008 12:29:25 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.3/8.14.3) with ESMTP id mBGCTNbQ018479; Tue, 16 Dec 2008 13:29:23 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.3/8.14.3/Submit) id mBGCTNRt018478; Tue, 16 Dec 2008 13:29:23 +0100 (CET) (envelope-from olli) Date: Tue, 16 Dec 2008 13:29:23 +0100 (CET) Message-Id: <200812161229.mBGCTNRt018478@lurza.secnetix.de> From: Oliver Fromme To: freebsd-bluetooth@FreeBSD.ORG In-Reply-To: <200812091354.mB9DstLs019270@lurza.secnetix.de> X-Newsgroups: list.freebsd-bluetooth User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/6.4-PRERELEASE-20080904 (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Tue, 16 Dec 2008 13:29:24 +0100 (CET) Cc: Subject: Re: bluetooth USB dongles 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: Tue, 16 Dec 2008 12:29:26 -0000 Oliver Fromme wrote: > After some searching, I finally ordered a "LogiLink Ultra > Mini Bluetooth 2.0 USB Adapter BT0007". According to the > manufacturer's web page it is Bluetooth V2.0 with 20m > range (so I assume it's class 2, even though they don't > mention this), and they even say that the chipset is "CSR" > (which I assume means cambridge silicon radio). Okay, basically it seems to work, but I have a few questions ... So I loaded the KLD modules manually (because I didn't want to reboot) and inserted the dongle. This is what I get in dmesg: WARNING: attempt to net_add_domain(netgraph) after domainfinalize() ubt0: on uhub0 ubt0: Interface 0 endpoints: interrupt=0x81, bulk-in=0x82, bulk-out=0x2 ubt0: Interface 1 (alt.config 5) endpoints: isoc-in=0x83, isoc-out=0x3; wMaxPacketSize=49; nframes=6, buffer size=294 hardware_error: - hardware error 0x37 I'm a bit worried about the warning line and the hardware error line. Is this normal and to be expected? Anyway, I followed the instructions in the Handbook and ran "/etc/rc.d/bluetooth start ubt0". I expected to get a few lines of output, according to the Handbook chapter 32.4. But I got nothing at all. Am I missing something, or should the Handbook get a fix? Still it seems to work: When I enable BT on my mobile phone, FreeBSD finds it: # hccontrol inquiry Inquiry result, num_responses=1 Inquiry result #0 BD_ADDR: 00:60:57:2e:27:de Page Scan Rep. Mode: 0x1 Page Scan Period Mode: 00 Page Scan Mode: 00 Class: 50:02:04 Clock offset: 0x18a1 Inquiry complete. Status: No error [00] And vice versa: The phone lists my FreeBSD box when I initiate a scan. The next thing I'm going to try is to connect to the NXT brick. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "The scanf() function is a large and complex beast that often does something almost but not quite entirely unlike what you desired." -- Chris Torek From owner-freebsd-bluetooth@FreeBSD.ORG Tue Dec 16 13:09:25 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 5EBD9106567A for ; Tue, 16 Dec 2008 13:09:25 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (unknown [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id BD12E8FC1A for ; Tue, 16 Dec 2008 13:09:24 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.3/8.14.3) with ESMTP id mBGD9Mqb019997; Tue, 16 Dec 2008 14:09:23 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.3/8.14.3/Submit) id mBGD9Mni019996; Tue, 16 Dec 2008 14:09:22 +0100 (CET) (envelope-from olli) Date: Tue, 16 Dec 2008 14:09:22 +0100 (CET) Message-Id: <200812161309.mBGD9Mni019996@lurza.secnetix.de> From: Oliver Fromme To: freebsd-bluetooth@FreeBSD.ORG, plunky@rya-online.net In-Reply-To: <1228741128.874448.728.nullmailer@galant.ukfsn.org> X-Newsgroups: list.freebsd-bluetooth User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/6.4-PRERELEASE-20080904 (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Tue, 16 Dec 2008 14:09:23 +0100 (CET) Cc: Subject: Re: libbluetooth2 and Net::Bluetooth X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-bluetooth@FreeBSD.ORG, plunky@rya-online.net List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2008 13:09:25 -0000 Iain Hibbert wrote: > On Mon, 8 Dec 2008, Oliver Fromme wrote: > > > Second, I would like to use this software (perl script): > > > > http://lukas.internet-freaks.net/nxtmanager.php > > > > As far as I can tell, the software requires libbluetooth2 > > and the CPAN module Net::Bluetooth. I searched the ports, > > but they're not there. I assume those don't work with > > FreeBSD, right? Any idea whether porting them would be > > feasible? > > The problem with this libbluetooth2 is that it forms the interface to the > linux kernel for the BlueZ system and as such, large parts of it are not > relevant to any other operating system. I see. > The way that this Lego Mindstorms NXT module speaks through bluetooth is > using RFCOMM with the SerialPortProfile, so of course it is possible to > talk to that from FreeBSD using an RFCOMM socket directly, or by using > rfcomm_sppd(1) to open a pty with a connection to the NXT and using stdio. > > I don't know what this perl script needs to use the libbluetooth2 for, > probably the module just lumps all bluetooth together. If you know how to > make bindings then perhaps you can make a RFCOMM sockets module that will > fulfil the requirements? Thanks for pointing me in the right direction. I decided to stop being a Bluetooth newbie and start programming the darn thing myself. :-) So I downloaded the NXT developers kit and started to make myself familiar with the API and protocols. My programming language of choice is Python, so I decided not to waste any more time with the existing (and rather unreadable) Perl code, and instead start from scratch. Python supports Bluetooth sockets natively on FreeBSD, without having to install any additional modules. In fact I found out that it's ridiculuously simple to open and access a Bluetooth RFCOMM socket from Python and talk to devices. I'll probably release my code under BSD license and submit it to the Ports collection as soon as it's ready. Thanks again for helping me to start off with this! Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "What is this talk of 'release'? We do not make software 'releases'. Our software 'escapes', leaving a bloody trail of designers and quality assurance people in its wake." From owner-freebsd-bluetooth@FreeBSD.ORG Thu Dec 18 23:01:27 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 DC2521065674 for ; Thu, 18 Dec 2008 23:01:27 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (unknown [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id 60D198FC0C for ; Thu, 18 Dec 2008 23:01:27 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.3/8.14.3) with ESMTP id mBIN1P4j062022; Fri, 19 Dec 2008 00:01:25 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.3/8.14.3/Submit) id mBIN1PGs062021; Fri, 19 Dec 2008 00:01:25 +0100 (CET) (envelope-from olli) Date: Fri, 19 Dec 2008 00:01:25 +0100 (CET) Message-Id: <200812182301.mBIN1PGs062021@lurza.secnetix.de> From: Oliver Fromme To: freebsd-bluetooth@FreeBSD.ORG X-Newsgroups: list.freebsd-bluetooth User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/6.4-PRERELEASE-20080904 (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Fri, 19 Dec 2008 00:01:25 +0100 (CET) Cc: Subject: 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: Thu, 18 Dec 2008 23:01:27 -0000 Hello, My Bluetooth Python module basically works now. However, I've got one small problem with pairing ... I have entered an 8-character PIN code in hcsecd.conf. 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. However, entering the code on the brick takes some time ... I have to scroll through the alphabet and digits which is rather slow. I can enter at most 4 characters of the PIN code before the socket() call returns with ECONN ("Connection refused"). For now I'm using a short 4-character PIN code, but I would really like to use a longer one. Where is the timeout defined for that? Python's socket module has no timeout by default. I've also searched the net.bluetooth sysctls and increased all of the timeout values (half a dozen), but none of them seemed to have an effect on this particular problem. So I think this value must be hardcoded somewhere. Where do I have to look? Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "If Java had true garbage collection, most programs would delete themselves upon execution." -- Robert Sewell From owner-freebsd-bluetooth@FreeBSD.ORG Fri Dec 19 05:51:50 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 D0D1D106564A for ; Fri, 19 Dec 2008 05:51:50 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.235]) by mx1.freebsd.org (Postfix) with ESMTP id A517A8FC14 for ; Fri, 19 Dec 2008 05:51:50 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so2200801rvf.43 for ; Thu, 18 Dec 2008 21:51:50 -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=UESDglJ2+oY6UP58hCVXK4pqAL1sdeK3JyGsGUinNs4=; b=HeAVlnzS83vm59NDltKCE2RpsqK7018Q8tX6VQhU9kHTgpIaXyWk/2fazu5mxZUKUK wDncvJVIOy3OdR+ekrVHxHLxvBSxoVrVmWfhMmbqM0n/uSIQ/LZfsjNNTFdFOBMNnj+Q ocK0/52pwoxkr9CGMhxByEakIJK7G7GphVL2E= 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=bEiQp8kJ812F25rcCCiB/b66prfCQO3cZhUUh273ZwcnMEmSI8H0UVAEEWjtvSxx1H Wfozg4vnjgG6vmRFChi+iowx28oRDCHwviAjPeouX/tohxfA22gPnGG07u9EnCfBBGke 1vFTdAVzD82pLwxx6g8x9aV2RG8scFYtJnpIY= Received: by 10.140.193.16 with SMTP id q16mr1408263rvf.6.1229665910397; Thu, 18 Dec 2008 21:51:50 -0800 (PST) Received: by 10.140.177.21 with HTTP; Thu, 18 Dec 2008 21:51:50 -0800 (PST) Message-ID: Date: Thu, 18 Dec 2008 21:51:50 -0800 From: "Maksim Yevmenkin" To: "Oliver Fromme" In-Reply-To: <200812182301.mBIN1PGs062021@lurza.secnetix.de> 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> Cc: freebsd-bluetooth@freebsd.org 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 05:51:50 -0000 Oliver, > My Bluetooth Python module basically works now. > However, I've got one small problem with pairing ... > > I have entered an 8-character PIN code in hcsecd.conf. > 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. However, entering the code on > the brick takes some time ... I have to scroll > through the alphabet and digits which is rather slow. > I can enter at most 4 characters of the PIN code > before the socket() call returns with ECONN > ("Connection refused"). > > For now I'm using a short 4-character PIN code, but > I would really like to use a longer one. Where is > the timeout defined for that? 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. > Python's socket module has no timeout by default. > I've also searched the net.bluetooth sysctls and > increased all of the timeout values (half a dozen), > but none of them seemed to have an effect on this > particular problem. So I think this value must be > hardcoded somewhere. Where do I have to look? i'm afraid that you can not change LMP response timeout. there isn't any defined command that would do that. 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. thanks, max From owner-freebsd-bluetooth@FreeBSD.ORG Fri Dec 19 09:44:35 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 3F26E1065675 for ; Fri, 19 Dec 2008 09:44:35 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (unknown [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id B06E68FC08 for ; Fri, 19 Dec 2008 09:44:34 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.3/8.14.3) with ESMTP id mBJ9iWUv086370; Fri, 19 Dec 2008 10:44:33 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.3/8.14.3/Submit) id mBJ9iWKp086368; Fri, 19 Dec 2008 10:44:32 +0100 (CET) (envelope-from olli) From: Oliver Fromme Message-Id: <200812190944.mBJ9iWKp086368@lurza.secnetix.de> To: maksim.yevmenkin@gmail.com (Maksim Yevmenkin) Date: Fri, 19 Dec 2008 10:44:32 +0100 (CET) In-Reply-To: X-Mailer: ELM [version 2.5 PL8] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Fri, 19 Dec 2008 10:44:33 +0100 (CET) Cc: freebsd-bluetooth@freebsd.org 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 09:44:35 -0000 Hello Max, Maksim Yevmenkin wrote: > Oliver, > > > My Bluetooth Python module basically works now. > > However, I've got one small problem with pairing ... > > > > I have entered an 8-character PIN code in hcsecd.conf. > > 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. However, entering the code on > > the brick takes some time ... I have to scroll > > through the alphabet and digits which is rather slow. > > I can enter at most 4 characters of the PIN code > > before the socket() call returns with ECONN > > ("Connection refused"). > > > > For now I'm using a short 4-character PIN code, but > > I would really like to use a longer one. Where is > > the timeout defined for that? > > 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. > > > Python's socket module has no timeout by default. > > I've also searched the net.bluetooth sysctls and > > increased all of the timeout values (half a dozen), > > but none of them seemed to have an effect on this > > particular problem. So I think this value must be > > hardcoded somewhere. Where do I have to look? > > i'm afraid that you can not change LMP response timeout. there isn't > any defined command that would do that. 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. Thankyou very much for the explanation. It was my impression that the length of the PIN code has to do with the security (i.e. the longer, the better). It seems I was wrong. Is it correct that it would even be secure enough to use the public default factory PIN code of the device ("1234")? In that case I could skip the whole business of entering a PIN code ... Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "I have stopped reading Stephen King novels. Now I just read C code instead." -- Richard A. O'Keefe From owner-freebsd-bluetooth@FreeBSD.ORG Fri Dec 19 17:43:27 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 11574106564A for ; Fri, 19 Dec 2008 17:43:27 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.237]) by mx1.freebsd.org (Postfix) with ESMTP id D91A18FC22 for ; Fri, 19 Dec 2008 17:43:26 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so2445110rvf.43 for ; Fri, 19 Dec 2008 09:43:26 -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=dMz+/WSx/SMmOEbUyggolSnSCqjF8NAlqy39sLo1Q4U=; b=lEHoKKvbDRtqNGKOgO0emMMJFSU1PhcAqjpeVRnpQL0kBf+NTHQfs3VXHcEkKqgVTv oTS3qqxotNgZGxWsFEU+O0v6g5b86SOj+GcoCORMR0XUyh1IgYoXfbr9jW+ZCmIzL5xy HVMWzV+wJmfPMqW+e1DVMHR+/Wk+SeH6ZetEg= 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=gfLQhf9xC8SJH17FaEC2g0AumFxqLi9j2jhQLLCCuudmzBXbbaH43KxjSAxK/+eiTL sYRwcxTmdxWfAopvvhVjceBP4KuqTdhrLpP4mB9SxKl7G3ddUxKv1xHv6LRUiUTxDyQE r6vuo2fPBrBB1aIcaENAvX9+0d/Wz1iScbCDw= Received: by 10.141.98.13 with SMTP id a13mr1691670rvm.85.1229708606497; Fri, 19 Dec 2008 09:43:26 -0800 (PST) Received: by 10.140.177.21 with HTTP; Fri, 19 Dec 2008 09:43:26 -0800 (PST) Message-ID: Date: Fri, 19 Dec 2008 09:43:26 -0800 From: "Maksim Yevmenkin" To: "Oliver Fromme" In-Reply-To: <200812190944.mBJ9iWKp086368@lurza.secnetix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200812190944.mBJ9iWKp086368@lurza.secnetix.de> Cc: freebsd-bluetooth@freebsd.org 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 17:43:27 -0000 Oliver, [...] > > > I have entered an 8-character PIN code in hcsecd.conf. > > > 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. However, entering the code on > > > the brick takes some time ... I have to scroll > > > through the alphabet and digits which is rather slow. > > > I can enter at most 4 characters of the PIN code > > > before the socket() call returns with ECONN > > > ("Connection refused"). > > > > > > For now I'm using a short 4-character PIN code, but > > > I would really like to use a longer one. Where is > > > the timeout defined for that? > > > > 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. > > > > > Python's socket module has no timeout by default. > > > I've also searched the net.bluetooth sysctls and > > > increased all of the timeout values (half a dozen), > > > but none of them seemed to have an effect on this > > > particular problem. So I think this value must be > > > hardcoded somewhere. Where do I have to look? > > > > i'm afraid that you can not change LMP response timeout. there isn't > > any defined command that would do that. 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. > > Thankyou very much for the explanation. > > It was my impression that the length of the PIN code has > to do with the security (i.e. the longer, the better). > It seems I was wrong. depending on your definition of "security" you may be right :) simply put, pin code is not the only thing that is used to generate initialization link key. there is something (in bluetooth spec) that is called e2 key generation function. it can operate in 2 modes, and mode 2, often referred as e22, is used to generate initialization link key from pin. e22 accepts 128-bit random value and pin code augmented with device's bd_addr. the output of the e22 function is 128-bit key. in mode 1, e2, often referred as e21, takes 128-bit random value and 48-bit bd_addr and outputs 128-bit key. for more details please take a look at section 14 "bluetooth security" of part B "baseband specification" of bluetooth v1.1 specification book. > Is it correct that it would even be secure enough to use > the public default factory PIN code of the device ("1234")? > In that case I could skip the whole business of entering > a PIN code ... again, it depends on your definition of "secure enough" :) "fixed" pins are most certainly have been around for a while. pretty much any bluetooth gadget with limited input capabilities/user interface usually has "fixed" pin. two examples on top of my head are bluetooth headsets and bluetooth gps'es (most of them come with hardwired pin of "0000" or something like that). keep in mind that short rf range, point-to-point nature and absence of "promiscuous mode" on of-the-shelf bluetooth devices make bluetooth somewhat more "secure" than, say, 802.11. even if it is "security through obscurity". also "pairing" is something that must be initiated manually on both sides. in my personal opinion, link level encryption is almost always a bad idea. especially when link layer is exposed like rf. at link layer one does not usually have enough information/resources/etc. to do a good crypto. good auth/crypto is something that upper layer protocols should do. thanks, max From owner-freebsd-bluetooth@FreeBSD.ORG Fri Dec 19 17:49: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 EBA17106567B for ; Fri, 19 Dec 2008 17:49:08 +0000 (UTC) (envelope-from plunky@rya-online.net) Received: from smtp02.one2one.net (smtp02.one2one.net [149.254.192.174]) by mx1.freebsd.org (Postfix) with ESMTP id 8D46B8FC13 for ; Fri, 19 Dec 2008 17:49:08 +0000 (UTC) (envelope-from plunky@rya-online.net) Received: from [127.0.0.1] (helo=localhost) by localhost.localdomain with esmtp (Exim 4.50) id 1LDjTD-0005w9-Ri; Fri, 19 Dec 2008 17:49:03 +0000 Received: from localhost.t-mobile.co.uk ([127.0.0.1]) by localhost (smtpbeckt01 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22623-09; Fri, 19 Dec 2008 17:49:03 +0000 (GMT) Received: from [10.206.8.46] (helo=rya-online.net) by localhost.localdomain with smtp (Exim 4.50) id 1LDjTA-0005vz-Jd; Fri, 19 Dec 2008 17:49:03 +0000 Received: (nullmailer pid 851 invoked by uid 1000); Fri, 19 Dec 2008 17:47:27 -0000 Date: Fri, 19 Dec 2008 17:47:27 +0000 (GMT) To: Oliver Fromme In-Reply-To: References: <200812182301.mBIN1PGs062021@lurza.secnetix.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-Id: <1229708847.488082.724.nullmailer@galant.ukfsn.org> From: Iain Hibbert X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at example.com X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: plunky@rya-online.net X-SA-Exim-Scanned: No (on localhost.localdomain); SAEximRunCond expanded to false Cc: freebsd-bluetooth@freebsd.org 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 17:49:09 -0000 On Thu, 18 Dec 2008, Maksim Yevmenkin wrote: > Oliver Fromme writes: > > 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 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? > 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. 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? iain 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 :) From owner-freebsd-bluetooth@FreeBSD.ORG Fri Dec 19 18:02:15 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 E251B106564A for ; Fri, 19 Dec 2008 18:02:15 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (unknown [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id 5D1AA8FC14 for ; Fri, 19 Dec 2008 18:02:15 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.3/8.14.3) with ESMTP id mBJI2DWT008126; Fri, 19 Dec 2008 19:02:13 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.3/8.14.3/Submit) id mBJI2Dip008124; Fri, 19 Dec 2008 19:02:13 +0100 (CET) (envelope-from olli) From: Oliver Fromme Message-Id: <200812191802.mBJI2Dip008124@lurza.secnetix.de> To: maksim.yevmenkin@gmail.com (Maksim Yevmenkin) Date: Fri, 19 Dec 2008 19:02:13 +0100 (CET) In-Reply-To: X-Mailer: ELM [version 2.5 PL8] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Fri, 19 Dec 2008 19:02:13 +0100 (CET) Cc: freebsd-bluetooth@freebsd.org 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:02:16 -0000 Hello Max, Maksim Yevmenkin wrote: > [...] > > > > It was my impression that the length of the PIN code has > > to do with the security (i.e. the longer, the better). > > It seems I was wrong. > > depending on your definition of "security" you may be right :) simply > put, pin code is not the only thing that is used to generate > initialization link key. there is something (in bluetooth spec) that > is called e2 key generation function. it can operate in 2 modes, and > mode 2, often referred as e22, is used to generate initialization link > key from pin. e22 accepts 128-bit random value and pin code augmented > with device's bd_addr. the output of the e22 function is 128-bit key. > in mode 1, e2, often referred as e21, takes 128-bit random value and > 48-bit bd_addr and outputs 128-bit key. > > for more details please take a look at section 14 "bluetooth security" > of part B "baseband specification" of bluetooth v1.1 specification > book. > > > Is it correct that it would even be secure enough to use > > the public default factory PIN code of the device ("1234")? > > In that case I could skip the whole business of entering > > a PIN code ... > > again, it depends on your definition of "secure enough" :) "fixed" > pins are most certainly have been around for a while. pretty much any > bluetooth gadget with limited input capabilities/user interface > usually has "fixed" pin. two examples on top of my head are bluetooth > headsets and bluetooth gps'es (most of them come with hardwired pin of > "0000" or something like that). > > keep in mind that short rf range, point-to-point nature and absence of > "promiscuous mode" on of-the-shelf bluetooth devices make bluetooth > somewhat more "secure" than, say, 802.11. even if it is "security > through obscurity". also "pairing" is something that must be initiated > manually on both sides. > > > in my personal opinion, link level encryption is almost always a bad > idea. especially when link layer is exposed like rf. at link layer one > does not usually have enough information/resources/etc. to do a good > crypto. good auth/crypto is something that upper layer protocols > should do. > Thanks again for the insight. Now I understand much better how the PIN codes are used. Well, the device I'm using is just a little toy, basically (a programmable Lego robot element), so security is not on top of my priorities. So I will continue to use my custom 4-character PIN code. :-) But still, I'm surprised that PIN codes up to 16 characters are supported (and this device explicitely supports custom PIN codes that long), but there's no way you can enter more than 4 characters on the device before the connect timeout expires. Well, maybe 5 or 6 if the characters are close to each other in the alphabet, so you don't have to scroll that much. I guess it's something that the designes of the device just did not take into account. Maybe they assumed that everyone will use the factory default PIN code. Maybe I'm just too paranoid. :-) Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "If you aim the gun at your foot and pull the trigger, it's UNIX's job to ensure reliable delivery of the bullet to where you aimed the gun (in this case, Mr. Foot)." -- Terry Lambert, FreeBSD-hackers mailing list. 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 From owner-freebsd-bluetooth@FreeBSD.ORG Fri Dec 19 19:35:29 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 898641065674 for ; Fri, 19 Dec 2008 19:35:29 +0000 (UTC) (envelope-from plunky@rya-online.net) Received: from smtp02.one2one.net (smtp02.one2one.net [149.254.192.174]) by mx1.freebsd.org (Postfix) with ESMTP id 2781C8FC19 for ; Fri, 19 Dec 2008 19:35:28 +0000 (UTC) (envelope-from plunky@rya-online.net) Received: from [127.0.0.1] (helo=localhost) by localhost.localdomain with esmtp (Exim 4.50) id 1LDl88-0006la-Nl for freebsd-bluetooth@freebsd.org; Fri, 19 Dec 2008 19:35:24 +0000 Received: from localhost.t-mobile.co.uk ([127.0.0.1]) by localhost (smtpbeckt01 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25998-01 for ; Fri, 19 Dec 2008 19:35:24 +0000 (GMT) Received: from [10.206.8.46] (helo=rya-online.net) by localhost.localdomain with smtp (Exim 4.50) id 1LDl85-0006lV-Mx for freebsd-bluetooth@freebsd.org; Fri, 19 Dec 2008 19:35:24 +0000 Received: (nullmailer pid 935 invoked by uid 1000); Fri, 19 Dec 2008 19:33:49 -0000 Date: Fri, 19 Dec 2008 19:33:49 +0000 (GMT) To: freebsd-bluetooth@freebsd.org In-Reply-To: References: <200812182301.mBIN1PGs062021@lurza.secnetix.de> <1229708847.488082.724.nullmailer@galant.ukfsn.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-Id: <1229715229.577297.1167.nullmailer@galant.ukfsn.org> From: Iain Hibbert X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at example.com X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: plunky@rya-online.net X-SA-Exim-Scanned: No (on localhost.localdomain); SAEximRunCond expanded to false 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 19:35:29 -0000 On Fri, 19 Dec 2008, Maksim Yevmenkin wrote: > hmm... i think, i'd like to see hci dump now to see what is going on. IIRC Oliver said ECONNREFUSED was returned, it might also be worth grepping for that in the source to see how it can occur.. > i.e. wait for page response, not complete connection setup including > authentication. but then again, you never know :) and i have been > wrong before :) No I think thats right. page timeout is the time that it takes to catch attention of the remote device, not the time it takes to complete connection negotiations. > > 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 :) I'm no crypto expert either but the only 'successful' generic attack I've heard about on bluetooth encryption required listening in on the initial pairing AND using weak PIN. I don't think it likely that any such attacks will be successful in the wild at any time soon though, as you say the hardware is not easily available for 'script kiddie' or even hardcore geek level, it would have to be some kind of targeted surveillance with a big budget. > > 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 :) I guess that "Change Connection Link Key" is e21 mode that you described > > 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! T-800: powered by FreeBSD? iain (eek!)