bluetooth: controller: Cannot receive long packets #26252
Assignees
Labels
Comments
rugeGerritsen
added
bug
|
@cvinayak , @kruithofa FYI |
rugeGerritsen
changed the title
|
@rugeGerritsen if you have the sniffer logs, upload here if the size is permitted, else by other means. |
|
@cvinayak. Here are two sniffer logs. One for the default configuration and one for the case where only 1M PHY is used |
|
I have identified the bug in Zephyr LL control procedure handling of unknown rsp. I will send a fix as soon as I can get back to work. |
cvinayak
added a commit
to cvinayak/zephyr
that referenced
this issue
Jun 19, 2020
Add explicit opcode check when handling received unknown response PDU. Without this, for example, an in progress Data Length Update procedure state was reset when receiving an unknown response to slave initiated feature request. Fixes zephyrproject-rtos#26252. Signed-off-by: Vinayak Kariappa Chettimada <vich@nordicsemi.no>
cvinayak
added a commit
to cvinayak/zephyr
that referenced
this issue
Jun 19, 2020
Fix PREAMBLE_SIZE define to handle phy parameter value of 0 as 1M PHY. Certain parts of controller implementation for control procedure evaluate to 0, in which case 1M PHY is to be assumed. In the related issue zephyrproject-rtos#26252, in the sniffer log it is seen that the controller returns 2112 us instead of 2120 us due to evaluation of phy parameter to 0 and passed to PKT_US define. Relates to zephyrproject-rtos#26252. Signed-off-by: Vinayak Kariappa Chettimada <vich@nordicsemi.no>
carlescufi
pushed a commit
that referenced
this issue
Jun 22, 2020
Add explicit opcode check when handling received unknown response PDU. Without this, for example, an in progress Data Length Update procedure state was reset when receiving an unknown response to slave initiated feature request. Fixes #26252. Signed-off-by: Vinayak Kariappa Chettimada <vich@nordicsemi.no>
cvinayak
added a commit
to cvinayak/zephyr
that referenced
this issue
Jun 24, 2020
Add explicit opcode check when handling received unknown response PDU. Without this, for example, an in progress Data Length Update procedure state was reset when receiving an unknown response to slave initiated feature request. Fixes zephyrproject-rtos#26252. Signed-off-by: Vinayak Kariappa Chettimada <vich@nordicsemi.no>
cvinayak
added a commit
to cvinayak/zephyr
that referenced
this issue
Jun 24, 2020
Add explicit opcode check when handling received unknown response PDU. Without this, for example, an in progress Data Length Update procedure state was reset when receiving an unknown response to slave initiated feature request. Fixes zephyrproject-rtos#26252. Signed-off-by: Vinayak Kariappa Chettimada <vich@nordicsemi.no>
jhedberg
pushed a commit
that referenced
this issue
Sep 15, 2020
Add explicit opcode check when handling received unknown response PDU. Without this, for example, an in progress Data Length Update procedure state was reset when receiving an unknown response to slave initiated feature request. Fixes #26252. Signed-off-by: Vinayak Kariappa Chettimada <vich@nordicsemi.no>
nashif
pushed a commit
that referenced
this issue
Nov 17, 2020
Add explicit opcode check when handling received unknown response PDU. Without this, for example, an in progress Data Length Update procedure state was reset when receiving an unknown response to slave initiated feature request. Fixes #26252. Signed-off-by: Vinayak Kariappa Chettimada <vich@nordicsemi.no>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
When running the NCS throughput sample with SoftDevice LL as master and Zephyr LL as slave, the connection drops after the master starts transmitting long packets.
To Reproduce
Steps to reproduce the behavior:
Checkout NCS v1.3.0-rc3
Run throughput sample on two nrf52 devkits.
Configure the SoftDevice LL to be master, Zephyr LL to be slave
Expected behavior
The Zephyr LL should be able to receive long packets.
Impact
Showstopper. It annoys the user because it initially looks like it is the SoftDevice LL which is misbehaving.
Screenshots or console output
Entire sequence:
The screenshot below shows pin toggles on RADIO_READY and RADIO_DISABLED for both the master and slave. You can see that the Zephyr LL toggles multiple times during the packet sent from the master.
Environment (please complete the following information):
The text was updated successfully, but these errors were encountered: