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