[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Bluetooth socket timeout, device pairing
- To: Oliver Fromme <olli_(_at_)_lurza_(_dot_)_secnetix_(_dot_)_de>
- Subject: Re: Bluetooth socket timeout, device pairing
- From: Iain Hibbert <plunky_(_at_)_rya-online_(_dot_)_net>
- Date: Fri, 19 Dec 2008 17:47:27 +0000 (GMT)
- Cc: freebsd-bluetooth_(_at_)_freebsd_(_dot_)_org
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
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
(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
> 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?
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 :)
freebsd-bluetooth_(_at_)_freebsd_(_dot_)_org mailing list
To unsubscribe, send any mail to "freebsd-bluetooth-unsubscribe_(_at_)_freebsd_(_dot_)_org"
Visit your host, monkey.org