Bluetooth socket timeout, device pairing

[Maksim Yevmenkin]

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