Re: kernel smp.c functions not called by Bluetootl LE controller

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

 



Am 21.07.2017 um 13:41 schrieb Marcel Holtmann:
> Hi Martin,
> 
>>>>> I try to call printk (with priority KERN_ALERT) functions placed in the
>>>>> net/bluetooth/smp.c file of my linux kernel 4.9.35 in order to get
>>>>> output from specifc functions like:
>>>>>
>>>>> static int smp_cmd_public_key()
>>>>>
>>>>> But during a pairing with another bluetooth LE device the output of
>>>>> these function is never shown in /var/log/kern.log
>>>>>
>>>>> Is there any way to verify, that the LE Controller accesses the Security
>>>>> Manager Protocol source code the Linux Kernel?
>>>>>
>>>>> As far as I understood the Core Specification, in BT 4.0 an above the
>>>>> Security Manager is always integrated in the Link Manager, when it comes
>>>>> to BR/EDR. But for LE the SM is integrated in the Host part and not the
>>>>> Controller. Thus LE Controller should access the smp.c in the Linux kernel.
>>>>
>>>> just run btmon and you see all the security manager exchanges.
>>>>
>>>> Regards
>>>>
>>>> Marcel
>>>>
>>> Hi Marcel,
>>> I tested it, and I saw some basic SMP messages, like:
>>>
>>> Sent Pairing Request: Bonding, MITM, Initiator Key(s): LTK CSRK ,
>>> Responder Key(s): LTK IRK CSRK
>>>
>>> I get a response and a confirmation of the pairing afterwards, but I
>>> don't see the key exchange, or the messages from Authentication Stage 1
>>> or 2.
>>>
>>> Is there any way to log parts of the smp.c functions into kern.log?
>>
>> just send the file created via "btmon -w trace.log" and I can tell you what is going on here. My guess is that you do not have LE SC enabled. That means legacy pairing is happening which does not using public key exchange.
> 
> < ACL Data TX: Handle 3585 flags 0x00 dlen 11
>       SMP: Pairing Request (0x01) len 6
>         IO capability: DisplayYesNo (0x01)
>         OOB data: Authentication data not present (0x00)
>         Authentication requirement: Bonding, MITM, SC, No Keypresses (0x0d)
>         Max encryption key size: 16
>         Initiator key distribution: EncKey Sign (0x05)
>         Responder key distribution: EncKey IdKey Sign (0x07)
>> ACL Data RX: Handle 3585 flags 0x02 dlen 11
>       SMP: Pairing Response (0x02) len 6
>         IO capability: NoInputNoOutput (0x03)
>         OOB data: Authentication data not present (0x00)
>         Authentication requirement: Bonding, No MITM, Legacy, No Keypresses (0x01)
>         Max encryption key size: 16
>         Initiator key distribution: Sign (0x04)
>         Responder key distribution: EncKey IdKey (0x03)
> 
> So while your Linux side supports LE SC, your remote side only supports legacy pairing. Which means no public key exchange will happen,
> 
> The LTK information is distributed instead of locally derived as with LE SC that uses ECDH.
> 
>> ACL Data RX: Handle 3585 flags 0x02 dlen 21
>       SMP: Encryption Information (0x06) len 16
>         Long term key: 8eb620e0cf2f490b9a174777d45c57b3
>> ACL Data RX: Handle 3585 flags 0x02 dlen 15
>       SMP: Master Identification (0x07) len 10
>         EDIV: 0x4be8
>         Rand: 0xf9cd7eb564bf38b9
> 
> Btw. I have yet to see a LE HID device that uses LE SC.
> 
> Regards
> 
> Marcel
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Thanks again for the help.

Is there any BE/EDR controller out there, which is open source/hardware
and which source code can be modified?

Kind Regards,
Martin

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature


[Index of Archives]     [Bluez Devel]     [Linux Wireless Networking]     [Linux Wireless Personal Area Networking]     [Linux ATH6KL]     [Linux USB Devel]     [Linux Media Drivers]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Big List of Linux Books]

  Powered by Linux