From olli at lurza.secnetix.de Mon Dec 8 01:53:45 2008 From: olli at lurza.secnetix.de (Oliver Fromme) Date: Mon Dec 8 01:53:52 2008 Subject: libbluetooth2 and Net::Bluetooth Message-ID: <200812080953.mB89rh7i042425@lurza.secnetix.de> Hello, I'm new to bluetooth (read: I know almost nothing about it), so I have a few questions. First, is there a recommended bluetooth USB dongle that's guaranteed to work with FreeBSD (7-stable) and that's not too expensive? I've seen a lot of really cheap and small dongles recently at online shops, but I assume not all of them work fine, right? Second, I would like to use this software (perl script): http://lukas.internet-freaks.net/nxtmanager.php (Sorry, the page is in German, but the .tar.gz download at the bottom of the page contains an English README.) As far as I can tell, the software requires libbluetooth2 and the CPAN module Net::Bluetooth. I searched the ports, but they're not there. I assume those don't work with FreeBSD, right? Any idea whether porting them would be feasible? Best regards Oliver -- 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 (On the statement print "42 monkeys" + "1 snake":) By the way, both perl and Python get this wrong. Perl gives 43 and Python gives "42 monkeys1 snake", when the answer is clearly "41 monkeys and 1 fat snake". -- Jim Fulton From plunky at rya-online.net Mon Dec 8 04:37:20 2008 From: plunky at rya-online.net (Iain Hibbert) Date: Mon Dec 8 04:37:27 2008 Subject: bluetooth USB dongles In-Reply-To: <200812080953.mB89rh7i042425@lurza.secnetix.de> References: <200812080953.mB89rh7i042425@lurza.secnetix.de> Message-ID: <1228739741.755294.775.nullmailer@galant.ukfsn.org> On Mon, 8 Dec 2008, Oliver Fromme wrote: > First, is there a recommended bluetooth USB dongle that's > guaranteed to work with FreeBSD (7-stable) and that's > not too expensive? I've seen a lot of really cheap and > small dongles recently at online shops, but I assume not > all of them work fine, right? the vast majority of USB dongles will work just fine if you are buying something, there are different selling points that can be confusing. Class 1 - 100m range Class 2 - 10m range Class 3 - 1m range I've never seen a class 3 device, and although I do have a class 1 controller it doesn't seem to make much difference as to signal quality at close range (I guess its just more powerful radio). Then there is Bluetooth version, so you might see v1.0b v1.2 v2.0 + EDR v2.1 + EDR If you see a v1.x device for sale then don't be tempted. v2.x devices are vastly better at making and maintaining connections, and the 'Enhanced Data Rate' gives much faster transfers. I've not seen a v2.1 dongle in the real world though they may exist (ditto for v2.2 as spec is availabe) I have seen (recently!) a v1.0b device advertised as "BLUETOOTH CLASS 2" with the v1.0b in really small writing on the case, I guess that these are old stock dressed up to sell rather than new manufactures but its good to be aware :) iain From plunky at rya-online.net Mon Dec 8 05:00:26 2008 From: plunky at rya-online.net (Iain Hibbert) Date: Mon Dec 8 05:00:32 2008 Subject: libbluetooth2 and Net::Bluetooth In-Reply-To: <200812080953.mB89rh7i042425@lurza.secnetix.de> References: <200812080953.mB89rh7i042425@lurza.secnetix.de> Message-ID: <1228741128.874448.728.nullmailer@galant.ukfsn.org> On Mon, 8 Dec 2008, Oliver Fromme wrote: > Second, I would like to use this software (perl script): > > http://lukas.internet-freaks.net/nxtmanager.php > > As far as I can tell, the software requires libbluetooth2 > and the CPAN module Net::Bluetooth. I searched the ports, > but they're not there. I assume those don't work with > FreeBSD, right? Any idea whether porting them would be > feasible? The problem with this libbluetooth2 is that it forms the interface to the linux kernel for the BlueZ system and as such, large parts of it are not relevant to any other operating system. The way that this Lego Mindstorms NXT module speaks through bluetooth is using RFCOMM with the SerialPortProfile, so of course it is possible to talk to that from FreeBSD using an RFCOMM socket directly, or by using rfcomm_sppd(1) to open a pty with a connection to the NXT and using stdio. I don't know what this perl script needs to use the libbluetooth2 for, probably the module just lumps all bluetooth together. If you know how to make bindings then perhaps you can make a RFCOMM sockets module that will fulfil the requirements? iain From vbotka at gmail.com Mon Dec 8 12:58:25 2008 From: vbotka at gmail.com (Vladimir Botka) Date: Mon Dec 8 12:58:32 2008 Subject: bluetooth USB dongles In-Reply-To: <1228739741.755294.775.nullmailer@galant.ukfsn.org> References: <200812080953.mB89rh7i042425@lurza.secnetix.de> <1228739741.755294.775.nullmailer@galant.ukfsn.org> Message-ID: <20081208212541.5736d3e9@vlado.netng.org> On Mon, 8 Dec 2008 12:35:41 +0000 (GMT) Iain Hibbert wrote: > On Mon, 8 Dec 2008, Oliver Fromme wrote: > > > First, is there a recommended bluetooth USB dongle that's > > guaranteed to work with FreeBSD (7-stable) and that's > > not too expensive? I've seen a lot of really cheap and > > small dongles recently at online shops, but I assume not > > all of them work fine, right? > > the vast majority of USB dongles will work just fine > > if you are buying something, there are different selling points that > can be confusing. > > Class 1 - 100m range > Class 2 - 10m range > Class 3 - 1m range > > I've never seen a class 3 device, and although I do have a class 1 > controller it doesn't seem to make much difference as to signal > quality at close range (I guess its just more powerful radio). Then > there is Bluetooth version, so you might see > > v1.0b > v1.2 > v2.0 + EDR > v2.1 + EDR > > If you see a v1.x device for sale then don't be tempted. v2.x devices > are vastly better at making and maintaining connections, and the > 'Enhanced Data Rate' gives much faster transfers. I've not seen a > v2.1 dongle in the real world though they may exist (ditto for v2.2 > as spec is availabe) > > I have seen (recently!) a v1.0b device advertised as "BLUETOOTH CLASS > 2" with the v1.0b in really small writing on the case, I guess that > these are old stock dressed up to sell rather than new manufactures > but its good to be aware :) > > iain > _______________________________________________ > freebsd-bluetooth@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-bluetooth > To unsubscribe, send any mail to > "freebsd-bluetooth-unsubscribe@freebsd.org" > I can recommend "cambridge silicon radio". The best choice up till now. -- -vlado Vladimir Botka From olli at lurza.secnetix.de Tue Dec 9 05:54:59 2008 From: olli at lurza.secnetix.de (Oliver Fromme) Date: Tue Dec 9 05:55:06 2008 Subject: bluetooth USB dongles In-Reply-To: <20081208212541.5736d3e9@vlado.netng.org> Message-ID: <200812091354.mB9DstLs019270@lurza.secnetix.de> Vladimir Botka wrote: > Iain Hibbert wrote: > > the vast majority of USB dongles will work just fine > > > > if you are buying something, there are different selling points that > > can be confusing. > > > > Class 1 - 100m range > > Class 2 - 10m range > > Class 3 - 1m range > > > > I've never seen a class 3 device, and although I do have a class 1 > > controller it doesn't seem to make much difference as to signal > > quality at close range (I guess its just more powerful radio). The device I'm going to use is class 2, so I guess it's sufficient to buy a class 2 controller. In order to be able to support the 100m range, both device _and_ controller have to be class 1, I assume. (Please correct me if I'm wrong.) > > Then there is Bluetooth version, so you might see > > > > v1.0b > > v1.2 > > v2.0 + EDR > > v2.1 + EDR > > > > If you see a v1.x device for sale then don't be tempted. v2.x devices > > are vastly better at making and maintaining connections, and the > > 'Enhanced Data Rate' gives much faster transfers. I've not seen a > > v2.1 dongle in the real world though they may exist (ditto for v2.2 > > as spec is availabe) > > > > I have seen (recently!) a v1.0b device advertised as "BLUETOOTH CLASS > > 2" with the v1.0b in really small writing on the case, I guess that > > these are old stock dressed up to sell rather than new manufactures > > but its good to be aware :) Thanks Iain for the explanations. That's very helpful. Indeed I noticed there are still 1.x dongles offered for sale. Good thing you warned me. > I can recommend "cambridge silicon radio". The best choice up till now. Thanks Vladimir for the suggestion. Unfortunately it is difficult to find a product by chipset name. Most online shops don't list such technical details, and even the manufacturers' web sites don't mention it. After some searching, I finally ordered a "LogiLink Ultra Mini Bluetooth 2.0 USB Adapter BT0007". According to the manufacturer's web page it is Bluetooth V2.0 with 20m range (so I assume it's class 2, even though they don't mention this), and they even say that the chipset is "CSR" (which I assume means cambridge silicon radio). Surprisingly this little fella is so small it seems to almost completely disappear inside the USB slot. Amazing. What's even better, it costs only 6 Euros. Thanks everybody for your suggestions! Best regards Oliver -- 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 "Python tricks" is a tough one, cuz the language is so clean. E.g., C makes an art of confusing pointers with arrays and strings, which leads to lotsa neat pointer tricks; APL mistakes everything for an array, leading to neat one-liners; and Perl confuses everything period, making each line a joyous adventure . -- Tim Peters From olli at lurza.secnetix.de Tue Dec 16 04:29:26 2008 From: olli at lurza.secnetix.de (Oliver Fromme) Date: Tue Dec 16 04:29:32 2008 Subject: bluetooth USB dongles In-Reply-To: <200812091354.mB9DstLs019270@lurza.secnetix.de> Message-ID: <200812161229.mBGCTNRt018478@lurza.secnetix.de> Oliver Fromme wrote: > After some searching, I finally ordered a "LogiLink Ultra > Mini Bluetooth 2.0 USB Adapter BT0007". According to the > manufacturer's web page it is Bluetooth V2.0 with 20m > range (so I assume it's class 2, even though they don't > mention this), and they even say that the chipset is "CSR" > (which I assume means cambridge silicon radio). Okay, basically it seems to work, but I have a few questions ... So I loaded the KLD modules manually (because I didn't want to reboot) and inserted the dongle. This is what I get in dmesg: WARNING: attempt to net_add_domain(netgraph) after domainfinalize() ubt0: on uhub0 ubt0: Interface 0 endpoints: interrupt=0x81, bulk-in=0x82, bulk-out=0x2 ubt0: Interface 1 (alt.config 5) endpoints: isoc-in=0x83, isoc-out=0x3; wMaxPacketSize=49; nframes=6, buffer size=294 hardware_error: - hardware error 0x37 I'm a bit worried about the warning line and the hardware error line. Is this normal and to be expected? Anyway, I followed the instructions in the Handbook and ran "/etc/rc.d/bluetooth start ubt0". I expected to get a few lines of output, according to the Handbook chapter 32.4. But I got nothing at all. Am I missing something, or should the Handbook get a fix? Still it seems to work: When I enable BT on my mobile phone, FreeBSD finds it: # hccontrol inquiry Inquiry result, num_responses=1 Inquiry result #0 BD_ADDR: 00:60:57:2e:27:de Page Scan Rep. Mode: 0x1 Page Scan Period Mode: 00 Page Scan Mode: 00 Class: 50:02:04 Clock offset: 0x18a1 Inquiry complete. Status: No error [00] And vice versa: The phone lists my FreeBSD box when I initiate a scan. The next thing I'm going to try is to connect to the NXT brick. Best regards Oliver -- 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 "The scanf() function is a large and complex beast that often does something almost but not quite entirely unlike what you desired." -- Chris Torek From olli at lurza.secnetix.de Tue Dec 16 05:09:25 2008 From: olli at lurza.secnetix.de (Oliver Fromme) Date: Tue Dec 16 05:09:31 2008 Subject: libbluetooth2 and Net::Bluetooth In-Reply-To: <1228741128.874448.728.nullmailer@galant.ukfsn.org> Message-ID: <200812161309.mBGD9Mni019996@lurza.secnetix.de> Iain Hibbert wrote: > On Mon, 8 Dec 2008, Oliver Fromme wrote: > > > Second, I would like to use this software (perl script): > > > > http://lukas.internet-freaks.net/nxtmanager.php > > > > As far as I can tell, the software requires libbluetooth2 > > and the CPAN module Net::Bluetooth. I searched the ports, > > but they're not there. I assume those don't work with > > FreeBSD, right? Any idea whether porting them would be > > feasible? > > The problem with this libbluetooth2 is that it forms the interface to the > linux kernel for the BlueZ system and as such, large parts of it are not > relevant to any other operating system. I see. > The way that this Lego Mindstorms NXT module speaks through bluetooth is > using RFCOMM with the SerialPortProfile, so of course it is possible to > talk to that from FreeBSD using an RFCOMM socket directly, or by using > rfcomm_sppd(1) to open a pty with a connection to the NXT and using stdio. > > I don't know what this perl script needs to use the libbluetooth2 for, > probably the module just lumps all bluetooth together. If you know how to > make bindings then perhaps you can make a RFCOMM sockets module that will > fulfil the requirements? Thanks for pointing me in the right direction. I decided to stop being a Bluetooth newbie and start programming the darn thing myself. :-) So I downloaded the NXT developers kit and started to make myself familiar with the API and protocols. My programming language of choice is Python, so I decided not to waste any more time with the existing (and rather unreadable) Perl code, and instead start from scratch. Python supports Bluetooth sockets natively on FreeBSD, without having to install any additional modules. In fact I found out that it's ridiculuously simple to open and access a Bluetooth RFCOMM socket from Python and talk to devices. I'll probably release my code under BSD license and submit it to the Ports collection as soon as it's ready. Thanks again for helping me to start off with this! Best regards Oliver -- 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 "What is this talk of 'release'? We do not make software 'releases'. Our software 'escapes', leaving a bloody trail of designers and quality assurance people in its wake." From olli at lurza.secnetix.de Thu Dec 18 15:01:27 2008 From: olli at lurza.secnetix.de (Oliver Fromme) Date: Thu Dec 18 15:01:34 2008 Subject: Bluetooth socket timeout, device pairing Message-ID: <200812182301.mBIN1PGs062021@lurza.secnetix.de> Hello, 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? 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? Best regards Oliver -- 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 "If Java had true garbage collection, most programs would delete themselves upon execution." -- Robert Sewell From maksim.yevmenkin at gmail.com Thu Dec 18 21:51:50 2008 From: maksim.yevmenkin at gmail.com (Maksim Yevmenkin) Date: Thu Dec 18 21:51:57 2008 Subject: Bluetooth socket timeout, device pairing In-Reply-To: <200812182301.mBIN1PGs062021@lurza.secnetix.de> References: <200812182301.mBIN1PGs062021@lurza.secnetix.de> Message-ID: Oliver, > 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 sec. > 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 pin. thanks, max From olli at lurza.secnetix.de Fri Dec 19 01:44:35 2008 From: olli at lurza.secnetix.de (Oliver Fromme) Date: Fri Dec 19 01:44:42 2008 Subject: Bluetooth socket timeout, device pairing In-Reply-To: Message-ID: <200812190944.mBJ9iWKp086368@lurza.secnetix.de> Hello Max, Maksim Yevmenkin wrote: > Oliver, > > > 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 > sec. > > > 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 > pin. 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 ... Best regards Oliver -- 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 From maksim.yevmenkin at gmail.com Fri Dec 19 09:43:27 2008 From: maksim.yevmenkin at gmail.com (Maksim Yevmenkin) Date: Fri Dec 19 09:43:33 2008 Subject: Bluetooth socket timeout, device pairing In-Reply-To: <200812190944.mBJ9iWKp086368@lurza.secnetix.de> References: <200812190944.mBJ9iWKp086368@lurza.secnetix.de> Message-ID: Oliver, [...] > > > 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 > > sec. > > > > > 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 > > pin. > > 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. depending on your definition of "security" you may be right :) simply put, pin code is not the only thing that is used to generate initialization link key. there is something (in bluetooth spec) that is called e2 key generation function. it can operate in 2 modes, and mode 2, often referred as e22, is used to generate initialization link key from pin. e22 accepts 128-bit random value and pin code augmented with device's bd_addr. the output of the e22 function is 128-bit key. in mode 1, e2, often referred as e21, takes 128-bit random value and 48-bit bd_addr and outputs 128-bit key. for more details please take a look at section 14 "bluetooth security" of part B "baseband specification" of bluetooth v1.1 specification book. > 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 ... again, it depends on your definition of "secure enough" :) "fixed" pins are most certainly have been around for a while. pretty much any bluetooth gadget with limited input capabilities/user interface usually has "fixed" pin. two examples on top of my head are bluetooth headsets and bluetooth gps'es (most of them come with hardwired pin of "0000" or something like that). keep in mind that short rf range, point-to-point nature and absence of "promiscuous mode" on of-the-shelf bluetooth devices make bluetooth somewhat more "secure" than, say, 802.11. even if it is "security through obscurity". also "pairing" is something that must be initiated manually on both sides. in my personal opinion, link level encryption is almost always a bad idea. especially when link layer is exposed like rf. at link layer one does not usually have enough information/resources/etc. to do a good crypto. good auth/crypto is something that upper layer protocols should do. thanks, max From plunky at rya-online.net Fri Dec 19 09:49:09 2008 From: plunky at rya-online.net (Iain Hibbert) Date: Fri Dec 19 09:49:16 2008 Subject: Bluetooth socket timeout, device pairing In-Reply-To: References: <200812182301.mBIN1PGs062021@lurza.secnetix.de> Message-ID: <1229708847.488082.724.nullmailer@galant.ukfsn.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 > 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 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? > 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? iain 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 :) From olli at lurza.secnetix.de Fri Dec 19 10:02:16 2008 From: olli at lurza.secnetix.de (Oliver Fromme) Date: Fri Dec 19 10:02:23 2008 Subject: Bluetooth socket timeout, device pairing In-Reply-To: Message-ID: <200812191802.mBJI2Dip008124@lurza.secnetix.de> Hello Max, Maksim Yevmenkin wrote: > [...] > > > > 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. > > depending on your definition of "security" you may be right :) simply > put, pin code is not the only thing that is used to generate > initialization link key. there is something (in bluetooth spec) that > is called e2 key generation function. it can operate in 2 modes, and > mode 2, often referred as e22, is used to generate initialization link > key from pin. e22 accepts 128-bit random value and pin code augmented > with device's bd_addr. the output of the e22 function is 128-bit key. > in mode 1, e2, often referred as e21, takes 128-bit random value and > 48-bit bd_addr and outputs 128-bit key. > > for more details please take a look at section 14 "bluetooth security" > of part B "baseband specification" of bluetooth v1.1 specification > book. > > > 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 ... > > again, it depends on your definition of "secure enough" :) "fixed" > pins are most certainly have been around for a while. pretty much any > bluetooth gadget with limited input capabilities/user interface > usually has "fixed" pin. two examples on top of my head are bluetooth > headsets and bluetooth gps'es (most of them come with hardwired pin of > "0000" or something like that). > > keep in mind that short rf range, point-to-point nature and absence of > "promiscuous mode" on of-the-shelf bluetooth devices make bluetooth > somewhat more "secure" than, say, 802.11. even if it is "security > through obscurity". also "pairing" is something that must be initiated > manually on both sides. > > > in my personal opinion, link level encryption is almost always a bad > idea. especially when link layer is exposed like rf. at link layer one > does not usually have enough information/resources/etc. to do a good > crypto. good auth/crypto is something that upper layer protocols > should do. > Thanks again for the insight. Now I understand much better how the PIN codes are used. Well, the device I'm using is just a little toy, basically (a programmable Lego robot element), so security is not on top of my priorities. So I will continue to use my custom 4-character PIN code. :-) But still, I'm surprised that PIN codes up to 16 characters are supported (and this device explicitely supports custom PIN codes that long), but there's no way you can enter more than 4 characters on the device before the connect timeout expires. Well, maybe 5 or 6 if the characters are close to each other in the alphabet, so you don't have to scroll that much. I guess it's something that the designes of the device just did not take into account. Maybe they assumed that everyone will use the factory default PIN code. Maybe I'm just too paranoid. :-) Best regards Oliver -- 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 "If you aim the gun at your foot and pull the trigger, it's UNIX's job to ensure reliable delivery of the bullet to where you aimed the gun (in this case, Mr. Foot)." -- Terry Lambert, FreeBSD-hackers mailing list. From maksim.yevmenkin at gmail.com Fri Dec 19 10:10:08 2008 From: maksim.yevmenkin at gmail.com (Maksim Yevmenkin) Date: Fri Dec 19 10:10:13 2008 Subject: Bluetooth socket timeout, device pairing In-Reply-To: <1229708847.488082.724.nullmailer@galant.ukfsn.org> References: <200812182301.mBIN1PGs062021@lurza.secnetix.de> <1229708847.488082.724.nullmailer@galant.ukfsn.org> Message-ID: 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. 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 > 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 From plunky at rya-online.net Fri Dec 19 11:35:29 2008 From: plunky at rya-online.net (Iain Hibbert) Date: Fri Dec 19 11:35:35 2008 Subject: Bluetooth socket timeout, device pairing In-Reply-To: References: <200812182301.mBIN1PGs062021@lurza.secnetix.de> <1229708847.488082.724.nullmailer@galant.ukfsn.org> Message-ID: <1229715229.577297.1167.nullmailer@galant.ukfsn.org> On Fri, 19 Dec 2008, Maksim Yevmenkin wrote: > hmm... i think, i'd like to see hci dump now to see what is going on. IIRC Oliver said ECONNREFUSED was returned, it might also be worth grepping for that in the source to see how it can occur.. > i.e. wait for page response, not complete connection setup including > authentication. but then again, you never know :) and i have been > wrong before :) No I think thats right. page timeout is the time that it takes to catch attention of the remote device, not the time it takes to complete connection negotiations. > > 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 :) I'm no crypto expert either but the only 'successful' generic attack I've heard about on bluetooth encryption required listening in on the initial pairing AND using weak PIN. I don't think it likely that any such attacks will be successful in the wild at any time soon though, as you say the hardware is not easily available for 'script kiddie' or even hardcore geek level, it would have to be some kind of targeted surveillance with a big budget. > > 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 :) I guess that "Change Connection Link Key" is e21 mode that you described > > 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! T-800: powered by FreeBSD? iain (eek!)