I have an nRF 52832 running the SDK 15.2 with s132_nrf52_6.1.0_softdevice as peripheral and a Dell XPS 13 9350 laptop with the integrated bluetooth 4.1 module (Dell Wireless 1820A). It's running Windows 10 Home, build 19041.804. I'm completely unable to pair with the nRF using this laptop. I can't make anything of the sniffer captures either. There are a bunch of unanswered messages and re-transmissions
Here you can see the sniffer capture. The Master sends an LL_VERSION_IND, which the slave answers. However, the slave sends an MTU request and LL_LENGTH_REQ, whereas the master sends an LL_FEATURE_REQ which are left unanswered. All of these messages seem to be ACK'd, because the SN change as expected, so I'm guessing the answers were queued, but were never transmitted because the Link Layer got stuck re-transmitting the Security Request. This message seems to never be ACK'd, as well as the Empty PDU sent by the Master, like both parties got out of sync or something.
Another attempt from the same capture file. Here, the behavior seems different, the nRF appears to disconnect completely because it doesn't even answer an empty pdu to ack the message. The LL_LENGTH_RSP is marked as having an incorrect CRC.
This kinda looks like another question I asked a few weeks ago https://devzone.nordicsemi.com/f/nordic-q-a/71182/error-when-trying-to-update-to-2m-phy-with-some-dongles. In that case, the PC seemed to be answering an incorrect packet, but, nevertheless, I did see a few cases were the LL_PHY_RSP packet was being retransmitted forever, with an incorrect CRC, with a complete absence from the nRF part. Does this point to an nRF firmware bug maybe? How is the CRC error explained?
Thank you for your time
Federico
1732.failed, laptop dell xps13 4.1 - 3.pcapng
Edit: updated the capture screenshot, it was the incorrect file
