Re: BTLE pairing sequence problem

why don't you look at the source code. We have a smp_c1() in net/bluetooth/smp.c in \
the kernel (including actual test vectors). And there is also bt_crypto_c1() in \
src/shared/crypto.c in BlueZ userspace.

Shame on me, but static analysis of the kernel code has never been a
strong point of mine.
So, the only built-in test case for smp_c1() that I found is called
test_c1(), and it contains the very case described in the standard.

As for userspace tools, I found out that they yield same results as my
code (and the former kernel code, apparently): see the attached source
file. When the second, real-life test case is commented out,
everything is ok.
Unfortunately, none of the uses of bt_crypto_c1() explain why calling
it with inputs set to legitimate values and exact packet captures does
not produce the captured result. Everything seems to comply, and I`m
sure that the problem is some insanely subtle detail I fail to
understand.

And on a side note, the PDUs from pairing request / response need to fed into c1 as \
they are received over the air. Meaning you can not mask out bits and then feed it \
in. That has been clarified in an erratum and especially important for LE Secure \
Connections (which Linux does support).

Exactly as I do, actually.
Or do I? Are these request/response packet dumps I got on my capture
the ones that have to be put into _pres and _preq variables from the
code attached?