Date: Fri, 19 Dec 2008 17:47:27 +0000 (GMT) From: Iain Hibbert <plunky@rya-online.net> To: Oliver Fromme <olli@lurza.secnetix.de> Cc: freebsd-bluetooth@freebsd.org Subject: Re: Bluetooth socket timeout, device pairing Message-ID: <1229708847.488082.724.nullmailer@galant.ukfsn.org> In-Reply-To: <bb4a86c70812182151q44cd1225o1c05aa5cd86bd4be@mail.gmail.com> References: <200812182301.mBIN1PGs062021@lurza.secnetix.de> <bb4a86c70812182151q44cd1225o1c05aa5cd86bd4be@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 :)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1229708847.488082.724.nullmailer>