[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Bluetooth socket timeout, device pairing
- To: maksim_(_dot_)_yevmenkin_(_at_)_gmail_(_dot_)_com (Maksim Yevmenkin)
- Subject: Re: Bluetooth socket timeout, device pairing
- From: Oliver Fromme <olli_(_at_)_lurza_(_dot_)_secnetix_(_dot_)_de>
- Date: Fri, 19 Dec 2008 10:44:32 +0100 (CET)
- Cc: freebsd-bluetooth_(_at_)_freebsd_(_dot_)_org
Maksim Yevmenkin wrote:
> > My Bluetooth Python module basically works now.
> > However, I've got one small problem with pairing ...
> > I have entered an 8-character PIN code in hcsecd.conf.
> > 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. However, entering the code on
> > the brick takes some time ... I have to scroll
> > through the alphabet and digits which is rather slow.
> > I can enter at most 4 characters of the PIN code
> > before the socket() call returns with ECONN
> > ("Connection refused").
> > For now I'm using a short 4-character PIN code, but
> > I would really like to use a longer one. Where is
> > the timeout defined for that?
> 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
> > Python's socket module has no timeout by default.
> > I've also searched the net.bluetooth sysctls and
> > increased all of the timeout values (half a dozen),
> > but none of them seemed to have an effect on this
> > particular problem. So I think this value must be
> > hardcoded somewhere. Where do I have to look?
> i'm afraid that you can not change LMP response timeout. there isn't
> any defined command that would do that. 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
Thankyou very much for the explanation.
It was my impression that the length of the PIN code has
to do with the security (i.e. the longer, the better).
It seems I was wrong.
Is it correct that it would even be secure enough to use
the public default factory PIN code of the device ("1234")?
In that case I could skip the whole business of entering
a PIN code ...
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün-
chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart
FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd
"I have stopped reading Stephen King novels.
Now I just read C code instead."
-- Richard A. O'Keefe
freebsd-bluetooth_(_at_)_freebsd_(_dot_)_org mailing list
To unsubscribe, send any mail to "freebsd-bluetooth-unsubscribe_(_at_)_freebsd_(_dot_)_org"