Encrypting problem while sending data via bluetooth

Encrypting problem while sending data via bluetooth

[Steffen Becker]

Hi,

At first: Sorry for my bad english, it's not my native language. So i 
wrote my problem in german and english.

My problem refers to bluez. I didn't got useful hits on Google, IRC 
didnt help and the only answer i got in a forum was: "there are not many 
people who are familiar with that". So i hope you can help me.

My problem:
After installing the latest bluez, i connected two gentoo-PC's (v2.1.6) 
via two bluetooth-dongles (BT3.0).
PC2:# rfcomm listen 0 1
PC1:# rfcomm connect 0 <bluetooth-adress> 1
This works fine.

But now, when i try to send some data:
PC2:# cat /dev/rfcomm0
PC1:# echo "test" > /dev/rfcomm0
it looks like this on the screen of PC2:
"^J^J^J^J^^J^J^J^J^J^J^J^J^J^J^J^J^J^J^J^J^J^J^J^J^J^test^J^J^J^J^J^J^J^J^J^J^J^J^J^J^J^J^J" 

[and many more rows]

So i think it's an encrypting problem, but i really don't know how to 
solve it!
i opened /etc/bluetooth/network.conf and uncommented
DisableSecurity=true
but that didn't changed my problem.
I also tried
# hciconfig hci0 nosecmgr
but this command didn't work.

So how can i disable the Security for not getting those cryptic symbols 
(^J^J^J^J^...) ? I really hope you can help me.

Best regards,
Steffen Becker

----------------------------------------------------------------------------

Hallo,

ich habe ein Problem beim Umgang mit bluez. Ich habe bereits Google 
benutzt, IRC aufgesucht und in Foren gepostet, aber ich habe keine 
hilfreichen Informationen bekommen. Lediglich die Antwort: "Es gibt 
nicht viele Leute die sich damit auskennen".

Zu meinem Problem:
Ich habe zwei baugleiche Gentoo-Rechner(v2.1.6) mit je einem 
Bluetooth-Dongle(BT3.0) und das neueste bleuz installiert. Diese 
funktionieren soweit wunderbar. Die Verbindungsherstellung klappt ohne 
Probleme:
PC2:# rfcomm listen 0 1
PC1:# rfcomm connect 0 <bluetooth-adress> 1

Wenn ich aber nun über ">" Daten senden will passiert folgendes:
PC2:# cat /dev/rfcomm0
PC1:# echo "test" > /dev/rfcomm0
dann erscheint auf dem Bildschirm von PC2 dieses:
"^J^J^J^J^^J^J^J^J^J^J^J^J^J^J^J^J^J^J^J^J^J^J^J^J^J^test^J^J^J^J^J^J^J^J^J^J^J^J^J^J^J^J^J" 

[und viele weitere solcher Zeilen]

Ich vermute, dass es sich um ein Verschlüsselungsproblem handelt.
Dazu habe ich die /etc/bluetooth/network.conf geöffnet und folgende 
Zeile gesetzt (welche standardmäßig auskommentiert war):
DisableSecurity=true
Das hat leider nichts geändert.
Ich habe auch versucht mit dem Befehl
# hciconfig hci0 nosecmgr
die Sicherheit zu deaktivieren, aber bei diesem Befehl ist gar nichts 
passiert, da ich hier auch nicht herausgefunden habe wie die genaue 
Syntax lautet.

Ich hoffe, Sie können mir hierbei helfen. Ist das Erscheinen der 
kryptischen Zeichen (^J^J^J^J^...) wirklich auf eine 
Verschlüsselungseinstellung zurückzuführen? Und wenn ja, wie kanndagegen 
vorgehen?

Mit freundlichen Grüßen,
Steffen Becker

Re: Encrypting problem while sending data via bluetooth

[Marcel Holtmann]

Hi Steffan,

> At first: Sorry for my bad english, it's not my native language. So i 
> wrote my problem in german and english.
> 
> My problem refers to bluez. I didn't got useful hits on Google, IRC 
> didnt help and the only answer i got in a forum was: "there are not many 
> people who are familiar with that". So i hope you can help me.
> 
> My problem:
> After installing the latest bluez, i connected two gentoo-PC's (v2.1.6) 
> via two bluetooth-dongles (BT3.0).
> PC2:# rfcomm listen 0 1
> PC1:# rfcomm connect 0 <bluetooth-adress> 1
> This works fine.
> 
> But now, when i try to send some data:
> PC2:# cat /dev/rfcomm0
> PC1:# echo "test" > /dev/rfcomm0
> it looks like this on the screen of PC2:
> "^J^J^J^J^^J^J^J^J^J^J^J^J^J^J^J^J^J^J^J^J^J^J^J^J^J^test^J^J^J^J^J^J^J^J^J^J^J^J^J^J^J^J^J" 

it has nothing to do with encryption. These are TTY terminal settings.
That is why rfcomm tool has a -r (raw TTY mode) switch. And that switch
is documented in manpage.

Regards

Marcel

Re: Encrypting problem while sending data via bluetooth

[Steffen Becker]

Thank you very much, this helped me!
Now everything looks fine on the screen of the "PC2".

But now i got another problem regarding to this:
I use a third PC with the "BPA500" (it's for bluetooth sniffing).
When i use again the command

PC1: # echo "test" > /dev/rfcomm0

then the BPA500 software says:
"100% Payload/CRC Errors"
and it can't go after "start_encrypt_req" (that's the last Opcode in the 
Link Management Protocol).

That's why i still think i have an encryption problem.
But the manpage only shows me how to ENable the encryption.

So i hope somebody can help me a second time.

Regards,
Steffen


Am 14.03.2012 18:49, schrieb Marcel Holtmann:
> Hi Steffan,
>
>> At first: Sorry for my bad english, it's not my native language. So i
>> wrote my problem in german and english.
>>
>> My problem refers to bluez. I didn't got useful hits on Google, IRC
>> didnt help and the only answer i got in a forum was: "there are not many
>> people who are familiar with that". So i hope you can help me.
>>
>> My problem:
>> After installing the latest bluez, i connected two gentoo-PC's (v2.1.6)
>> via two bluetooth-dongles (BT3.0).
>> PC2:# rfcomm listen 0 1
>> PC1:# rfcomm connect 0<bluetooth-adress>  1
>> This works fine.
>>
>> But now, when i try to send some data:
>> PC2:# cat /dev/rfcomm0
>> PC1:# echo "test">  /dev/rfcomm0
>> it looks like this on the screen of PC2:
>> "^J^J^J^J^^J^J^J^J^J^J^J^J^J^J^J^J^J^J^J^J^J^J^J^J^J^test^J^J^J^J^J^J^J^J^J^J^J^J^J^J^J^J^J"
> it has nothing to do with encryption. These are TTY terminal settings.
> That is why rfcomm tool has a -r (raw TTY mode) switch. And that switch
> is documented in manpage.
>
> Regards
>
> Marcel
>
>

RE: Encrypting problem while sending data via bluetooth

[james.steele]

Hi Steffen

> But now i got another problem regarding to this:
> I use a third PC with the "BPA500" (it's for bluetooth sniffing).
> When i use again the command
>
>
> PC1: # echo "test" > /dev/rfcomm0
>
> then the BPA500 software says:
> "100% Payload/CRC Errors"
> and it can't go after "start_encrypt_req" (that's the last Opcode in the Link
> Management Protocol).
>
> That's why i still think i have an encryption problem.
> But the manpage only shows me how to ENable the encryption.
>
> So i hope somebody can help me a second time.

>From what you've said it appears that there is no problem with encryption - after the start_encrypt_req LMP message if the decoder is failing to decode the sniffed data then that is a good sign that encryption is working correctly.

If you want to decode the encrypted sniffed data then you have to configure your sniffing set-up appropriately.  Normally this requires observing the pairing process so that the sniffer can also compute the link key (and therefore encryption key).  If using Bluetooth v2.0 and earlier you may be able to enter the PIN code you are going to use in the sniffing tool prior to performing pairing.  If using Bluetooth v2.1 and later you will need to configure one of the Bluetooth devices to enter "SSP debug mode".

For the latter (Bluetooth v2.1 and later) case, we have a patch that adds the ability to enable/disable SSP debug mode using the hciconfig tool - I'll push it out to the mailing list as soon as possible, as it appears it would be useful for others.

Regards,
James

________________________________
Subject to local law, communications with Accenture and its affiliates including telephone calls and emails (including content), may be monitored by our systems for the purposes of security and the assessment of internal compliance with Accenture policy.
______________________________________________________________________________________

www.accenture.com

Re: Encrypting problem while sending data via bluetooth

[Andrei Emeltchenko]

Hi James,

On Thu, Mar 15, 2012 at 11:08:35AM +0000, james.steele@accenture.com wrote:
> Hi Steffen
> 
> > But now i got another problem regarding to this:
> > I use a third PC with the "BPA500" (it's for bluetooth sniffing).
> > When i use again the command
> >
> >
> > PC1: # echo "test" > /dev/rfcomm0
> >
> > then the BPA500 software says:
> > "100% Payload/CRC Errors"
> > and it can't go after "start_encrypt_req" (that's the last Opcode in the Link
> > Management Protocol).
> >
> > That's why i still think i have an encryption problem.
> > But the manpage only shows me how to ENable the encryption.
> >
> > So i hope somebody can help me a second time.
> 
> From what you've said it appears that there is no problem with encryption - after the start_encrypt_req LMP message if the decoder is failing to decode the sniffed data then that is a good sign that encryption is working correctly.
> 
> If you want to decode the encrypted sniffed data then you have to configure your sniffing set-up appropriately.  Normally this requires observing the pairing process so that the sniffer can also compute the link key (and therefore encryption key).  If using Bluetooth v2.0 and earlier you may be able to enter the PIN code you are going to use in the sniffing tool prior to performing pairing.  If using Bluetooth v2.1 and later you will need to configure one of the Bluetooth devices to enter "SSP debug mode".
> 
> For the latter (Bluetooth v2.1 and later) case, we have a patch that adds the ability to enable/disable SSP debug mode using the hciconfig tool - I'll push it out to the mailing list as soon as possible, as it appears it would be useful for others.

You can just issue HCI command like:

hcitool cmd 0x06 0x0004 0x01

Best regards 
Andrei Emeltchenko 

Re: Encrypting problem while sending data via bluetooth

[Steffen Becker]

Hi James,

Am 15.03.2012 12:08, schrieb james.steele@accenture.com:
> Hi Steffen
>   If using Bluetooth v2.1 and later you will need to configure one of the Bluetooth devices to enter "SSP debug mode".
>
> For the latter (Bluetooth v2.1 and later) case, we have a patch that adds the ability to enable/disable SSP debug mode using the hciconfig tool - I'll push it out to the mailing list as soon as possible, as it appears it would be useful for others.
>
> Regards,
> James
>
>
Do you know when you will push out that patch to the mailing list? It 
would be nice if it appears within this week.

Regards,
Steffen

RE: Encrypting problem while sending data via bluetooth

[Vijaykumar Dadmode]

SGkgU3RlZmZlbiwNCg0KPj4gdGhlbiB0aGUgQlBBNTAwIHNvZnR3YXJlIHNh
eXM6DQo+PiAiMTAwJSBQYXlsb2FkL0NSQyBFcnJvcnMiDQo+PiBhbmQgaXQg
Y2FuJ3QgZ28gYWZ0ZXIgInN0YXJ0X2VuY3J5cHRfcmVxIiAodGhhdCdzIHRo
ZSBsYXN0IE9wY29kZSBpbiB0aGUgDQo+PiBMaW5rIE1hbmFnZW1lbnQgUHJv
dG9jb2wpLg0KDQoNCkkgYW0gdXNpbmcgQlBBNTAwIHRvIHNuaWZmIHRoZSBM
RSBkYXRhLCBJIGhhdmUgc2VlbiBmZXcgdGltZXMgYmVsb3cgcHJvYmxlbSwg
dGhlIGRldmljZXMgd2hpY2ggeW91IGFyZSBzbmlmZmluZyBoYXZlIHRvIGJl
IHZlcnkgY2xvc2UgdG8gdGhlIEJQQTUwMCB0byB3b3JrIHdlbGwhIA0KDQpU
aGFua3MsDQpWaWpheQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K
RnJvbTogbGludXgtYmx1ZXRvb3RoLW93bmVyQHZnZXIua2VybmVsLm9yZyBb
bWFpbHRvOmxpbnV4LWJsdWV0b290aC1vd25lckB2Z2VyLmtlcm5lbC5vcmdd
IE9uIEJlaGFsZiBPZiBTdGVmZmVuIEJlY2tlcg0KU2VudDogVGh1cnNkYXks
IE1hcmNoIDE1LCAyMDEyIDI6MzAgUE0NCkNjOiBsaW51eC1ibHVldG9vdGhA
dmdlci5rZXJuZWwub3JnDQpTdWJqZWN0OiBSZTogRW5jcnlwdGluZyBwcm9i
bGVtIHdoaWxlIHNlbmRpbmcgZGF0YSB2aWEgYmx1ZXRvb3RoDQoNClRoYW5r
IHlvdSB2ZXJ5IG11Y2gsIHRoaXMgaGVscGVkIG1lIQ0KTm93IGV2ZXJ5dGhp
bmcgbG9va3MgZmluZSBvbiB0aGUgc2NyZWVuIG9mIHRoZSAiUEMyIi4NCg0K
QnV0IG5vdyBpIGdvdCBhbm90aGVyIHByb2JsZW0gcmVnYXJkaW5nIHRvIHRo
aXM6DQpJIHVzZSBhIHRoaXJkIFBDIHdpdGggdGhlICJCUEE1MDAiIChpdCdz
IGZvciBibHVldG9vdGggc25pZmZpbmcpLg0KV2hlbiBpIHVzZSBhZ2FpbiB0
aGUgY29tbWFuZA0KDQpQQzE6ICMgZWNobyAidGVzdCIgPiAvZGV2L3JmY29t
bTANCg0KdGhlbiB0aGUgQlBBNTAwIHNvZnR3YXJlIHNheXM6DQoiMTAwJSBQ
YXlsb2FkL0NSQyBFcnJvcnMiDQphbmQgaXQgY2FuJ3QgZ28gYWZ0ZXIgInN0
YXJ0X2VuY3J5cHRfcmVxIiAodGhhdCdzIHRoZSBsYXN0IE9wY29kZSBpbiB0
aGUgDQpMaW5rIE1hbmFnZW1lbnQgUHJvdG9jb2wpLg0KDQpUaGF0J3Mgd2h5
IGkgc3RpbGwgdGhpbmsgaSBoYXZlIGFuIGVuY3J5cHRpb24gcHJvYmxlbS4N
CkJ1dCB0aGUgbWFucGFnZSBvbmx5IHNob3dzIG1lIGhvdyB0byBFTmFibGUg
dGhlIGVuY3J5cHRpb24uDQoNClNvIGkgaG9wZSBzb21lYm9keSBjYW4gaGVs
cCBtZSBhIHNlY29uZCB0aW1lLg0KDQpSZWdhcmRzLA0KU3RlZmZlbg0KDQoN
CkFtIDE0LjAzLjIwMTIgMTg6NDksIHNjaHJpZWIgTWFyY2VsIEhvbHRtYW5u
Og0KPiBIaSBTdGVmZmFuLA0KPg0KPj4gQXQgZmlyc3Q6IFNvcnJ5IGZvciBt
eSBiYWQgZW5nbGlzaCwgaXQncyBub3QgbXkgbmF0aXZlIGxhbmd1YWdlLiBT
byBpDQo+PiB3cm90ZSBteSBwcm9ibGVtIGluIGdlcm1hbiBhbmQgZW5nbGlz
aC4NCj4+DQo+PiBNeSBwcm9ibGVtIHJlZmVycyB0byBibHVlei4gSSBkaWRu
J3QgZ290IHVzZWZ1bCBoaXRzIG9uIEdvb2dsZSwgSVJDDQo+PiBkaWRudCBo
ZWxwIGFuZCB0aGUgb25seSBhbnN3ZXIgaSBnb3QgaW4gYSBmb3J1bSB3YXM6
ICJ0aGVyZSBhcmUgbm90IG1hbnkNCj4+IHBlb3BsZSB3aG8gYXJlIGZhbWls
aWFyIHdpdGggdGhhdCIuIFNvIGkgaG9wZSB5b3UgY2FuIGhlbHAgbWUuDQo+
Pg0KPj4gTXkgcHJvYmxlbToNCj4+IEFmdGVyIGluc3RhbGxpbmcgdGhlIGxh
dGVzdCBibHVleiwgaSBjb25uZWN0ZWQgdHdvIGdlbnRvby1QQydzICh2Mi4x
LjYpDQo+PiB2aWEgdHdvIGJsdWV0b290aC1kb25nbGVzIChCVDMuMCkuDQo+
PiBQQzI6IyByZmNvbW0gbGlzdGVuIDAgMQ0KPj4gUEMxOiMgcmZjb21tIGNv
bm5lY3QgMDxibHVldG9vdGgtYWRyZXNzPiAgMQ0KPj4gVGhpcyB3b3JrcyBm
aW5lLg0KPj4NCj4+IEJ1dCBub3csIHdoZW4gaSB0cnkgdG8gc2VuZCBzb21l
IGRhdGE6DQo+PiBQQzI6IyBjYXQgL2Rldi9yZmNvbW0wDQo+PiBQQzE6IyBl
Y2hvICJ0ZXN0Ij4gIC9kZXYvcmZjb21tMA0KPj4gaXQgbG9va3MgbGlrZSB0
aGlzIG9uIHRoZSBzY3JlZW4gb2YgUEMyOg0KPj4gIl5KXkpeSl5KXl5KXkpe
Sl5KXkpeSl5KXkpeSl5KXkpeSl5KXkpeSl5KXkpeSl5KXkpeSl50ZXN0Xkpe
Sl5KXkpeSl5KXkpeSl5KXkpeSl5KXkpeSl5KXkpeSiINCj4gaXQgaGFzIG5v
dGhpbmcgdG8gZG8gd2l0aCBlbmNyeXB0aW9uLiBUaGVzZSBhcmUgVFRZIHRl
cm1pbmFsIHNldHRpbmdzLg0KPiBUaGF0IGlzIHdoeSByZmNvbW0gdG9vbCBo
YXMgYSAtciAocmF3IFRUWSBtb2RlKSBzd2l0Y2guIEFuZCB0aGF0IHN3aXRj
aA0KPiBpcyBkb2N1bWVudGVkIGluIG1hbnBhZ2UuDQo+DQo+IFJlZ2FyZHMN
Cj4NCj4gTWFyY2VsDQo+DQo+DQoNCg0KLS0NClRvIHVuc3Vic2NyaWJlIGZy
b20gdGhpcyBsaXN0OiBzZW5kIHRoZSBsaW5lICJ1bnN1YnNjcmliZSBsaW51
eC1ibHVldG9vdGgiIGluDQp0aGUgYm9keSBvZiBhIG1lc3NhZ2UgdG8gbWFq
b3Jkb21vQHZnZXIua2VybmVsLm9yZw0KTW9yZSBtYWpvcmRvbW8gaW5mbyBh
dCAgaHR0cDovL3ZnZXIua2VybmVsLm9yZy9tYWpvcmRvbW8taW5mby5odG1s
DQoNCg0KIFRvIHJlcG9ydCB0aGlzIGVtYWlsIGFzIHNwYW0gY2xpY2sgaHR0
cHM6Ly93d3cubWFpbGNvbnRyb2wuY29tL3NyL3dRdzB6bWpQb0hkSlRaR3lP
Q3JyaGc9PSAuDQoKCk1lbWJlciBvZiB0aGUgQ1NSIHBsYyBncm91cCBvZiBj
b21wYW5pZXMuIENTUiBwbGMgcmVnaXN0ZXJlZCBpbiBFbmdsYW5kIGFuZCBX
YWxlcywgcmVnaXN0ZXJlZCBudW1iZXIgNDE4NzM0NiwgcmVnaXN0ZXJlZCBv
ZmZpY2UgQ2h1cmNoaWxsIEhvdXNlLCBDYW1icmlkZ2UgQnVzaW5lc3MgUGFy
aywgQ293bGV5IFJvYWQsIENhbWJyaWRnZSwgQ0I0IDBXWiwgVW5pdGVkIEtp
bmdkb20KTW9yZSBpbmZvcm1hdGlvbiBjYW4gYmUgZm91bmQgYXQgd3d3LmNz
ci5jb20uIEZvbGxvdyBDU1Igb24gVHdpdHRlciBhdCBodHRwOi8vdHdpdHRl
ci5jb20vQ1NSX1BMQyBhbmQgcmVhZCBvdXIgYmxvZyBhdCB3d3cuY3NyLmNv
bS9ibG9nCg==