[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Bluetooth socket timeout, device pairing
- To: "Iain Hibbert" <plunky_(_at_)_rya-online_(_dot_)_net>
- Subject: Re: Bluetooth socket timeout, device pairing
- From: "Maksim Yevmenkin" <maksim_(_dot_)_yevmenkin_(_at_)_gmail_(_dot_)_com>
- Date: Fri, 19 Dec 2008 10:10:07 -0800
- Cc: freebsd-bluetooth_(_at_)_freebsd_(_dot_)_org, Oliver Fromme <olli_(_at_)_lurza_(_dot_)_secnetix_(_dot_)_de>
- 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=
>> > 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
> 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
> (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
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!
freebsd-bluetooth_(_at_)_freebsd_(_dot_)_org mailing list
To unsubscribe, send any mail to "freebsd-bluetooth-unsubscribe_(_at_)_freebsd_(_dot_)_org"