BLE Link Layer behavior for "barge-in attack"?

[Elias]

This is a more specific counterpart to a question I posted on StackExchange. If you want to know more about the attack itself, check that out, but here, I'm asking for a specific behavior that the attack takes advantage of. I'm going to refer to Devices A and B, which are in an active unencrypted connection.

When the Link Layer of Device A receives an invalid packet, it transmits a reply with a non-incremented Next Expected Sequence Number, which signals to Device B's Link Layer that it should re-transmit the packet. Is there a limit from the perspective of Device B on how many times this can happen? If it's receiving valid packets, the channel is apparently usable, but none of the packets it's transmitting are apparently getting through.

Will Device B just keep trying to re-transmit the same packet as long as Device A keeps asking for it?

[Hung Bui]

As far as I understand, the connection will not be timed out as long as the peer still receive "valid packet" , so it doesn't mater if it's a NACK or and ACK, it's still a valid packet. Quoted here:

To be able to detect link loss, both the master and the slave shall use a Link Layer connection supervision timer, T_LLconnSupervision. Upon reception of a valid packet, the timer shall be reset.

Core spec 4.2 , Vol 6 Part B section 4.5.2 .

B will continue transmitting , there is no time out for this except if it's in a procedure that has a timeout, such as encrypting (30s timeout).

I don't understand purpose, what is the next step of jamming a device and then let other device transmitting ?

[Elias]

A quote from the Core Spec is pretty much exactly what I was hoping for.