[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [bluetooth-dev] encryptions problem ?


The encryption works as follows (when using the security manager):

1. A basebandconnection is created.
2. Initiating device do a l2cap_connection_request and on our side
   we will ask the security manager if the incoming connection is
   OK. In our accesspoints we always allows connections to the
   l2cap layer.
3. Initating device sends a SABM message for DLCI 0 to initiate
   a rfcomm-session. When we receive it we check with the 
   security manager again if the incoming connection is allowed.
   If security is switched on we now sends a AUTHENTICATION_REQUESTED
   to the host controller which will start the authentication procedure,
   this involves creation of a linkkey for the encryption. Briefly it
   works like this: First the module tries to find a stored link key.
   If no link key is found it will ask the host if it can provide one
   and if not it asks for the pincode to be used for creation of the 
   linkkey (and the initating side will do a similar thing). The 
   detailed procedure is covered in the baseband specification.
4. The last thing that will happend in the procedure is that we
   receive an ENCRYPTION_CHANGED event which means that encryption
   now is in use. Now it's time to send the UA rfcomm response to 
   the initiating side and a rfcomm-session is sucessfully created.

So to answer your question you should send a SECURITY_OK msg from
your securitymanager to trigger rfcomm_sec to send a UA back to
the initiating device.

Unfourtanly there is no cmd to force the module to NOT use any
encryption whatsoever that I'm aware of. Both sides of a 
link can ask for encryption and therefore if you have a client
which do that we can't do anything about it. I saw a later post
on the subject which suggest that you disable the security in
your client but I really don't know which level this security 
deals with, if it's the link-level-security it should probably
work anyway but when we reach the rfcomm-layer the problem
will probably occur again. The strange thing is that you manage
to get the serialport up (which uses RFCOMM) and it confuses me
a bit. I'm currently out of office so I can't verify the exact
behaviour but the description above is how it is suposed to 
work. I'll correct the "cut-copy-paste-typo" soon (if its not 
already done by someone) :) thanks
for pointing it out. If you still can't get it to work please
provide me with the logfile during the connectionphase. 

Best Regards 
Anders Johansson

> -----Original Message-----
> From: Matthias Fuchs [mailto:matthias.fuchs@xxxxxxx.com]
> Sent: Thursday, December 06, 2001 3:01 AM
> To: Bluetooth-dev
> Subject: [bluetooth-dev] encryptions problem ?
> Hi,
> again, in general everything works fine :-)
> But when I try to connect to my OpenBT device through the DUP profile 
> from my IBM PCMCIA card (BT spec 1.1) connecting fails. 
> Connecting to a 
> serial port works fine, also SDP and so on is fine.
> I gave a glance to the log files and noticed an ENCRYPTION 
> on my OpenBT device. This is the last that happens before the client 
> throws the "connection failed" message.
> I have a simple security manager and the 
> ist defined. My current sec_man implementation does not do 
> anything when 
> receiving a sec_man_event with the ENCRYPTION_CHANGE event.
> Does it have something to do ?
> As I understood, when a device receives the above evenet, 
> encryption is 
> correctly setup and therefore I do not have to do anything upon 
> receiving this event, am I right ?
> Is there a simple way to tell the client side, that I do not want any 
> encryption ? I did not find anything in the spec about this.
> By the way, I can rember that DUP was working fine again the IBM card 
> some time ago. I am not really sure if it is a problem with 
> my Ericsson 
> modules. I changed from the ROK101008 to ROK101007.
> Any hints ?
> By the way: There's a little "cut-copy-paste-typo" in hci.c:
>      if(r_val[0]) {
>             get_err_msg(r_val[0]));
>             result_param = -r_val[0];
>             }
>       break; 
> Matthias
> -- 
> --------------------------------------------------------------
> -----------
>                              _/_/_/_/   Matthias Fuchs
>                             _/_/_/_/   Dipl.-Ing.
>                            _/_/_/_/   
> matthias.fuchs@xxxxxxx.com
>        _/_/_/   _/_/_/_/_/_/_/      esd electronic system design gmbh
>      _/   _/  _/             _/    Vahrenwalder Str. 207
>     _/   _/    _/_/_/   _/   _/   D-30165 Hannover
>     _/             _/  _/   _/   Phone: +49-511-37298-0
>      _/_/_/_/_/_/_/   _/_/_/    Fax:   +49-511-37298-68
> --------------------------------------------------------------
> -----------
> -
> To unsubscribe from this list: send the line "unsubscribe 
> bluetooth-dev" in
> the body of a message to majordomo@xxxxxxx.com
To unsubscribe from this list: send the line "unsubscribe bluetooth-dev" in
the body of a message to majordomo@xxxxxxx.com