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 _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bluetooth To unsubscribe, send any mail to "[email protected]"
