Open sacca97 opened 8 months ago
My hypothesis: this is due to how the m_bufs are managed. So if you try to fill them just by working with pointers you will break something (?) if the content is too big. Would like some feedback on this, there's a completely broken Secure Connection.
Hi,
Do you tune MSYS_1_BLOCK_SIZE ? Default 292 should be fine for LE SC. I think SMP code assumes continuous buffer for SMP commands so probably we miss some restrictions regarding this (at least as short term solution)
Yeah I was using the provided sample app bleprp, which sets it to 110. I can see the problem now. I can work on a fix that fits all the scenarios in the next days and make a PR.
Hi @sacca97, when do you plan to land the PR ? :)
Hey I've been a bit overwhelmend and also forgot abt it. I have made some changes in my fork but could not test it properly yet (it works in the case of the MSYS_1_BLOCK_SIZE=110 as in the blehr app at least). It is on my profile if you want to check it.
Edit:
When reducing the MSYS_1_BLOCK_SIZE (e.g., 110 as in the bleprph app) the current way of filling the mbuf does not work as intended when trying to write >60 bytes of data (DH PubKey in SC), and the result is a randomly filled mbuf which causes the handshake to abort.
The solution here would be to use the
_copyinto
function to fill the buffer.